Compose: docker-compose lento en docker para mac os beta

ping @frenchben : sonrisa:

+1

tengo el mismo problema: D

¿El problema de

@stijn Sí, cuando

Von meinem iPhone gesendet

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

¿El problema de

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

@ smith64fx Veo por su firma que probablemente sea de Alemania (o Austria / Suiza). ¿Te importa que te pregunte cuál es tu proveedor de Internet? Me pregunto si tenemos lo mismo, y si podría provenir de la caja que no parece una muy buena pieza de hardware / software y no actuaría como pensaba la ventana acoplable.

(Estoy con Vodafone y tengo su easybox-lo que sea)

El mismo problema en una red cableada (red corporativa), tan pronto como lo desconecto, todo es muy rápido. Así que estoy seguro de que no está relacionado con su proveedor específico.

He mirado la salida detallada, no hay ningún error obvio (ni en ninguna parte de los registros del sistema). Sin embargo, noté esto:

Sin conexión en red, estas líneas se agrupan:

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

Sin la red, obtengo ~ 100-200 líneas de 'compose.parallel.feed_queue: Pending: set ([])' entre adjuntar <- y donde regresa con adjuntar -> ...

Antes de este punto, también están sucediendo muchas más cosas con la red, pero parece que en su mayoría solo más llamadas para inspeccionar la imagen, etc.

He adjuntado la salida de compose --verbose up para situaciones de bot. El archivo de redacción es solo dos contenedores directamente desde el concentrador.

with-networking.txt
sin-networking.txt

@holstvoogd oh, está bien para el proveedor. Gracias por la información, estaba un poco preocupado :)

@Erwyn @ smith64fx Para confirmar, ¿siempre estás conectado (cableado) y al mismo tiempo usas la misma red con wifi?

@FrenchBen No, solo está en la red wifi de mi casa. En mi oficina es súper rápido. Pero el caso es que todo lo demás en home funciona rápido, excepto docker-compose ^ _ ^ "

@FrenchBen igual que @ smith64fx. Es solo wifi en casa, por lo que no hay conexión por cable involucrada. Y como puedo ver, @holstvoogd parece tener el mismo problema con una conexión por cable.

Noto el mismo problema con Docker para Mac Beta. docker-compose up es lento cuando Wifi está habilitado, rápido cuando Wifi está deshabilitado.

• Versión de Docker Compose: versión de docker-compose 1.7.1, compilación 0a9ab35
• Versión de Docker: versión de Docker 1.11.1, compilación 5604cbe
• Versión del sistema operativo: OS X El Capitan 10.11.4

Hola, ¿hay alguna noticia sobre esto?

Tengo el mismo problema. Las versiones de Compose / Docker / OSX son las mismas que tiene @eugenesia .
Utilizo WiFi en casa y en la oficina y en mi casa funciona increíblemente lento. En la oficina funciona como se esperaba (rápido).

Pensé que tal vez era algo relacionado con el servidor DNS de mi ISP (los proveedores de Internet en el hogar y la oficina son diferentes) e intenté usar un DNS público, incluido el de Google, pero no ayudó.

Si apago el WiFi, docker-compose funciona muy rápido

@KryDos Una nueva versión debería salir esta semana con algunas mejoras de velocidad

Tengo el mismo problema, después de actualizar a Docker para mac 1.11.1-beta13, el problema persiste. La solución alternativa al apagar y encender las redes ya no funciona, los servicios se inician rápidamente cuando se apaga la red, pero cuando se vuelve a encender la red, los servicios ya no son accesibles y el demonio de la ventana acoplable no responde

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

• Versión de Docker Compose: versión de docker-compose 1.7.1, compilación 0a9ab35
• Versión de Docker: versión de Docker 1.11.1-beta13, compilación 7975
• Versión del sistema operativo: OS X El Capitan 10.11.5

Tuve los mismos problemas y encontré una publicación (lo siento, perdí la referencia) que menciona que docker-compose está tratando de resolver localunixsocket.local . Puede obtener información sobre la búsqueda de dns ejecutando sudo tcpdump -A -s0 -nni en0 port 53

Por ahora, he apuntado localunixsocket.local a localhost en mi /etc/hosts . Ahora todo vuelve a ser rápido.

127.0.0.1 localunixsocket.local

Gracias @jewilmeer , parece útil

Cambié de nuevo usando virtualbox con docker-machine. ¡El problema no existe y es hasta 10 veces más rápido que Docker Mac Beta!

@ smith64fx por favor mantenga sus comentarios constructivos; es una versión beta, aún no es un producto terminado, por lo que se esperan errores y problemas de rendimiento. Son exactamente este tipo de problemas los que necesitan informes (y pruebas) para resolverlos.

comentario súper impresionante, @jewilmeer! Para mí, tuve que agregar algunas direcciones más a / etc / hosts que descubrí usando su comando 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

Después de esas adiciones, ¡rápido! En realidad, sorprendentemente rápido, parece mucho más rápido que cuando se usa Docker Toolbox. woop woop :) (¡Aunque eso puede ser una observación muy subjetiva!)

Eso es bastante extraño, pero parece indicar cuál es el problema subyacente ...

Actualmente estoy enfrentando este mismo problema y no puedo resolverlo.
Probé las sugerencias anteriores para editar /etc/hosts . En nuestra red de oficinas, la ventana acoplable es extremadamente lenta. En redes domésticas o el uso de la conexión a un teléfono celular elimina todas las ralentizaciones y todo es rápido.

Estamos usando docker-compose con un contenedor web vinculado a cuatro contenedores de servicio (postgres, redis, rabbitmq, elasticsearch). La conexión a cualquiera de los cuatro contenedores de servicios directamente desde OSX está bien. Solo es lento cuando intenta conectarse desde el contenedor web a cualquiera de los contenedores de servicio.

Ejecutar tcpdump -vvv -s 0 -l -n port 53 da la siguiente salida cuando está conectado a un teléfono celular

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)

y esta es la salida cuando está en nuestra oficina wifi:

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)

Por lo tanto, parece algo con búsqueda de DNS inversa, pero no estoy seguro de cómo solucionarlo. La desactivación de wifi también garantiza completamente esta lentitud. Deshabilitar y volver a habilitar no ayuda.

Por supuesto, encontrará su propia solución justo después de publicar la pregunta. Parece que un paquete instalado en nuestro entorno de desarrollo actualizó la configuración de DNS en OSX, lo que causa el problema. Una vez que restablezco el DNS de OSX para usar los valores predeterminados en /etc/resolv.conf, todo funciona.

¿Podría esto estar relacionado con el problema con Bonjour 'poseyendo' .local y un error de IPV6?
detalles: https://news.ycombinator.com/item?id=11567442

No sé si esto ayuda, pero solía tener este problema y lo solucioné cambiando mis servidores DNS a 8.8.8.8 y 8.8.4.4 .

Además, este problema solo ocurrió en mi red doméstica. En el trabajo no tuve este problema.

También me enfrento al mismo problema incluso después de probar la solución de
docker-compose up funciona bien en la red de mi oficina, pero toma alrededor de ~ 7 minutos en mi red doméstica.
mismo comportamiento con otros comandos de docker-compose como stop, pull, ps, etc.

docker --versión
Docker versión 1.12.0-rc2, compilación 906eacd, experimental

docker-compose --version
docker-compose versión 1.8.0-rc1, compilación 9bf6bc6

docker-machine --versión
docker-machine versión 0.8.0-rc1, compilación fffa6c9

No estoy seguro de por qué, pero tuve que eliminar cualquier elemento de dominio local para que funcionara.

/ etc / hosts:
127.0.0.1 localunixsocket

Tengo un problema muy similar, pero creo que puede estar relacionado con mi uso de DNSCrypt .

@Erwyn También he experimentado el mismo problema con Vodafone Easybox ...
resultó que Vodafone Easybox vincula la búsqueda de dominios .local al enrutador (para evaluar el nombre de host dinámico de su enrutador, es decir, easy.box )
y supongo que este enlace estaba causando que docker-compose esperara la respuesta del enrutador (podría estar completamente equivocado en esto) ...
pero agregando
127.0.0.1 localunixsocket.local to etc/hosts resolvió el problema por mí

Hola chicos,
127.0.0.1 localunixsocket to etc / hosts resolvió el problema por mí

@davidino Thx Bro, ¡funciona perfectamente! Me interesa ¿por qué necesitamos esta solución?

¡Hola chicos! El mismo problema aqui. En Brasil, el uso de wifi en la oficina lleva mucho tiempo para comenzar. Después de cambiar los archivos /etc/hosts , todo funcionó bien.

El mismo problema aquí. Trabajando desde una oficina (con WIFI) no tengo problemas ni retrasos. Trabajando en una oficina diferente (también en WIFI) obtendría retrasos de ~ 10 minutos.

Agregar 127.0.0.1 localunixsocket a /etc/hosts _no_ resolvió el problema por mí. Intenté hacer eso en combinación con un reinicio, pero aún así no tuve suerte.

Agregar 8.8.8.8 y 8.8.4.4 como servidores DNS resolvieron el problema.

¡Gracias @Typositoire!

Hola, @dadarek , intenta agregar 127.0.0.1 localunixsocket.home <hostname>.home en tu archivo de hosts. Simplemente funcionó para mí cuando agregué ambos nombres de host. Para que pueda seguir usando su DNS local, si lo necesita ...

Esto me ocurre tanto en el canal estable como en el beta, desconectar Internet o agregar la entrada de host lo soluciona.

El Capitán 10.11.4
Docker versión 1.12.0, compilación 8eab29e, experimental
docker-compose versión 1.8.0, compilación f3628c7
docker-machine versión 0.8.0, compilación b85aac1

Intenté tanto el nombre de host como la desconexión de Internet en un comando de compilación y nada ayuda ... también probé el cambio de DNS ... simplemente se queda allí durante 5-10 minutos y luego comienza el proceso de compilación ... Puedo ver que la utilización de la CPU avanza hasta un 100% en el proceso de composición de Docker

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

muy frustrante

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

por cierto, la configuración funcionó bien con la caja de herramientas y se ejecutó muy rápido ...

con depuración detallada, puedo verlo colgando aquí

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

compose.config.config.find: usando archivos de configuración: ./docker-compose.yml
docker.auth.auth.load_config: el archivo no existe
compose.cli.command.get_client: docker-compose versión 1.8.0, compilación f3628c7
versión de docker-py: 1.9.0
Versión de CPython: 2.7.9
Versión de OpenSSL: OpenSSL 1.0.2h 3 de mayo de 2016
compose.cli.command.get_client: Docker base_url: http + docker: // localunixsocket
compose.cli.command.get_client: Versión de 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: Aplicación de creación
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 ')

después de unos minutos va a

docker.api.build._set_auth_headers: Buscando auth config
docker.api.build._set_auth_headers: No hay configuración de autenticación en la memoria: se carga desde el sistema de archivos
docker.auth.auth.load_config: el archivo no existe
docker.api.build._set_auth_headers: No se encontró ninguna configuración de autenticación

luego se cuelga de nuevo ...

mi velocidad de Internet está bien, solo probada a 60mb / s

habilitar Exclude simple hostnames desde la configuración del proxy funcionó perfectamente para mí.

NO_PROXY=* docker-compose up

Solución alternativa publicada por @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 funciona para mí.

Sería bueno tener un consejo de @jibingeo en Docker para Mac README.md o en algún lugar del tutorial.

Hola chicos, @thaJeztah.

Después de revisar el código fuente, descubrí que socket.gethostbyname("localunixsocket") está tardando más de 30 segundos (en mi caso) en ejecutarse.

Así que consulté mi DNS local y el DNS de Google.

$ 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

El DNS local funciona perfectamente con el nombre de host 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

Esto significa que el problema real es con el DNS del enrutador.

¿Soy solo yo, o hacer una búsqueda de DNS por localunixsocket parece contradictorio? Parece un nombre de host de relleno que solo se usa como marcador de posición cuando algo espera direcciones de estilo TCP en lugar de sockets de dominio local.

En cualquier caso, la diferencia de tiempos entre el DNS local y el DNS de Google es interesante ... Tendría curiosidad por saber qué está causando eso. (lamentablemente, creo que tendrías que tener otro volcado de TCP en el servidor DNS al que apunta el enrutador para saberlo, a menos que haya un tracert equivalente para búsquedas de DNS que puedan preservar los servidores intermedios afectados por un recursivo consulta)

Esto también podría ser informativo (se encuentra en man nslookup en Mac OS X):

AVISO DE Mac OS X

El comando nslookup no usa el nombre de host y la resolución de direcciones
o los mecanismos de enrutamiento de consultas de DNS utilizados por otros procesos que se ejecutan en
Mac OS X. Los resultados de las consultas de nombre o dirección impresos por nslookup
pueden diferir de los encontrados por otros procesos que utilizan Mac OS X
mecanismos de resolución de nombres y direcciones nativos. Los resultados de DNS
Las consultas también pueden diferir de las consultas que utilizan el enrutamiento DNS de Mac OS X
biblioteca.

Dado que en realidad no dan ninguna aclaración sobre qué mecanismo específico nslookup _does_ usa en comparación con lo que ofrece Mac OS X, es difícil decir si se esperaría que Docker compartiera el comportamiento de nslookup , o el de otras aplicaciones de Mac OS X ... (supongo que usa los mismos métodos que nslookup , pero probablemente tendríamos que profundizar en el código para que ambos lo averigüen definitivamente)

Hola @whitelynx

Aquí está el volcado de TCP tomado con el DNS local y el DNS de Google. El comando que solía tomar es

sudo killall -HUP mDNSResponder && docker-compose ps

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

Con DNS de Google:

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)

Aquí puedo ver un retraso de ~ 3 segundos con el DNS local.

Nota: el enrutador que usé aquí es diferente al que usé para el comentario anterior

Hola a todos,
después de la actualización a docker para mac Version 1.12.1 (build: 12133) tuve que agregar el
127.0.0.1 localunixsocket nuevamente en el /etc/hosts

Yo también tenía que hacer lo que hizo Davidino.

Sin estimativo en resolver este error muy molesto?

También tuve que agregar 127.0.0.1 localunixsocket.lan para que funcione. Estoy usando macOS Sierra.

Realmente no sé si este es el mismo problema, pero la respuesta de @jibingeo me ayudó.
_docker-compose_ también es muy lento en el entorno de mi empresa con Docker Toolbox para Windows. Configurar NO_PROXY=* también me ayudó, pero esto interfiere con el proxy de mi empresa. Así que probé un poco y encontré una solución más específica (asumiendo que estás usando el rango de ip de VirtualBox de Docker predeterminado 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 acelera todo, por lo que redactar no necesita probar el proxy de mi empresa para direcciones IP internas.

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

La solución de 127.0.0.1 localunixsocket en su /etc/hosts resolvió el problema por mí.

Mucho más rápido ahora

Tengo los mismos problemas. Intenté apagar mi wifi, agregando múltiples entradas a mi archivo de host sin éxito. He probado la misma configuración en mi caja de Linux y los resultados son mucho más rápidos.

La compilación parece ejecutarse a una velocidad decente, pero una vez que realizo alguna solicitud en los contenedores en ejecución, el resultado es horrible. Aproximadamente 30 segundos para cualquier solicitud, sin importar si se trata de una simple respuesta de texto.

Estoy ejecutando Mac OS Sierra (10.12.1) y Docker para Mac (1.12.1) con una pila de Rails.

Estoy en 10.11.6 (15G31)

Esto es lo que hay en mi archivo /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

Estoy en la ventana acoplable del canal beta 1.12.3-beta29.2 (13499)

@gardner Lo agregué a mi archivo de hosts y probé la versión beta sin éxito. Realmente estoy empezando a pensar que tiene algo que ver con Sierra. Estoy bastante seguro de que estaba funcionando antes de actualizar. Voy a darle otra oportunidad a la beta para ver si funciona. Publicaré de nuevo después de la prueba.

@gardner Mismo problema. Ahora ejecuta Docker 1.12.3-beta29.3 (13640). Mi configuración de Linux todavía se está ejecutando mucho más rápido con 1/4 de la RAM.

Lo mejor que puedo decir es que se trata de un problema de E / S entre la ventana acoplable y la máquina host. Ejecuté un flamegraph sobre la solicitud y pasa la mayor parte del tiempo leyendo archivos.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

Esta es la misma aplicación, la misma solicitud, que se ejecuta localmente.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

Si configuro, configure la aplicación para que se ejecute en modo de producción, se ejecutará con la misma rapidez dentro de Docker.

No estoy seguro si esto ya se sabe o no, pero espero que ayude a cualquiera que venga a este hilo tratando de resolverlo.

Editar: Parece que este es el problema real al que me enfrento. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

También con este problema, los cambios en los hosts marcan una pequeña diferencia, pero aún un poco lentos.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

Veo esto en la siguiente versión estable de la ventana acoplable que ejecuta OSX 10.11.6 con la siguiente versión de la ventana acoplable:

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

Veo esto en una conexión lenta en la nube (The Cloud en un café en Londres), cuando apago el WiFi, la composición es súper rápida, de lo contrario todo funciona muy lento ...

¿La última versión (1.9.0) pareció cambiar algo para las personas que experimentan el problema?

@ shin- Todavía tengo 1.8.1 en mi docker-compose --version con la última versión de Docker para Mac. ¿Cuándo podemos esperar una actualización?

¿Cuándo podemos esperar una resolución para este problema?

1.9 está en el canal beta, no estoy seguro de cuándo se enviará en estable, probablemente
en una semana más o menos.

El 18 de noviembre de 2016 a las 8:07 a. M., "David Richards" [email protected] escribió:

@ shin- https://github.com/shin- Todavía tengo 1.8.1 en mi docker-compose
--versión con la última versión de Docker para Mac. ¿Cuándo podemos esperar una actualización?

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

Para mí, McAfee Endpoint Security fue la razón por la que la composición de Docker era muy lenta. Parece que el escáner en acceso realmente está matando el rendimiento de descomprimir el entorno de Python que parece suceder cada vez que se ejecuta docker-compose.

Para mí, eliminar el dominio de búsqueda .local marcó la diferencia.

@ shin- en el 1.9.0-rc4 todavía tengo el problema. No sé qué hice, pero hace unos días no tuve el problema, usando docker-compose durante más de un año.
docker-compose --version es realmente rápido
docker-compose ps es muy lento
Desactivar Wifi - ps es rápido

@gsong lamentablemente eso no me ayudó

También de repente comencé a tener este problema. Al igual que @timsuchanek , he estado usando docker-compose durante aproximadamente un año y docker-compose up cuelga casi indefinidamente. Como todos los demás, cuando apago el wifi funciona.

Estoy en docker-compose version 1.9.0, build 2585387

Editar: Agregar 127.0.0.1 localunixsocket a /etc/hosts solucionó por ahora. Estoy en macOS 10.11.6

¿Cuáles son las posibilidades de que esto se deba a los cambios .local introducidos en yosemite?

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

Vi que @afxjzs lo mencionó anteriormente, pero no vi ningún seguimiento.

Me encontré con algo que funciona para mí, mientras intentaba que xdebug funcionara:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

en la máquina host.

Gracias a James Cowie .

Editar: Parece que xdebug fue la raíz de mi problema. Con xdebug desactivado, mi máquina acoplable es súper rápida, incluso con / etc / hosts en su estado predeterminado. Con él encendido, y mi xdebug.remote_host configurado en 10.254.254.254, se ralentiza a un rastreo. Las ediciones sugeridas en / etc / hosts no ayudan, pero establecer el alias de localhost en en0 como se indica arriba soluciona el problema.

Esto me está sucediendo con el último Docker estable para Mac (1.13.1, docker-compose 1.11.1)

Hacer NO_PROXY=* funciona.

Esto también me sucedió con la última actualización (1.13.1, docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 resolvió mi problema.

Yo tengo el mismo error. Añadiendo localunixsocket a /etc/hosts . no funcionó. Corrección temporal que marca el Exclude simple hostnames en la pestaña de proxies.

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

He notado que los dominios de búsqueda que no responden hacen que la composición de la ventana acoplable sea muy lenta. No es solo .local que estaba usando .dev .

Encontré el mismo problema hoy con docker-compose colgando para siempre, incluso para mostrar ayuda o --version. Seguí el consejo de 127.0.0.1 prod.python.map.fastly.net a / etc hosts

Bastante raro, creo.

El mismo problema aquí. Parece que cuelga dos veces, cada una durante unos 25 segundos. Aquí está la salida --verbose con cada HANG intervenido

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>

Probé las soluciones alternativas de / etc / hosts sin una mejora notable.

El mismo problema aquí y ninguna solución de todo el hilo me ayuda (ni /etc/hosts ni NO_PROXY variable ni Exclude simple hostnames ni cambiar DNS a 8.8.8.8 ).

Una cosa a tener en cuenta: si ejecuto Docker con sudo, resuelve el problema de velocidad.

Última versión de Docker (versión de Docker 17.03.1-ce-rc1, compilación 3476dbf). Probé versiones beta y estable.

docker --version tarda 32 segundos en generar la versión en mi caso.

Este problema ha existido durante casi un año ...

@mobileka ¿Estás hablando de docker o docker-compose ?

@ shin- En mi caso, cada comando cli (ya sea docker o docker-compose ) relacionado con la ventana acoplable tiene una latencia de aproximadamente 30 segundos antes de dar resultados o antes de comenzar a hacer su trabajo.

@mobileka De acuerdo, eso definitivamente no está relacionado con el problema que se describe aquí. En su lugar, considere crear un problema en el repositorio de Docker para Mac .

@ shin- Lo siento, no me di cuenta de que estoy en un repositorio incorrecto porque los "síntomas" eran muy similares: es lento cuando la conexión a Internet está activa y es rápido cuando no hay conexión a Internet.

Gracias, crearé un problema en el repositorio de Docker para Mac.

En la remota posibilidad de que esto afecte a alguien más, estoy bastante seguro de que mi juego (y el posterior error) con Consul agregó un archivo de configuración en / etc / resolvers. Esto provocó problemas similares a los de @seeekr informados al ver localunixsocket., al igual que:

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 eliminación del archivo de / etc / resolvers resolvió el problema de inmediato.

¡Espero que ayude!

El mismo problema aquí y ninguna solución de todo el hilo me ayuda (ni / etc / hosts ni la variable NO_PROXY ni Excluir nombres de host simples ni cambiar DNS a 8.8.8.8).

Escribo un sitio web de juguetes (la lógica es realmente simple y no debería tener problemas de rendimiento) y lo ejecuto localmente usando docker-compose. Resulta que casi todas las páginas tardan unos minutos en cargarse. ¿Alguna instrucción?

Los tiempos de carga de la página absoluto con este problema y, en general, no están relacionados con Redactar.

MacOS Sierra, 10.12.5.
Edición de la comunidad de Docker
Versión 17.06.0-ce-mac18 (18433)
Canal: estable
d9b66511e0

Ya tenía DNS como 8.8.8.8. Es necesario agregar localunixsocket.local y localunixsocket en / etc / hosts. En el instante en que se agregó esto, mi ventana acoplable-componer en ejecución cobró vida.

No estoy seguro de si esto ayuda a alguien, pero tengo dnscrypt instalado y, después de cambiar a la versión beta de la ventana acoplable, la composición de la ventana acoplable fue increíblemente lenta. Reinstalar dnscrypt (a través de brew cask) me solucionó el problema.

Te amo @jewilmeer

Solo quería dejar esto aquí. Mis problemas fueron los archivos de sesión dentro de mi contexto de compilación. Los archivos eran propiedad del usuario de apache y la compilación de docker-compose simplemente se colgaría después de esta línea:

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

Lo más triste es que dejé de usar sesiones basadas en archivos hace mucho tiempo. Probablemente debería limpiar mi espacio de trabajo de vez en cuando.

La razón para comentar: sería muy bueno si componer no se bloqueara. Solo descubrí al culpable usando docker build directamente, lo que me informó muy bien de mis problemas.

@paali, ¿puedes explicar lo que hiciste exactamente?

@ Vad1mo mi configuración completa es bastante compleja (y desordenada y en progreso) pero las partes básicas son el proyecto Symfony2. Tenía archivos de sesión antiguos en la carpeta ./app/sessions que eran propiedad del usuario de Apache (antes de los tiempos de Docker).

Básicamente tuve
COPY app app/
en uno de los Dockerfiles y docker-compose.yml para construir el correspondiente Dockerfile.
El comando utilizado:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

Como se señaló, el proceso de compilación nunca comenzó realmente, pero se congeló después de las líneas sobre los encabezados de autenticación. Hacer construir en Docker directamente me dio:

> 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 próxima vez sabré probar Docker directamente de inmediato, pero nada parecía indicar cuál era el problema real. Estoy en Docker para Mac 7.06.1-ce-mac24.

¿Alguna palabra sobre una solución real a esto que no sea tener que decirles a todos que agreguen una regla de host o desactiven los proxies?

+1

+1

+1

Lo que me solucionó fue ir a Preferencias del sistema / Red / Avanzado / DNS / Buscar dominios y eliminar la entrada ".local". que había puesto allí. Esto hizo que macOS llenara los dominios de búsqueda solo con el valor predeterminado, "dominio local". Y luego docker-compose volvió a responder.

docker sí mismo respondía todo el tiempo.

No lo sé, pero supongo que tal vez docker está encontrando correctamente un recurso en el sistema usando una dirección IP o un nombre local estable, mientras que docker-compose confía de forma insegura en localdomain siempre se define como uno de los dominios de búsqueda. ¡Pero no sé!

Ejecuté la línea para monitorear el DNS que estaba en la publicación original sobre la solución:

sudo tcpdump -A -s0 -nni en0 puerto 53

Eso me mostró que lo que necesitaba agregar a mi archivo host era:

127.0.0.1 localunixsocket.localdomain

parece que algo ha cambiado de .local a .localdomain?

Desde entonces he realizado una nueva instalación de 10.12 Sierra. Reinstalé Docker y no pude reproducir el problema.

Me encontré con este problema hoy, mi primer día en Mac.
La composición de Docker se detuvo, literalmente después de insertar la línea en /etc/hosts , comenzó a funcionar como se esperaba.
Estaba usando WiFi , todos en la oficina con la misma versión en Ethernet ni siquiera habían oído hablar de este problema.
Docker: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

El mismo error aquí. Tengo que agregar las tres líneas a / etc / hosts para resolver este problema.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Mismo error. Esto funcionó para mí.

$ 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

Agregué 127.0.0.1 localunixsocket en /etc/hosts y funcionó para mí, ¡gracias!
(pero sigue siendo un error wtf)

Sigue siendo un problema en la última versión. Las correcciones anteriores no parecen hacer nada por mí, en algún momento se vuelve tan lento que se cuelga. La solución para mí es reiniciar Docker para mac de vez en cuando.

Confirmado que 127.0.0.1 localunixsocket en /etc/hosts acelera drásticamente las cosas, ¡corríjalo!

agregar 127.0.0.1 localunixsocket en /etc/hosts ayuda. Estoy usando docker-compose version 1.18.0, build 8dd22a9

La solución que recomendó @norbertsienkiewicz funcionó perfectamente para mí. Bajó mi tiempo docker-compose up de más de 10 minutos a menos de un minuto (versión 1.18.0).

De hecho, tengo más curiosidad por saber por qué comenzó a suceder esto en primer lugar. Me parece un poco tonto tener que modificar mi archivo de hosts como solución temporal a un problema que se presentó recientemente y declararlo como la "solución".

Aquí está el seguimiento que causa la búsqueda de DNS falsa:

  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)

Acabo de tener este problema después de cambiar de inalámbrico a cableado. De vuelta a la tecnología inalámbrica y todo está bien en el mundo.

¿Los cambios en / etc / host se refieren a la máquina host o al contenedor de la ventana acoplable?

¿Qué archivo de hosts modificar?

1. archivo hosts macOS?
2. ¿La máquina virtual Linux que actúa como host de la ventana acoplable?
3. ¿El contenedor en sí?

No estoy seguro de por qué, pero tuve que eliminar cualquier elemento de dominio local para que funcionara.

/ etc / hosts:
127.0.0.1 localunixsocket

¡¡¡Genio!!!