Compose: docker-compose lent sur docker pour mac os beta

ping @frenchben : sourire:

+1

a eu le même problème: D

@ smith64fx problème disparaît également si vous éteignez votre WiFi?

@stijn Oui, quand je désactive le wifi, tout fonctionne comme du charme

Von meinem iPhone gesendet

Suis 05.05.2016 à 00:26 schrieb Sebastiaan van Stijn [email protected] :

@ smith64fx problème disparaît également si vous éteignez votre WiFi?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

@ smith64fx Je vois d'après votre signature que vous venez probablement d'Allemagne (ou d'Autriche / de Suisse). Voulez-vous me demander quel est votre fournisseur d'accès Internet? Je me demande si nous avons le même, et si cela pourrait provenir de la boîte qui ne ressemble pas à un très bon matériel / logiciel et n'agirait pas comme le pense docker.

(Je suis avec Vodafone et j'ai leur easybox-peu importe)

Même problème sur un réseau filaire (réseau d'entreprise), dès que je le débranche, tout est très rapide. Je suis donc certain que ce n'est pas lié à votre fournisseur spécifique.

J'ai regardé la sortie verbeuse, il n'y a pas d'erreur évidente (ni nulle part dans les journaux système). J'ai remarqué ceci cependant:

Sans mise en réseau, ces lignes sont regroupées:

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

Sans réseau, j'obtiens ~ 100-200 lignes de 'compose.parallel.feed_queue: Pending: set ([])' entre l'attache <- et l'endroit où elle retourne avec attach -> ...

Avant ce point, il se passe beaucoup plus de choses avec le réseau, mais surtout juste plus d'appels pour inspecter l'image, etc.

J'ai joint la sortie de compose --verbose up pour les situations de bot. Le fichier de composition est juste deux conteneurs directement à partir du hub.

with-networking.txt
without-networking.txt

@holstvoogd oh, d'accord pour le fournisseur. Merci pour l'info, j'étais un peu inquiet :)

@Erwyn @ smith64fx Pour confirmer, vous êtes toujours connecté (câblé) et en même temps utilisez le même réseau avec wifi?

@FrenchBen Non, c'est uniquement dans le réseau wifi de ma maison. Dans mon bureau, c'est super rapide. Mais le fait est que tout le reste à la maison tourne vite, sauf docker-compose ^ _ ^ "

@FrenchBen identique à @ smith64fx. Il n'y a que le wifi à la maison, donc il n'y a pas de connexion filaire impliquée. Et comme je peux le voir, @holstvoogd semble avoir le même problème avec une connexion filaire.

Je remarque le même problème avec Docker pour Mac Beta. docker-compose up est lent lorsque le Wi-Fi est activé, rapide lorsque le Wi-Fi est désactivé.

• Version de Docker Compose: version 1.7.1 de docker-compose, build 0a9ab35
• Version Docker: version 1.11.1 de Docker, build 5604cbe
• Version du système d'exploitation: OS X El Capitan 10.11.4

Salut, Y a-t-il des nouvelles à ce sujet?

J'ai le même problème. Les versions de Compose / Docker / OSX sont identiques à celles de @eugenesia .
J'utilise le WiFi à la maison et au bureau et chez moi, cela fonctionne incroyablement lentement. Au bureau, cela fonctionne comme prévu (rapide).

Je pensais que c'était peut-être quelque chose lié au serveur DNS de mon FAI (les fournisseurs Internet à domicile et au bureau sont différents) et j'ai essayé d'utiliser un DNS public, y compris celui de Google, mais cela n'a pas aidé.

Si je désactive le WiFi, alors docker-compose fonctionne très vite

@KryDos Une nouvelle version devrait sortir cette semaine avec quelques améliorations de vitesse

J'ai le même problème, après la mise à jour vers docker pour mac 1.11.1-beta13, le problème persiste. La solution de contournement en éteignant et rallumant le (s) réseau (s) ne fonctionne plus, les services démarrent rapidement lors de la désactivation du réseau, mais lors de la remise sous tension du réseau, les services ne sont plus accessibles et le démon docker ne répond pas

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

• Version de Docker Compose: version 1.7.1 de docker-compose, build 0a9ab35
• Version de Docker: version 1.11.1-beta13 de Docker, build 7975
• Version du système d'exploitation: OS X El Capitan 10.11.5

J'ai eu les mêmes problèmes et j'ai trouvé un message (désolé, j'ai perdu la référence) mentionnant que docker-compose essaie de résoudre localunixsocket.local . Vous pouvez obtenir un aperçu de la recherche DNS en exécutant sudo tcpdump -A -s0 -nni en0 port 53

Pour l'instant, j'ai pointé localunixsocket.local vers localhost dans mon /etc/hosts . Maintenant, tout est à nouveau rapide.

127.0.0.1 localunixsocket.local

Merci @jewilmeer , cela semble utile

Je suis revenu en utilisant virtualbox avec docker-machine. Le problème n'existe pas et il est jusqu'à 10 fois plus rapide que Docker Mac Beta!

@ smith64fx veuillez garder vos commentaires constructifs; c'est une version bêta, ce n'est pas encore un produit fini, donc des bugs et des problèmes de performances sont attendus. C'est exactement ce genre de problèmes qui nécessitent des rapports (et des tests) pour les résoudre.

commentaire super génial, @jewilmeer! Pour moi, j'ai dû ajouter quelques adresses supplémentaires à / etc / hosts que j'ai découvertes en utilisant votre commande 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

Après ces ajouts - rapide! En fait, incroyablement rapide, cela semble beaucoup plus rapide que lors de l'utilisation de Docker Toolbox! woop woop :) (Bien que cela puisse être une observation très subjective!)

C'est assez étrange, mais semble indiquer quel est le problème sous-jacent ...

Je suis actuellement confronté au même problème et je ne peux pas résoudre le problème.
J'ai essayé les suggestions précédentes pour modifier /etc/hosts . Sur notre réseau de bureaux, docker est extrêmement lent. Sur les réseaux domestiques ou l'utilisation de la connexion à un téléphone portable supprime tous les ralentissements et tout est accrocheur.

Nous utilisons docker-compose avec un conteneur Web lié à quatre conteneurs de services (postgres, redis, rabbitmq, elasticsearch). La connexion à l'un des quatre conteneurs de services directement depuis OSX est très bien. Ce n'est que lent lorsque vous essayez de vous connecter du conteneur Web à l'un des conteneurs de service.

Lancer tcpdump -vvv -s 0 -l -n port 53 donne la sortie suivante lorsqu'il est connecté à un téléphone portable

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)

et voici la sortie lorsque sur notre wifi de bureau:

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)

Cela ressemble donc à quelque chose avec une recherche DNS inversée, mais je ne sais pas comment le dépanner. La désactivation du wifi garantit également cette lenteur. La désactivation et la réactivation n'aident pas.

Bien sûr, vous trouvez votre propre solution juste après avoir posé la question. Il ressemble à un package installé dans notre environnement de développement mis à jour les paramètres DNS dans OSX qui causent le problème. Une fois que j'ai réinitialisé le DNS OSX pour utiliser les valeurs par défaut dans /etc/resolv.conf, tout fonctionne.

Cela pourrait-il être lié au problème avec Bonjour «possédant» .local et un bogue IPV6?
détails: https://news.ycombinator.com/item?id=11567442

Je ne sais pas si cela aide mais j'avais l'habitude d'avoir ce problème et je l'ai résolu en changeant mes serveurs DNS en 8.8.8.8 et 8.8.4.4 .

De plus, ce problème ne s'est produit que sur mon réseau domestique. Au travail, je n'avais pas ce problème.

Je suis également confronté au même problème même après avoir essayé le correctif de
docker-compose up fonctionne bien sur le réseau de mon bureau, mais cela prend environ 7 minutes sur mon réseau domestique.
même comportement avec d'autres commandes de docker-compose comme stop, pull, ps etc.

docker --version
Docker version 1.12.0-rc2, build 906eacd, expérimental

docker-compose --version
docker-compose version 1.8.0-rc1, build 9bf6bc6

docker-machine - version
docker-machine version 0.8.0-rc1, build fffa6c9

Je ne sais pas pourquoi, mais j'ai dû supprimer tout élément de domaine local pour le faire fonctionner.

/ etc / hosts:
127.0.0.1 localunixsocket

J'ai un problème très similaire, mais je pense qu'il peut être lié à mon utilisation de DNSCrypt ?

@Erwyn J'ai également rencontré le même problème avec Vodafone Easybox ...
il s'est avéré que Vodafone Easybox lie la recherche des domaines .local au routeur (pour évaluer le nom d'hôte dynamique de votre routeur, à savoir easy.box )
et je suppose que cette liaison faisait attendre docker-compose la réponse du routeur (je me trompe peut-être complètement à ce sujet) ...
mais en ajoutant
127.0.0.1 localunixsocket.local à etc/hosts résolu le problème pour moi

Salut les gars,
127.0.0.1 localunixsocket à etc / hosts a résolu le problème pour moi

@davidino Thx Bro, fonctionne parfaitement! Je suis intéressé pourquoi nous avons besoin de cette solution de contournement?

Bonjour gars! Même problème ici. Au Brésil, l'utilisation du wifi au bureau prend beaucoup de temps pour démarrer. Après avoir changé les fichiers /etc/hosts , tout a bien fonctionné.

Même problème ici. Travailler à partir d'un bureau (sur WIFI) Je n'ai aucun problème ou retard. En travaillant dans un bureau différent (également sur WIFI), j'obtiendrais des retards d'environ 10 minutes.

Ajouter 127.0.0.1 localunixsocket à /etc/hosts n'a _pas_ résolu le problème pour moi. J'ai essayé de le faire en combinaison avec un redémarrage, mais toujours pas de chance.

L'ajout de 8.8.8.8 et 8.8.4.4 tant que serveurs DNS a résolu le problème.

Merci @Typositoire!

Hé, @dadarek , essayez d'ajouter 127.0.0.1 localunixsocket.home <hostname>.home dans votre fichier hosts. Cela a fonctionné pour moi lorsque j'ai ajouté les deux noms d'hôte. Vous pouvez donc toujours utiliser votre DNS local, si vous en avez besoin ...

Cela se produit pour moi à la fois sur le canal stable et bêta, la déconnexion d'Internet ou l'ajout de l'entrée d'hôte le corrige pour moi.

El Capitan 10.11.4
Docker version 1.12.0, build 8eab29e, expérimental
docker-compose version 1.8.0, build f3628c7
docker-machine version 0.8.0, build b85aac1

J'ai essayé à la fois le nom d'hôte et la déconnexion d'Internet sur une commande de construction et rien n'aide ... j'ai également essayé le changement DNS ... il reste juste là pendant 5 à 10 minutes, puis démarre le processus de construction ... Je peux voir l'utilisation du processeur aller jusqu'à 100% sur le processus de composition de docker

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

Si frustrant

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

btw la configuration a bien fonctionné avec la boîte à outils et a fonctionné très rapidement ...

avec un débogage détaillé, je peux le voir suspendu ici

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

compose.config.config.find: Utilisation des fichiers de configuration: ./docker-compose.yml
docker.auth.auth.load_config: le fichier n'existe pas
compose.cli.command.get_client: docker-compose version 1.8.0, build f3628c7
version docker-py: 1.9.0
Version CPython: 2.7.9
Version OpenSSL: OpenSSL 1.0.2h 3 mai 2016
compose.cli.command.get_client: Docker base_url: http + docker: // localunixsocket
compose.cli.command.get_client: Version Docker: 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: Création d'une application
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 ')

après quelques minutes, il passe à

docker.api.build._set_auth_headers: recherche de la configuration d'authentification
docker.api.build._set_auth_headers: Pas de configuration d'authentification en mémoire - chargement depuis le système de fichiers
docker.auth.auth.load_config: le fichier n'existe pas
docker.api.build._set_auth_headers: Aucune configuration d'authentification trouvée

puis il se bloque à nouveau ...

ma vitesse Internet est correcte, juste testée à 60 Mo / s

activer Exclude simple hostnames partir des paramètres proxy a parfaitement fonctionné pour moi.

NO_PROXY=* docker-compose up

Solution de contournement publiée par @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 fonctionne pour moi.

Ce serait bien d'avoir un conseil de @jibingeo dans Docker pour Mac README.md ou quelque part dans le tutoriel.

Bonjour les gars, @thaJeztah.

Après avoir parcouru le code source, j'ai trouvé que l'exécution de socket.gethostbyname("localunixsocket") prend plus de 30 secondes (dans mon cas).

J'ai donc interrogé mon DNS local et Google DNS

$ 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

Le DNS local fonctionne parfaitement avec le nom d'hôte FQDN

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

Cela signifie que le problème réel est lié au DNS du routeur.

Est-ce juste moi, ou est-ce que faire une recherche DNS pour localunixsocket semble contre-intuitif? Cela ressemble à un nom d'hôte de remplissage qui est simplement utilisé comme espace réservé lorsque quelque chose attend des adresses de style TCP au lieu de sockets de domaine locaux.

Quoi qu'il en soit, la différence de temps entre le DNS local et le DNS de Google est intéressante ... Je serais curieux de savoir ce qui le pousse à faire cela. (malheureusement, je pense que vous devrez avoir un autre vidage TCP sur le serveur DNS pointé par le routeur pour le dire, à moins qu'il n'y ait un équivalent tracert pour les recherches DNS qui peuvent préserver les serveurs intermédiaires touchés par un récursif requete)

Cela peut également être informatif (trouvé dans man nslookup sur Mac OS X):

AVIS Mac OS X

La commande nslookup n'utilise pas le nom d'hôte et la résolution d'adresse
ou les mécanismes de routage des requêtes DNS utilisés par d'autres processus exécutés sur
Mac OS X. Les résultats des requêtes de nom ou d'adresse imprimés par nslookup
peuvent différer de ceux trouvés par d'autres processus utilisant Mac OS X
mécanismes natifs de résolution de noms et d'adresses. Les résultats du DNS
les requêtes peuvent également différer des requêtes qui utilisent le routage DNS de Mac OS X
bibliothèque.

Comme ils ne donnent pas vraiment de précisions sur le mécanisme spécifique utilisé par nslookup _does_ par rapport à ce que Mac OS X fournit, il est difficile de dire si Docker devrait partager le comportement de nslookup , ou celle d'autres applications Mac OS X ... (je suppose qu'il utilise les mêmes méthodes que nslookup , mais nous aurions probablement à fouiller dans le code pour les deux pour le comprendre définitivement)

Hé @whatelynx

Voici le vidage TCP effectué avec le DNS local et le DNS Google. La commande que j'avais l'habitude de prendre est

sudo killall -HUP mDNSResponder && docker-compose ps

Avec DNS local:

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)

Avec 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)

Ici, je peux voir un délai d'environ 3 secondes avec le DNS local.

Remarque: le routeur que j'ai utilisé ici est différent de celui que j'ai utilisé pour les commentaires précédents

Salut à tous,
après la mise à niveau vers docker pour mac Version 1.12.1 (build: 12133) j'ai dû ajouter le
127.0.0.1 localunixsocket nouveau dans le /etc/hosts

Je devais aussi faire ce que Davidino a fait.

Pas d'estimation sur la résolution de ce bug très ennuyeux?

Je devais juste ajouter 127.0.0.1 localunixsocket.lan pour que cela fonctionne. J'utilise macOS Sierra.

Je ne sais pas vraiment si c'est le même problème, mais la réponse de @jibingeo m'a aidé.
_docker-compose_ est également très lent dans mon environnement d'entreprise en utilisant Docker Toolbox pour Windows. La configuration de NO_PROXY=* m'a également aidé, mais cela interfère avec le proxy de mon entreprise. J'ai donc essayé un peu et j'ai trouvé une solution plus spécifique (en supposant que vous utilisez la plage d'adresses IP par défaut du docker VirtualBox 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 accélère tout, donc compose n'a pas besoin d'essayer le proxy de mon entreprise pour les adresses IP internes.

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

@davidino solution 127.0.0.1 localunixsocket dans votre /etc/hosts résolu le problème pour moi.

Tellement plus vite maintenant

J'ai les mêmes problèmes. J'ai essayé de désactiver mon wifi, en ajoutant plusieurs entrées à mon fichier hôte sans succès. J'ai essayé la même configuration sur ma machine Linux et les résultats sont beaucoup plus rapides.

La construction semble fonctionner à une vitesse décente, mais une fois que je fais des demandes dans les conteneurs en cours d'exécution, le résultat est horrible. Environ 30 secondes pour toute demande, qu'il s'agisse même d'une simple réponse textuelle.

J'utilise Mac OS Sierra (10.12.1) et Docker pour Mac (1.12.1) avec une pile Rails.

Je suis sur 10.11.6 (15G31)

Voici ce que contient mon fichier /etc/hosts :

##
# 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

Je suis sur le docker du canal bêta 1.12.3-beta29.2 (13499)

@gardner J'ai ajouté cela à mon fichier d'hôtes et j'ai essayé la version bêta sans succès. Je commence vraiment à penser que c'est quelque chose à voir avec Sierra. Je suis presque sûr que cela fonctionnait avant la mise à niveau. Je vais essayer de nouveau la version bêta pour voir si cela fonctionne. Je posterai à nouveau après avoir testé.

@gardner Même problème. Exécute maintenant Docker 1.12.3-beta29.3 (13640). Ma configuration Linux est toujours beaucoup plus rapide avec 1 / 4ème de RAM.

Le mieux que je puisse dire, c'est qu'il s'agit d'un problème d'E / S entre le docker et la machine hôte. J'ai exécuté un graphe de flamme sur la demande et il passe la plupart de son temps à lire des fichiers.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

C'est la même application, la même demande, exécutée localement.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

Si je configure la configuration de l'application pour qu'elle s'exécute en mode production, elle s'exécute tout aussi rapidement à l'intérieur de Docker.

Je ne sais pas si cela est déjà connu ou non, mais j'espère que cela aidera quiconque à venir sur ce fil pour essayer de le comprendre.

Edit: On dirait que c'est le vrai problème que je rencontre. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

Également confronté à ce problème, les modifications apportées aux hôtes font une petite différence, mais restent un peu lentes.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

Je vois cela sur la version de docker stable suivante exécutant OSX 10.11.6 avec la version de docker suivante:

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

Je vois cela sur une connexion cloud lente (Le Cloud dans un café à Londres), quand je désactive le WiFi, la composition est super rapide, sinon tout tourne très lentement ...

La dernière version (1.9.0) semble-t-elle changer quelque chose pour les personnes rencontrant le problème?

@ shin- J'ai toujours 1.8.1 dans mon docker-compose --version avec le dernier Docker pour Mac. Quand pouvons-nous nous attendre à une mise à jour?

Quand pouvons-nous espérer une résolution de ce problème?

1.9 est dans le canal bêta, je ne sais pas quand il sera disponible en version stable, probablement
dans une semaine environ.

Le 18 novembre 2016, à 8 h 07, "David Richards" [email protected] a écrit:

@ shin- https://github.com/shin- J'ai toujours 1.8.1 dans mon docker-compose
--version avec le dernier Docker pour Mac. Quand pouvons-nous nous attendre à une mise à jour?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

Pour moi, McAfee Endpoint Security était la raison pour laquelle la composition de docker était très lente. On dirait que l'analyseur à l'accès tue vraiment les performances de décompression de l'environnement python qui semblent se produire chaque fois que docker-compose est exécuté.

Pour moi, la suppression du domaine de recherche .local fait toute la différence.

@ shin- dans le 1.9.0-rc4 J'ai toujours le problème. Je ne sais pas ce que j'ai fait, mais il y a quelques jours, je n'ai pas eu le problème, en utilisant docker-compose pendant plus d'un an.
docker-compose --version est vraiment rapide
docker-compose ps est très lent
Désactiver le Wi-Fi - ps est également rapide

@gsong malheureusement cela ne m'a pas aidé

J'ai aussi soudainement commencé à avoir ce problème. Tout comme @timsuchanek, j'utilise docker-compose depuis environ un an maintenant et docker-compose up bloque presque indéfiniment. Comme tout le monde, lorsque je désactive le wifi, cela fonctionne.

Je suis sur docker-compose version 1.9.0, build 2585387

Edit: L'ajout de 127.0.0.1 localunixsocket à /etc/hosts corrigé pour le moment. Je suis sous macOS 10.11.6

Quelles sont les chances que cela soit dû aux changements .local introduits dans yosemite?

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

J'ai vu que @afxjzs en avait parlé plus tôt mais je n'ai vu aucun suivi.

Je suis tombé sur quelque chose qui fonctionne pour moi, en essayant de faire fonctionner xdebug:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

sur la machine hôte.

Merci à James Cowie .

Edit: Il semble que xdebug était la racine de mon problème. Avec xdebug désactivé, ma machine docker est ultra-rapide, même avec / etc / hosts dans son état par défaut. Lorsqu'il est activé et que mon xdebug.remote_host est défini sur 10.254.254.254, il ralentit jusqu'à une exploration. Les modifications suggérées pour / etc / hosts n'aident pas, mais la définition de l'alias localhost sur en0 comme ci-dessus résout le problème.

Cela m'arrive avec le dernier Docker stable pour Mac (1.13.1, docker-compose 1.11.1)

Faire NO_PROXY=* fonctionne.

Cela m'est également arrivé avec la dernière mise à jour (1.13.1, docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 a résolu mon problème.

J'ai la même erreur. Ajout de localunixsocket à /etc/hosts . n'a pas marché. Correction temporaire marquant le Exclude simple hostnames dans l'onglet proxies.

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

J'ai remarqué que tous les domaines de recherche non réactifs entraînent une composition de docker très lente. Ce n'est pas seulement .local j'utilisais .dev .

J'ai rencontré le même problème aujourd'hui avec docker-compose suspendu pour toujours, même pour afficher l'aide ou --version. J'ai suivi les conseils de @jewilmeer sur l'utilisation de tcpdump et dans mon cas, le problème a été résolu en ajoutant 127.0.0.1 prod.python.map.fastly.net aux hôtes / etc

Assez bizarre, je pense?

Même problème ici. On dirait qu'il se bloque deux fois, chacun pendant environ 25 secondes. Voici la sortie --verbose avec chaque HANG interjecté

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>

J'ai essayé les solutions de contournement / etc / hosts sans aucune amélioration notable.

Le même problème ici et aucune solution de l'ensemble du thread ne m'aide (ni /etc/hosts ni NO_PROXY variable ni Exclude simple hostnames ni changer DNS en 8.8.8.8 ).

Une chose à noter: si j'exécute docker avec sudo, cela résout le problème de vitesse.

Dernière version de Docker (Docker version 17.03.1-ce-rc1, build 3476dbf). J'ai essayé les versions bêta et stable.

docker --version prend 32 secondes pour afficher la version dans mon cas.

Ce problème existe depuis presque un an maintenant ...

@mobileka Parlez -vous de docker ou docker-compose ?

@ shin- Dans mon cas, chaque commande cli (que ce soit docker ou docker-compose ) liée à docker a une latence d'environ 30 secondes avant de donner des résultats ou avant de commencer à faire son travail.

@mobileka Okay - ce n'est certainement pas lié au problème décrit ici. Envisagez plutôt de créer un problème sur le dépôt Docker pour Mac .

@ shin- Désolé, je n'ai pas réalisé que je suis dans un mauvais repo car les "symptômes" étaient très similaires: c'est lent quand la connexion Internet est active et c'est rapide quand il n'y a pas de connexion Internet.

Merci, je vais créer un problème dans le dépôt Docker pour Mac.

Au cas où cela toucherait quelqu'un d'autre, je suis à peu près sûr que mon jeu (et mes erreurs ultérieures) avec Consul a ajouté un fichier de configuration dans / etc / resolvers. Cela provoquait des problèmes similaires à @seeekr signalés lors de l'affichage de localunixsocket., ainsi:

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
...

La suppression du fichier de / etc / resolvers a résolu le problème immédiatement.

J'espère que ça t'as aidé!

Le même problème ici et aucune solution de l'ensemble du thread ne m'aide (ni / etc / hosts ni variable NO_PROXY, ni exclure les noms d'hôte simples ni changer DNS en 8.8.8.8).

J'écris un site Web de jouets (la logique est vraiment simple et ne devrait avoir aucun problème de performance) et je l'exécute localement en utilisant docker-compose. Il s'avère que presque chaque page prend quelques minutes à se charger. Des instructions?

Les temps de chargement des pages

MacOS Sierra, 10.12.5.
Édition communautaire Docker
Version 17.06.0-ce-mac18 (18433)
Canal: stable
d9b66511e0

J'avais déjà DNS en tant que 8.8.8.8. Nécessaire pour ajouter à la fois localunixsocket.local et localunixsocket dans / etc / hosts. À l'instant où cela a été ajouté, mon docker-compose a pris vie.

Je ne sais pas si cela aide quelqu'un - mais j'ai installé dnscrypt et après le passage à la version bêta de docker, docker compose était incroyablement lent. La réinstallation de dnscrypt (via brew cask) a résolu le problème pour moi.

Je t'aime @jewilmeer

Je voulais juste laisser ça ici. Mes problèmes étaient les fichiers de session dans mon contexte de construction. Les fichiers appartenaient à l'utilisateur apache et la construction de docker-compose se bloquerait juste après cette ligne:

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

Le plus triste, c'est que j'ai arrêté d'utiliser des sessions basées sur des fichiers il y a longtemps. Devrait probablement nettoyer mon espace de travail de temps en temps.

La raison du commentaire: ce serait vraiment bien si composer ne se bloque pas. Je n'ai découvert le coupable qu'en utilisant directement docker build, ce qui m'a bien informé de mes problèmes.

@paali pouvez-vous expliquer ce que vous avez fait exactement?

@ Vad1mo ma configuration complète est assez complexe (et désordonnée et en cours) mais les parties de base sont le projet Symfony2. Avait d'anciens fichiers de session sur le dossier ./app/sessions qui appartenaient à l'utilisateur apache (avant les heures de docker).

Fondamentalement, j'avais
COPY app app/
sur l'un des Dockerfiles et docker-compose.yml pour construire le Dockerfile correspondant.
La commande utilisée:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

Comme indiqué, le processus de construction n'a jamais vraiment démarré mais s'est figé après les lignes sur les en-têtes d'authentification. Faire construire sur docker m'a directement donné:

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

La prochaine fois, je saurai essayer docker directement tout de suite, mais rien ne semblait vraiment indiquer quel était le vrai problème. Je suis sur Docker pour Mac 7.06.1-ce-mac24.

Un mot sur une vraie solution à cela autre que de devoir dire à tout le monde d'ajouter une règle d'hôte ou de désactiver les proxys?

+1

+1

+1

Ce qui a résolu le problème pour moi était d'aller dans mes Préférences Système / Réseau / Avancé / DNS / Domaines de recherche et de supprimer l'entrée ".local". que j'avais mis là. Cela a amené macOS à remplir les domaines de recherche uniquement avec la valeur par défaut, "localdomain". Et puis docker-compose est redevenu responsive.

docker lui-même était réactif tout le temps.

Je ne sais pas, mais j'imagine que peut-être docker trouve correctement une ressource sur le système en utilisant une adresse IP ou un nom local stable, tandis que docker-compose dépend pas en toute sécurité de localdomain étant toujours défini comme l'un des domaines de recherche. Mais je sais pas!

J'exécuterais la ligne pour surveiller les DNS qui figuraient dans le message d'origine sur le correctif:

sudo tcpdump -A -s0 -nni en0 port 53

Cela m'a montré que ce que je devais ajouter à mon fichier hôte était:

127.0.0.1 localunixsocket.localdomain

semble que quelque chose a changé de .local à .localdomain?

J'ai depuis fait une nouvelle installation de 10.12 Sierra. J'ai réinstallé le docker et je n'ai pas pu reproduire le problème.

J'ai rencontré ce problème aujourd'hui, mon premier jour sur Mac.
Docker compose était juste bloqué, littéralement après avoir inséré la ligne dans le /etc/hosts il a commencé à fonctionner comme prévu.
J'utilisais le WiFi , tout le monde au bureau avec la même version sur Ethernet n'a même jamais entendu parler de ce problème.
Docker: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

Même bug ici. Je dois ajouter les trois lignes à / etc / hosts pour résoudre ce problème.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Même bug. Cela a fonctionné pour moi.

$ 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

J'ai ajouté 127.0.0.1 localunixsocket dans /etc/hosts et cela a fonctionné pour moi, merci!
(mais c'est toujours un bug wtf)

Encore un problème sur la dernière version. Les correctifs ci-dessus ne semblent rien faire pour moi, à un moment donné, cela devient tellement lent qu'il se bloque. La solution de contournement pour moi est de redémarrer Docker pour mac de temps en temps.

Confirmé que 127.0.0.1 localunixsocket in /etc/hosts accélère considérablement les choses, veuillez corriger!

ajouter 127.0.0.1 localunixsocket dans /etc/hosts aide. J'utilise docker-compose version 1.18.0, build 8dd22a9

La solution recommandée par @norbertsienkiewicz a parfaitement fonctionné pour moi. Il a fait passer mon temps docker-compose up de plus de 10 minutes à moins d'une minute (version 1.18.0).

Je suis en fait plus curieux de savoir pourquoi cela a commencé à se produire. Il me semble un peu idiot de devoir modifier mon fichier hosts comme solution de contournement à un problème qui a été récemment introduit et de le faire déclarer comme étant la «solution».

Voici le backtrace qui provoque la recherche DNS parasite:

  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)

Je viens d'avoir ce problème après le passage du sans fil au filaire. De retour au sans fil et tout va bien dans le monde.

Les modifications apportées à / etc / host sont-elles apportées à la machine hôte ou au conteneur docker?

Quel fichier d'hôtes modifier?

1. Fichier hôtes macOS?
2. La VM Linux servant d'hôte docker?
3. Le conteneur lui-même?

Je ne sais pas pourquoi, mais j'ai dû supprimer tout élément de domaine local pour le faire fonctionner.

/ etc / hosts:
127.0.0.1 localunixsocket

Génie!!!