Compose: Docker-Compose langsam auf Docker für Mac OS Beta

ping @frenchben : lächeln:

+1

habe das gleiche Problem: D.

@ smith64fx Problem

@stijn Ja, wenn ich WiFi ausschalte, funktioniert alles wie Charme

Von meinem iPhone gehört

Am 05.05.2016 um 00:26 schrieb Sebastiaan van Stijn [email protected] :

@ smith64fx Problem

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an

@ smith64fx Ich sehe aus Ihrer Unterschrift, dass Sie wahrscheinlich aus Deutschland (oder Österreich / Schweiz) stammen. Stört es Sie, wenn ich Sie frage, was Ihr Internetprovider ist? Ich frage mich, ob wir das gleiche haben und ob es aus der Box kommen könnte, die nicht wie ein sehr gutes Stück Hardware / Software aussieht und nicht so funktioniert, wie es Docker gedacht hat.

(Ich bin bei Vodafone und ich habe ihre Easybox - was auch immer)

Gleiches Problem in einem kabelgebundenen Netzwerk (Unternehmensnetzwerk), sobald ich es ausstecke, ist alles sehr schnell. Ich bin mir also sicher, dass es nicht mit Ihrem spezifischen Anbieter zusammenhängt.

Ich habe mir die ausführliche Ausgabe angesehen, es gibt keinen offensichtlichen Fehler (noch irgendwo in den Systemprotokollen). Habe das allerdings bemerkt:

Ohne Vernetzung sind diese Leitungen zusammengefasst:

docker attach <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e', stderr=True, stream=True, stdout=True)
docker attach -> <generator object _multiplexed_response_stream_helper at 0x1045f20a0>
docker start <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e')

Ohne Netzwerk bekomme ich ~ 100-200 Zeilen 'compose.parallel.feed_queue: Pending: set ([])' zwischen dem Attach <- und dem Ort, an dem es mit Attach -> zurückgegeben wird ...

Vor diesem Punkt passiert auch viel mehr mit dem Netzwerk, aber meistens nur mehr Anrufe, um das Bild usw. zu überprüfen, wie es scheint.

Ich habe die Ausgabe von compose --verbose für Bot-Situationen angehängt. Die Erstellungsdatei besteht nur aus zwei Containern direkt vom Hub.

with-network.txt
ohne-network.txt

@holstvoogd oh, ok für den Anbieter. Danke für die Info, ich war ein bisschen besorgt :)

@Erwyn @ smith64fx Um zu bestätigen, dass Sie immer verbunden sind (fest verdrahtet) und gleichzeitig dasselbe Netzwerk mit WLAN verwenden?

@FrenchBen Nein, es ist nur im WLAN-Netzwerk in meinem Haus. In meinem Büro geht es super schnell. Aber die Sache ist, alles andere zu Hause läuft schnell, außer Docker-Compose ^ _ ^ "

@FrenchBen wie @ smith64fx. Es ist nur WLAN zu Hause, so dass keine Kabelverbindung erforderlich ist. Und wie ich sehen kann, scheint Kabelverbindung zu haben.

Ich stelle das gleiche Problem mit Docker für Mac Beta fest. docker-compose up ist langsam, wenn Wifi aktiviert ist, schnell, wenn Wifi deaktiviert ist.

• Docker Compose-Version: Docker-Compose-Version 1.7.1, Build 0a9ab35
• Docker-Version: Docker-Version 1.11.1, Build 5604cbe
• Betriebssystemversion: OS X El Capitan 10.11.4

Hallo, gibt es Neuigkeiten dazu?

Ich habe das gleiche Problem. Compose / Docker / OSX-Versionen sind dieselben wie bei @eugenesia .
Ich benutze WiFi zu Hause und im Büro und bei mir zu Hause funktioniert es unglaublich langsam. Im Büro funktioniert es wie erwartet (schnell).

Ich dachte, es hängt vielleicht mit dem DNS-Server meines Internetdienstanbieters zusammen (Internetanbieter zu Hause und im Büro sind unterschiedlich), und ich habe versucht, öffentliches DNS zu verwenden, einschließlich des von Google, aber es hat nicht geholfen.

Wenn ich WiFi ausschalte, funktioniert docker-compose sehr schnell

@KryDos Diese Woche sollte eine neue Version mit einigen Geschwindigkeitsverbesserungen herauskommen

Ich habe das gleiche Problem, nach dem Update auf Docker für Mac 1.11.1-Beta13 bleibt das Problem bestehen. Die Problemumgehung durch Aus- und Wiedereinschalten der Netzwerke funktioniert nicht mehr. Die Dienste werden beim Ausschalten des Netzwerks schnell gestartet. Beim erneuten Einschalten des Netzwerks sind die Dienste jedoch nicht mehr verfügbar und der Docker-Daemon reagiert nicht

docker ps
Error response from daemon: Bad response from Docker engine

• Docker Compose-Version: Docker-Compose-Version 1.7.1, Build 0a9ab35
• Docker-Version: Docker-Version 1.11.1-beta13, Build 7975
• Betriebssystemversion: OS X El Capitan 10.11.5

Ich hatte die gleichen Probleme und fand einen Beitrag (Entschuldigung, ich habe den Schiedsrichter verloren), in dem erwähnt wurde, dass Docker-Compose versucht, localunixsocket.local aufzulösen. Sie können einen Einblick in die DNS-Suche erhalten, indem Sie sudo tcpdump -A -s0 -nni en0 port 53 ausführen

Im Moment habe ich localunixsocket.local in meinem /etc/hosts auf localhost gezeigt. Jetzt ist alles wieder schnell.

127.0.0.1 localunixsocket.local

Danke @jewilmeer , das sieht nützlich aus

Ich habe mit Virtualbox mit Docker-Maschine zurückgeschaltet. Problem gibt es nicht und es ist bis zu 10x schneller als Docker Mac Beta!

@ smith64fx bitte halten Sie Ihre Kommentare konstruktiv; Es ist eine Beta, es ist noch kein fertiges Produkt, daher werden Fehler und Leistungsprobleme erwartet. Es sind genau diese Probleme, die gemeldet (und getestet) werden müssen, um sie zu beheben.

super toller Kommentar, @jewilmeer! Für mich musste ich / etc / hosts ein paar weitere Adressen hinzufügen, die ich mit Ihrem Befehl tcpdump :

# (yours)
127.0.0.1 localunixsocket.local
# additional ones -- be sure to replace bracketed thing with the output of `hostname`
127.0.0.1 localunixsocket.home <my hostname>.home

Nach diesen Ergänzungen - schnell! Eigentlich erstaunlich schnell, scheint ein guter Haufen schneller zu sein als bei Verwendung der Docker Toolbox! woop woop :) (Obwohl das eine sehr subjektive Beobachtung sein kann!)

Das ist ziemlich seltsam, scheint aber darauf hinzuweisen, was das zugrunde liegende Problem ist ...

Ich habe derzeit das gleiche Problem und kann das Problem nicht lösen.
Ich habe die vorherigen Vorschläge zum Bearbeiten von /etc/hosts ausprobiert. In unserem Büronetzwerk ist Docker extrem langsam. In Heimnetzwerken oder durch die Anbindung an ein Mobiltelefon werden alle Verlangsamungen beseitigt und alles ist bissig.

Wir verwenden Docker-Compose mit einem Webcontainer, der mit vier Servicecontainern verknüpft ist (postgres, redis, rabbitmq, elasticsearch). Die Verbindung zu einem der vier Service-Container direkt von OSX aus ist in Ordnung. Es ist nur langsam, wenn versucht wird, eine Verbindung vom Webcontainer zu einem der Servicecontainer herzustellen.

Wenn Sie tcpdump -vvv -s 0 -l -n port 53 ausführen, wird die folgende Ausgabe ausgegeben, wenn Sie an ein Mobiltelefon gebunden sind

tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
16:54:34.236026 IP (tos 0x0, ttl 64, id 25341, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.56662 > 172.20.10.1.53: [udp sum ok] 5785+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.239617 IP (tos 0x0, ttl 64, id 29137, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.56662: [udp sum ok] 5785 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:34.303325 IP (tos 0x0, ttl 64, id 46188, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.58590 > 172.20.10.1.53: [udp sum ok] 52066+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.309241 IP (tos 0x0, ttl 64, id 7329, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.58590: [udp sum ok] 52066 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.309028 IP (tos 0x0, ttl 64, id 52570, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.63544 > 172.20.10.1.53: [udp sum ok] 12851+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.320135 IP (tos 0x0, ttl 64, id 32359, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.63544: [udp sum ok] 12851 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.392915 IP (tos 0x0, ttl 64, id 8082, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.59994 > 172.20.10.1.53: [udp sum ok] 22334+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.416821 IP (tos 0x0, ttl 64, id 51863, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.59994: [udp sum ok] 22334 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)

und dies ist die Ausgabe, wenn in unserem Büro WLAN:

16:54:13.870062 IP (tos 0x0, ttl 64, id 17811, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56316 > 192.168.0.1.53: [udp sum ok] 21469+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.870723 IP (tos 0x0, ttl 64, id 53920, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.52082 > 192.168.0.1.53: [udp sum ok] 50601+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.872706 IP (tos 0x0, ttl 64, id 50395, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56176 > 192.168.0.1.53: [udp sum ok] 45180+ PTR? 1.0.19.172.in-addr.arpa. (41)

Es sieht also nach etwas mit umgekehrter DNS-Suche aus, aber ich bin mir nicht sicher, wie ich Fehler beheben soll. Das vollständige Deaktivieren von WLAN garantiert auch diese Langsamkeit. Das Deaktivieren und erneute Aktivieren hilft nicht.

Natürlich finden Sie gleich nach dem Posten der Frage Ihre eigene Lösung. Es sieht so aus, als ob ein in unserer Entwicklungsumgebung installiertes Paket die DNS-Einstellungen in OSX aktualisiert hat, die das Problem verursachen. Sobald ich das OSX-DNS zurückgesetzt habe, um die Standardeinstellungen in /etc/resolv.conf zu verwenden, funktioniert alles.

Könnte dies mit dem Problem zusammenhängen, dass Bonjour .local und ein IPV6-Fehler vorliegt?
Details: https://news.ycombinator.com/item?id=11567442

Keine Ahnung, ob dies hilft, aber ich hatte dieses Problem und habe es behoben, indem ich meine DNS-Server auf 8.8.8.8 und 8.8.4.4 geändert habe.

Auch dieses Problem trat nur in meinem Heimnetzwerk auf. Bei der Arbeit hatte ich dieses Problem nicht.

Ich habe auch das gleiche Problem, selbst nachdem ich versucht habe,
Docker-Compose-Up funktioniert in meinem Büronetzwerk einwandfrei, in meinem Heimnetzwerk dauert es jedoch ca. 7 Minuten.
Gleiches Verhalten mit anderen Docker-Compose-Befehlen wie Stop, Pull, Ps usw.

Docker - Version
Docker Version 1.12.0-rc2, Build 906eacd, experimentell

Docker-Compose - Version
Docker-Compose Version 1.8.0-rc1, Build 9bf6bc6

Docker-Maschine - Version
Docker-Maschine Version 0.8.0-rc1, Build fffa6c9

Ich weiß nicht warum, aber ich musste jedes lokale Domänenelement entfernen, damit es funktioniert.

/ etc / hosts:
127.0.0.1 localunixsocket

Ich habe ein sehr ähnliches Problem, aber ich denke, es hängt möglicherweise mit meiner Verwendung von DNSCrypt zusammen .

@Erwyn Ich habe das gleiche Problem auch mit Vodafone Easybox erlebt ...
Es stellte sich heraus, dass Vodafone Easybox die Suche nach .local Domains an den Router bindet (um den dynamischen Hostnamen Ihres Routers auszuwerten, nämlich easy.box ).
und ich vermute, dass diese Bindung dazu geführt hat, dass docker-compose auf die Antwort des Routers gewartet hat (ich könnte mich in dieser Sache völlig irren) ...
aber hinzufügen
127.0.0.1 localunixsocket.local bis etc/hosts das Problem für mich gelöst

Hallo Leute,
127.0.0.1 localunixsocket to etc / hosts hat das Problem für mich gelöst

@ Davidid Thx Bro, funktioniert perfekt! Ich bin interessiert, warum wir diese Problemumgehung benötigen.

Hallo Leute! Selbes Problem hier. In Brasilien dauert es lange, bis WLAN im Büro verwendet wird. Nach dem Ändern der /etc/hosts -Dateien funktionierte alles einwandfrei.

Gleiches Problem hier. Ich arbeite in einem Büro (über WIFI) und habe keine Probleme oder Verzögerungen. Wenn ich in einem anderen Büro (auch über WIFI) arbeite, bekomme ich ca. 10 Minuten Verspätung.

Das Hinzufügen von 127.0.0.1 localunixsocket zu /etc/hosts hat das Problem für mich nicht gelöst. Ich habe versucht, dies in Kombination mit einem Neustart zu tun, aber immer noch kein Glück.

Durch Hinzufügen von 8.8.8.8 und 8.8.4.4 als DNS-Server wurde das Problem behoben.

Danke @Typositoire!

Hey, @dadarek , versuche 127.0.0.1 localunixsocket.home <hostname>.home in deine Hosts-Datei einzufügen . Es hat nur bei mir funktioniert, als ich beide Hostnamen hinzugefügt habe. Sie können also weiterhin Ihr lokales DNS verwenden, wenn Sie ...

Dies tritt für mich sowohl im stabilen als auch im Beta-Kanal auf. Wenn ich das Internet trenne oder den Host-Eintrag hinzufüge, wird dies für mich behoben.

El Capitan 10.11.4
Docker Version 1.12.0, Build 8eab29e, experimentell
Docker-Compose Version 1.8.0, Build f3628c7
Docker-Maschine Version 0.8.0, Build b85aac1

Ich habe versucht, sowohl den Hostnamen als auch das Internet von einem Build-Befehl zu trennen, und nichts hilft ... versuchte auch die DNS-Änderung ... sie sitzt nur 5-10 Minuten dort und startet dann den Build-Prozess ... Ich kann sehen, wie die CPU-Auslastung abläuft Bis zu 100% beim Docker-Compose-Prozess

http://i.imgur.com/fmlhjCo.png

so frustrierend

http://i.imgur.com/C1P6zHi.png

Übrigens funktionierte das Setup gut mit der Toolbox und lief sehr schnell ...

Mit ausführlichem Debugging kann ich sehen, dass es hier hängt

[home / docker] - $ docker-compose --verbose build app

compose.config.config.find: Verwenden von Konfigurationsdateien: ./docker-compose.yml
docker.auth.auth.load_config: Datei existiert nicht
compose.cli.command.get_client: Docker-Compose Version 1.8.0, Build f3628c7
Docker-Py-Version: 1.9.0
CPython-Version: 2.7.9
OpenSSL-Version: OpenSSL 1.0.2h 3. Mai 2016
compose.cli.command.get_client: Docker base_url: http + docker: // localunixsocket
compose.cli.command.get_client: Docker-Version: KernelVersion = 4.4.15-moby, Os = Linux, BuildTime = 2016-07-28T21: 15: 28.963402499 + 00: 00, ApiVersion = 1.24, Version = 1.12.0, GitCommit = 8eab29e, Arch = amd64, GoVersion = go1.6.3
compose.service.build: App erstellen
compose.cli.verbose_proxy.proxy_callable: Docker-Build <- (pull = False, stream = True, nocache = False, tag = u'docker_app ', buildargs = None, rm = True, forcerm = False, path =' / Users / bartdabek / Sites / docker ', dockerfile =' Dockerfile-App ')

nach ein paar minuten geht es zu

docker.api.build._set_auth_headers: Suche nach auth config
docker.api.build._set_auth_headers: Keine Auth-Konfiguration im Speicher - Laden aus dem Dateisystem
docker.auth.auth.load_config: Datei existiert nicht
docker.api.build._set_auth_headers: Keine Auth-Konfiguration gefunden

dann hängt es wieder ...

Meine Internetgeschwindigkeit ist in Ordnung, nur mit 60 MB / s getestet

Das Aktivieren von Exclude simple hostnames über die Proxy-Einstellungen hat bei mir perfekt funktioniert.

NO_PROXY=* docker-compose up

Problemumgehung gepostet von @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 funktioniert für mich.

Es wäre gut, einen Tipp von @jibingeo in Docker für Mac README.md oder irgendwo im Tutorial zu haben.

Hallo Leute, @thaJeztah.

Nachdem ich den Quellcode durchgesehen hatte, stellte ich fest, dass die Ausführung von socket.gethostbyname("localunixsocket") (in meinem Fall) mehr als 30 Sekunden dauert.

Also habe ich mein lokales DNS und Google DNS abgefragt

$ time nslookup localunixsocket 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

** server can't find localunixsocket: NXDOMAIN

real    0m30.295s
user    0m0.004s
sys     0m0.005s

$ time nslookup localunixsocket 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

** server can't find localunixsocket: NXDOMAIN

real    0m0.685s
user    0m0.005s
sys     0m0.013s

Lokales DNS funktioniert perfekt mit dem FQDN-Hostnamen

time nslookup google.com 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.196.110


real    0m0.028s
user    0m0.005s
sys 0m0.006s

Dies bedeutet, dass das eigentliche Problem beim Router-DNS liegt.

Bin ich es nur, oder scheint eine DNS-Suche nach localunixsocket intuitiv zu sein? Das scheint ein Füll-Hostname zu sein, der nur als Platzhalter verwendet wird, wenn etwas Adressen im TCP-Stil anstelle von lokalen Domain-Sockets erwartet.

In jedem Fall ist der Zeitunterschied zwischen dem lokalen DNS und dem DNS von Google interessant ... Ich wäre gespannt, warum dies so ist. (Leider muss auf dem DNS-Server, auf den der Router verweist, ein weiterer TCP-Speicherauszug vorhanden sein, um dies zu erkennen, es sei denn, es gibt ein tracert -Äquivalent für DNS-Lookups, mit denen Zwischenserver, die von einem Rekursiv betroffen sind, erhalten bleiben können Abfrage)

Dies kann auch informativ sein (gefunden in man nslookup unter Mac OS X):

Mac OS X HINWEIS

Der Befehl nslookup verwendet nicht die Auflösung des Hostnamens und der Adresse
oder die DNS-Abfrage-Routing-Mechanismen, die von anderen laufenden Prozessen verwendet werden
Mac OS X. Die Ergebnisse von Namens- oder Adressabfragen, die mit nslookup gedruckt wurden
kann von denen anderer Prozesse abweichen, die Mac OS X verwenden
native Mechanismen zur Auflösung von Namen und Adressen. Die Ergebnisse von DNS
Abfragen können sich auch von Abfragen unterscheiden, die das Mac OS X DNS-Routing verwenden
Bibliothek.

Da sie nicht wirklich klarstellen, welchen spezifischen Mechanismus nslookup _does_ im Vergleich zu Mac OS X verwendet, ist es schwierig zu sagen, ob von Docker erwartet wird, dass er das Verhalten von nslookup teilt. oder das von anderen Mac OS X-Apps ... (Ich vermute, dass es die gleichen Methoden verwendet wie nslookup , aber wir müssten uns wahrscheinlich in den Code für beide vertiefen, um das endgültig herauszufinden)

Hey @whitelynx

Hier ist der TCP-Speicherauszug, der mit lokalem DNS und Google DNS erstellt wurde. Befehl, den ich verwendet habe, um Dump zu nehmen, ist

sudo killall -HUP mDNSResponder && docker-compose ps

Mit lokalem DNS:

15:49:30.025038 IP (tos 0x0, ttl 255, id 18504, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:30.291508 IP (tos 0x0, ttl 255, id 36848, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:31.097658 IP (tos 0x0, ttl 255, id 32568, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:31.368098 IP (tos 0x0, ttl 255, id 54970, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:33.596367 IP (tos 0x0, ttl 30, id 20508, offset 0, flags [none], proto UDP (17), length 133)
    10.0.0.1.53 > 10.0.0.3.60707: [udp sum ok] 54235 NXDomain* q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. [1d] SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (105)
15:49:33.597103 IP (tos 0x0, ttl 30, id 20510, offset 0, flags [none], proto UDP (17), length 136)
    10.0.0.1.53 > 10.0.0.3.52331: [udp sum ok] 10799 NXDomain q: A? localunixsocket. 0/1/0 ns: . [2h8m4s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

Mit Google DNS:

15:45:25.301293 IP (tos 0x0, ttl 255, id 37492, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 8.8.8.8.53: [udp sum ok] 14029+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:45:25.371167 IP (tos 0x0, ttl 56, id 10269, offset 0, flags [none], proto UDP (17), length 83)
    8.8.8.8.53 > 10.0.0.3.60707: [udp sum ok] 14029 NXDomain q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/0/0 (55)
15:45:25.599570 IP (tos 0x0, ttl 255, id 7256, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.59912 > 8.8.8.8.53: [udp sum ok] 3154+ A? localunixsocket. (33)
15:45:25.702374 IP (tos 0x0, ttl 56, id 39895, offset 0, flags [none], proto UDP (17), length 136)
    8.8.8.8.53 > 10.0.0.3.59912: [udp sum ok] 3154 NXDomain q: A? localunixsocket. 0/1/0 ns: . [29m58s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

Hier kann ich ~ 3sec Verzögerung mit lokalem DNS sehen.

Hinweis: Der hier verwendete Router unterscheidet sich von dem, den ich für den vorherigen Kommentar verwendet habe

Hallo zusammen,
Nach dem Upgrade auf Docker für Mac Version 1.12.1 (build: 12133) ich das hinzufügen
127.0.0.1 localunixsocket wieder im /etc/hosts

Ich musste das tun, was Davidino auch tat.

Keine Schätzung zur Lösung dieses sehr nervigen Fehlers?

Ich musste nur 127.0.0.1 localunixsocket.lan hinzufügen, damit es funktioniert. Ich benutze macOS Sierra.

Ich weiß nicht wirklich, ob dies das gleiche Problem ist, aber die Antwort von @jibingeo hat mir geholfen.
_docker-compose_ ist auch in meiner Unternehmensumgebung mit Docker Toolbox für Windows sehr langsam. Das Konfigurieren von NO_PROXY=* hat mir ebenfalls geholfen, aber dies beeinträchtigt meinen Firmen-Proxy. Also habe ich ein wenig versucht und eine spezifischere Lösung gefunden (vorausgesetzt, Sie verwenden den Standard-Docker VirtualBox IP-Bereich 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 beschleunigt alles, sodass Compose meinen Firmenproxy nicht für interne IPs testen muss.

Verbunden? https://github.com/SeleniumHQ/docker-selenium/issues/227

@davidino Lösung des 127.0.0.1 localunixsocket in Ihr /etc/hosts das Problem für mich gelöst.

So viel schneller jetzt

Ich habe die gleichen Probleme. Ich habe versucht, mein WLAN auszuschalten und meiner Hostdatei mehrere Einträge ohne Erfolg hinzuzufügen. Ich habe das gleiche Setup auf meiner Linux-Box versucht und die Ergebnisse sind viel schneller.

Der Build scheint mit einer anständigen Geschwindigkeit zu laufen, aber sobald ich irgendwelche Anfragen an die laufenden Container stelle, ist das Ergebnis schrecklich. Etwa 30 Sekunden für jede Anfrage, egal ob es sich um eine einfache Textantwort handelt.

Ich verwende Mac OS Sierra (10.12.1) und Docker für Mac (1.12.1) mit einem Rails-Stack.

Ich bin am 10.11.6 (15G31)

Folgendes steht in meiner /etc/hosts -Datei:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
255.255.255.255 broadcasthost
::1             localhost 
127.0.0.1 localhost
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Ich bin auf Beta-Kanal Docker 1.12.3-Beta29.2 (13499)

@gardner Ich habe das zu meiner Hosts-Datei hinzugefügt und die Beta ohne Erfolg ausprobiert. Ich fange wirklich an zu denken, dass es etwas mit Sierra zu tun hat. Ich bin mir ziemlich sicher, dass es funktioniert hat, bevor ich ein Upgrade durchgeführt habe. Ich werde die Beta noch einmal versuchen, um zu sehen, ob es funktioniert. Ich werde nach dem Test wieder posten.

@gardner Gleiches Problem. Jetzt wird Docker 1.12.3-beta29.3 (13640) ausgeführt. Mein Linux-Setup läuft immer noch viel schneller mit 1/4 des RAM.

Das Beste, was ich sagen kann, ist, dass es sich um ein E / A-Problem zwischen Docker und Host-Computer handelt. Ich habe einen Flammengraphen für die Anfrage erstellt und er verbringt die meiste Zeit damit, Dateien zu lesen.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

Dies ist dieselbe App, dieselbe Anforderung, die lokal ausgeführt wird.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

Wenn ich die App so konfiguriere, dass sie im Produktionsmodus ausgeführt wird, wird sie in Docker genauso schnell ausgeführt.

Ich bin mir nicht sicher, ob dies bereits bekannt ist oder nicht, aber hoffentlich hilft es allen anderen, die zu diesem Thread kommen und versuchen, es herauszufinden.

Bearbeiten: Scheint, als wäre dies das eigentliche Problem, auf das ich stoße. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

Auch bei diesem Problem machen die Änderungen an den Hosts einen kleinen Unterschied, sind aber immer noch etwas träge.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

Ich sehe dies auf der folgenden stabilen Docker-Version unter OSX 10.11.6 mit der folgenden Docker-Version:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

Ich sehe dies auf einer langsamen Cloud-Verbindung (The Cloud in einem Café in London). Wenn ich WiFi ausschalte, ist das Verfassen sehr schnell, sonst läuft alles sehr langsam ...

Hat die neueste Version (1.9.0) anscheinend etwas für die Menschen geändert, bei denen das Problem aufgetreten ist?

@ shin- Ich habe immer noch 1.8.1 in meinem docker-compose --version mit dem neuesten Docker für Mac. Wann können wir mit einem Update rechnen?

Wann können wir eine Lösung für dieses Problem erwarten?

1.9 befindet sich im Beta-Kanal und ist sich wahrscheinlich nicht sicher, wann es im Stall ausgeliefert wird
in einer Woche oder so.

Am 18. November 2016, 8:07 Uhr, schrieb "David Richards" [email protected] :

@ shin- https://github.com/shin- Ich habe noch 1.8.1 in meinem Docker-Compose
--version mit dem neuesten Docker für Mac. Wann können wir mit einem Update rechnen?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

Für mich war McAfee Endpoint Security der Grund dafür, dass Docker-Compose sehr langsam war. Es scheint, als würde der On-Access-Scanner die Leistung beim Entpacken der Python-Umgebung, die jedes Mal auftritt, wenn Docker-Compose ausgeführt wird, wirklich beeinträchtigen.

Für mich machte das Entfernen der Suchdomäne .local den Unterschied.

@ shin- in der 1.9.0-rc4 Ich habe immer noch das Problem. Ich weiß nicht, was ich getan habe, aber vor einigen Tagen hatte ich kein Problem damit, über ein Jahr lang docker-compose zu verwenden.
docker-compose --version ist sehr schnell
docker-compose ps ist sehr langsam
Das Deaktivieren von Wifi - ps ist ebenfalls schnell

@gsong leider hat mir das nicht geholfen

Ich bekam auch plötzlich dieses Problem. Genau wie @timsuchanek benutze ich Docker-Compose seit ungefähr einem Jahr und docker-compose up hängt fast auf unbestimmte Zeit. Wie alle anderen funktioniert es, wenn ich WLAN ausschalte.

Ich bin auf docker-compose version 1.9.0, build 2585387

Bearbeiten: Durch Hinzufügen von 127.0.0.1 localunixsocket zu /etc/hosts vorerst behoben. Ich bin auf macOS 10.11.6

Wie hoch sind die Chancen, dass dies auf die in Yosemite eingeführten Änderungen von .local zurückzuführen ist?

https://support.apple.com/en-us/HT203136
https://news.ycombinator.com/item?id=9026192

Ich habe gesehen, dass @afxjzs es früher erwähnt hat , aber keine Folgemaßnahmen gesehen.

Ich bin auf etwas gestoßen, das für mich funktioniert, während ich versucht habe, xdebug zum Laufen zu bringen:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

auf dem Host-Computer.

Vielen Dank an James Cowie .

Bearbeiten: Es sieht so aus, als ob xdebug die Wurzel meines Problems war. Wenn xdebug deaktiviert ist, ist mein Docker-Computer superschnell, selbst wenn / etc / hosts im Standardzustand ist. Wenn es aktiviert ist und mein xdebug.remote_host auf 10.254.254.254 gesetzt ist, wird es langsamer. Die vorgeschlagenen Änderungen an / etc / hosts helfen nicht, aber das Festlegen des localhost-Alias ​​auf en0 wie oben behebt das Problem.

Dies passiert mir mit dem neuesten stabilen Docker für Mac (1.13.1, Docker-Compose 1.11.1).

NO_PROXY=* tun funktioniert.

Dies ist mir auch mit dem neuesten Update passiert (1.13.1, Docker-Compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 hat mein Problem behoben.

Ich habe den gleichen Fehler. Hinzufügen von localunixsocket zu /etc/hosts . funktioniert nicht. Temporärer Fix zum Markieren von Exclude simple hostnames auf der Registerkarte "Proxies".

macOS Sierra 10.12.3 (16D32)
Docker version 1.13.1, build 092cba3
docker-compose version 1.11.1, build 7c5d5e4

Ich habe festgestellt, dass nicht reagierende Suchdomänen zu einer sehr langsamen Docker-Komposition führen. Es ist nicht nur .local Ich habe .dev .

Ich habe heute das gleiche Problem mit Docker-Compose gehabt, das für immer hängt, sogar um Hilfe oder --version anzuzeigen. Ich folgte den Ratschlägen von 127.0.0.1 prod.python.map.fastly.net zu / etc-Hosts gelöst

Ziemlich komisch, finde ich?

Gleiches Problem hier. Es sieht so aus, als würde es zweimal hängen, jeweils etwa 25 Sekunden lang. Hier ist die Ausgabe von --verbose wobei jeder HANG unterbrochen wird

compose.config.config.find: Using configuration files: ./config/docker-compose-dev.yml
docker.auth.find_config_file: Trying paths: ['/Users/dorkusprime/.docker/config.json', '/Users/dorkusprime/.dockercfg']
docker.auth.find_config_file: Found file at path: /Users/dorkusprime/.docker/config.json
docker.auth.load_config: Found 'auths' section
docker.auth.parse_auth: Found entry (registry=u'https://index.docker.io/v1/', username=u'dorkusprime')

[HANGS FOR ~25S]

compose.cli.command.get_client: docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.9.13-moby, Arch=amd64, BuildTime=2017-03-15T20:28:18.193664702+00:00, ApiVersion=1.27, Version=17.03.1-ce-rc1, MinAPIVersion=1.12, GitCommit=3476dbf, Os=linux, Experimental=True, GoVersion=go1.7.5
compose.project.build: mongodb uses an image, skipping
compose.project.build: redis uses an image, skipping
compose.service.build: Building web
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag='dorkusprime/dashboard-test', buildargs=None, rm=True, forcerm=False, path='/Users/dorkusprime/repository/Dashboard-test', dockerfile=None)
docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: Sending auth config (u'https://index.docker.io/v1/')

[HANGS FOR ~25S]

compose.cli.verbose_proxy.proxy_callable: docker build -> <generator object _stream_helper at 0x105cc4910>

Ich habe die Problemumgehungen für / etc / hosts ohne nennenswerte Verbesserung ausprobiert.

Das gleiche Problem hier und keine Lösung aus dem gesamten Thread hilft mir (weder /etc/hosts noch NO_PROXY Variable noch Exclude simple hostnames noch DNS in 8.8.8.8 ändern).

Eine Sache zu beachten: Wenn ich Docker mit Sudo laufen lasse, löst es das Geschwindigkeitsproblem.

Neueste Docker-Version (Docker-Version 17.03.1-ce-rc1, Build 3476dbf). Ich habe sowohl Beta- als auch Stable-Releases ausprobiert.

docker --version benötigt in meinem Fall 32 Sekunden, um die Version auszugeben.

Dieses Problem gibt es schon seit fast einem Jahr ...

@mobileka Sprechen Sie über docker oder docker-compose ?

@ shin- In meinem Fall hat jeder einzelne CLI-Befehl (sei es docker oder docker-compose ), der sich auf Docker bezieht, eine Latenz von ungefähr 30 Sekunden, bevor er tatsächlich Ergebnisse liefert oder bevor er seine Arbeit ausführt.

@mobileka Okay - das hat definitiv nichts mit dem hier beschriebenen Problem zu Docker für Mac- Repo zu erstellen.

@ shin- Entschuldigung, ich habe nicht bemerkt, dass ich in einem falschen Repo bin, weil die "Symptome" sehr ähnlich waren: Es ist langsam, wenn die Internetverbindung aktiv ist, und es ist schnell, wenn keine Internetverbindung besteht.

Vielen Dank, ich werde ein Problem im Docker für Mac-Repo erstellen.

Ich bin mir ziemlich sicher, dass mein Herumspielen (und das anschließende Versauen) mit Consul eine Konfigurationsdatei in / etc / resolvers hinzugefügt hat. Dies verursachte ähnliche Probleme wie @seeekr , die beim localunixsocket gemeldet wurden., wie so:

A.D.*.5.>t.d............localunixsocket.foo.bar.example.com.....
14:36:13.357925 IP 10.23.45.67.65066 > 10.98.76.54.53: 25754+ A? localunixsocket.foo.bar.example.com. (54)
E..R.......P
...

Durch Entfernen der Datei aus / etc / resolvers wurde das Problem sofort behoben.

Hoffentlich hilft das!

Das gleiche Problem hier und keine Lösung aus dem gesamten Thread hilft mir (weder / etc / hosts noch NO_PROXY-Variable noch Einfache Hostnamen ausschließen oder DNS in 8.8.8.8 ändern).

Ich schreibe eine Spielzeug-Website (Logik ist wirklich einfach und sollte keine Leistungsprobleme haben) und führe sie lokal mit Docker-Compose aus. Es stellt sich heraus, dass das Laden fast jeder Seite Minuten dauert. Irgendeine Anweisung?

Die Ladezeiten Ihrer App für

MacOS Sierra, 10.12.5.
Docker Community Edition
Version 17.06.0-ce-mac18 (18433)
Kanal: stabil
d9b66511e0

Ich hatte bereits DNS als 8.8.8.8. Muss sowohl localunixsocket.local als auch localunixsocket in / etc / hosts hinzufügen. In dem Moment, in dem dies hinzugefügt wurde, erwachte meine laufende Docker-Komposition zum Leben.

Ich bin mir nicht sicher, ob dies jemandem hilft - aber ich habe dnscrypt installiert und nach dem Wechsel zu Docker Beta war Docker Compose unglaublich langsam. Die Neuinstallation von dnscrypt (über das Brühfass) hat das Problem für mich behoben.

Ich liebe dich @jewilmeer

Ich wollte das nur hier lassen. Meine Probleme waren Sitzungsdateien in meinem Build-Kontext. Die Dateien gehörten dem Apache-Benutzer und der Docker-Compose-Build hing nur nach dieser Zeile:

docker.api.build._set_auth_headers: No auth config found 

Das Traurigste ist, dass ich vor langer Zeit keine dateibasierten Sitzungen mehr verwendet habe. Sollte wahrscheinlich ab und zu meinen Arbeitsbereich reinigen.

Der Grund für den Kommentar: Es wäre wirklich schön, wenn das Komponieren nicht einfach hängen würde. Ich habe den Täter nur mit Docker Build direkt herausgefunden, was mich gut über meine Probleme informiert hat.

@paali kannst du

@ Vad1mo Mein komplettes Setup ist ziemlich komplex (und chaotisch und in Bearbeitung), aber die grundlegenden Teile sind Symfony2-Projekte. Hatte alte Sitzungsdateien im Ordner ./app/sessions, die dem Apache-Benutzer gehörten (vor Docker-Zeiten).

Grundsätzlich hatte ich
COPY app app/
on on der Dockerfiles und docker-compose.yml, um die entsprechende Dockerfile zu erstellen.
Der verwendete Befehl:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

Wie bereits erwähnt, hat der Erstellungsprozess nie wirklich begonnen, sondern ist nach den Zeilen über Auth-Header eingefroren. Das direkte Bauen auf Docker gab mir:

> docker build -f thefile --no-cache --force-rm
error checking context: 'no permission to read from '/path/to/my/project/app/sessions/sess_n8turtujft1bipv745khqsqbi1''.

Das nächste Mal werde ich Docker sofort ausprobieren, aber nichts schien wirklich darauf hinzudeuten, was das eigentliche Problem war. Ich bin auf Docker für Mac 7.06.1-ce-mac24.

Gibt es ein Wort zu einer echten Lösung für dieses Problem, außer dass Sie jedem sagen müssen, dass er eine Host-Regel hinzufügen oder Proxys deaktivieren soll?

+1

+1

+1

Für mich wurde das Problem behoben, indem ich zu meinen Systemeinstellungen / Netzwerk / Erweitert / DNS / Suchdomänen ging und den Eintrag ".local" entfernte. was ich dort hingelegt hatte. Dies führte dazu, dass das macOS die Suchdomänen nur mit dem Standardwert "localdomain" füllte. Und dann docker-compose wieder.

docker selbst reagierte die ganze Zeit.

Ich weiß es nicht, aber ich würde vermuten, dass docker eine Systemressource unter Verwendung einer IP-Adresse oder eines stabilen lokalen Namens korrekt findet, während docker-compose unsicher auf localdomain angewiesen ist

Ich würde die Zeile ausführen, um DNS zu überwachen, die sich im ursprünglichen Beitrag zum Fix befand:

sudo tcpdump -A -s0 -nni en0 Port 53

Das zeigte mir, dass ich meiner Hostdatei Folgendes hinzufügen musste:

127.0.0.1 localunixsocket.localdomain

scheint sich etwas von .local zu .localdomain geändert zu haben?

Ich habe seitdem eine Neuinstallation von 10.12 Sierra durchgeführt. Ich habe Docker neu installiert und konnte das Problem nicht reproduzieren.

Ich bin heute, meinem ersten Tag auf dem Mac, auf dieses Problem gestoßen.
Docker Compose wurde gerade blockiert, buchstäblich nachdem die Zeile in das /etc/hosts eingefügt wurde, begann es wie erwartet zu funktionieren.
Ich habe WiFi verwendet , jeder im Büro mit derselben Ethernet-Version hat noch nie von diesem Problem gehört.
Docker: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

Gleicher Fehler hier. Ich muss die drei Zeilen zu / etc / hosts hinzufügen, um dieses Problem zu lösen.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Gleicher Fehler. Das hat bei mir funktioniert.

$ sudo tcpdump -vvv -s 0 -l -n port 53
...
13:46:10.203734 IP (tos 0x0, ttl 255, id 7224, offset 0, flags [none], proto UDP (17), length 81, bad cksum 0 (->7b21)!)
    10.64.14.244.54683 > 10.0.0.10.53: [bad udp cksum 0x2491 -> 0xf39b!] 30038+ A? localunixsocket.*.svc.cluster.local. (53)

$ sudo vim /etc/hosts

# hacks for docker
127.0.0.1 localunixsocket.*.svc.cluster.local

Ich habe 127.0.0.1 localunixsocket in /etc/hosts hinzugefügt und es hat bei mir funktioniert, danke!
(aber es ist immer noch ein WTF-Fehler)

Immer noch ein Problem mit der neuesten Version. Die obigen Korrekturen scheinen nichts für mich zu tun, irgendwann wird es einfach so langsam, dass es hängt. Die Problemumgehung für mich besteht darin, Docker für Mac von Zeit zu Zeit neu zu starten.

Bestätigt, dass 127.0.0.1 localunixsocket in /etc/hosts Dinge dramatisch beschleunigt, bitte korrigieren!

Das Hinzufügen von 127.0.0.1 localunixsocket in /etc/hosts hilft. Ich benutze docker-compose version 1.18.0, build 8dd22a9

Die von @norbertsienkiewicz empfohlene Lösung docker-compose up von über 10 Minuten auf weniger als eine Minute gesenkt (Version 1.18.0).

Ich bin eigentlich neugieriger, warum dies überhaupt passiert ist. Es erscheint mir ein bisschen albern, meine Hosts-Datei als Problemumgehung für ein kürzlich eingeführtes Problem ändern zu müssen und es als "Lösung" deklarieren zu lassen.

Hier ist die Rückverfolgung, die die falsche DNS-Suche verursacht:

  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/daemon.py", line 88, in info
    return self._result(self._get(self._url("/info")), True)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/utils/decorators.py", line 46, in inner
    return f(self, *args, **kwargs)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/client.py", line 193, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 521, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 499, in request
    prep.url, proxies, stream, verify, cert
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 672, in merge_environment_settings
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 692, in get_environ_proxies
    if should_bypass_proxies(url, no_proxy=no_proxy):
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 676, in should_bypass_proxies
    bypass = proxy_bypass(netloc)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1487, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1453, in proxy_bypass_macosx_sysconf
    hostIP = socket.gethostbyname(hostonly)

Ich hatte gerade dieses Problem, nachdem ich von drahtlos zu kabelgebunden gewechselt hatte. Zurück zu Wireless und alles ist in Ordnung mit der Welt.

Sind die Änderungen an / etc / host auf dem Host-Computer oder dem Docker-Container?

Welche Hosts-Datei soll geändert werden?

1. MacOS-Hosts-Datei?
2. Die Linux-VM, die als Docker-Host dient?
3. Der Container selbst?

Ich weiß nicht warum, aber ich musste jedes lokale Domänenelement entfernen, damit es funktioniert.

/ etc / hosts:
127.0.0.1 localunixsocket

Genius!!!