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

ping @frenchben : smile:

+1

tenho o mesmo problema: D

@ smith64fx problema também vai embora se você desligar seu WiFi?

@stijn Sim, quando desligo o wi-fi, tudo funciona

Von meinem iPhone gesendet

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

@ smith64fx problema também vai embora se você desligar seu WiFi?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

@ smith64fx Vejo pela sua assinatura que provavelmente você é da Alemanha (ou da Áustria / Suíça). Você se importa se eu perguntar qual é o seu provedor de Internet? Eu gostaria de saber se temos o mesmo, e se poderia estar vindo da caixa que não parece ser um hardware / software muito bom e não funcionaria como pensado pelo docker.

(Estou com a Vodafone e tenho a sua caixa fácil, seja lá o que for)

Mesmo problema em uma rede cabeada (rede corporativa), assim que desligo tudo é muito rápido. Portanto, tenho certeza de que não está relacionado ao seu provedor específico.

Eu olhei para a saída detalhada, não há nenhum erro óbvio (nem em qualquer lugar nos logs do sistema). Porém, notei isso:

Sem rede, essas linhas são agrupadas:

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

Sem rede, obtenho ~ 100-200 linhas de 'compose.parallel.feed_queue: Pending: set ([])' entre o attach <- e onde ele retorna com attach -> ...

Antes deste ponto, há muito mais acontecendo com a rede também, mas na maioria das vezes, apenas mais chamadas para inspecionar a imagem, etc., ao que parece.

Anexei a saída de compose --verbose up para situações de bot. O arquivo de composição é apenas dois contêineres direto do hub.

with-networking.txt
sem rede.txt

@holstvoogd oh, ok para o provedor. Obrigado pela informação, estava um pouco preocupado :)

@Erwyn @ smith64fx Para confirmar, você está sempre conectado (com fio) e ao mesmo tempo usa a mesma rede com wi-fi?

@FrenchBen Não, é apenas na rede wi-fi da minha casa. No meu escritório é super rápido. Mas a questão é que tudo em casa é executado rápido, exceto docker-compose ^ _ ^ "

@FrenchBen igual a @ smith64fx. É apenas wi-fi em casa, então não há conexão com fio envolvida. E, como posso ver, @holstvoogd parece ter o mesmo problema com uma conexão com fio.

Estou percebendo o mesmo problema com o Docker para Mac Beta. docker-compose up é lento quando o Wifi está ativado e rápido quando o Wifi está desativado.

• Versão do Docker Compose: docker-compose versão 1.7.1, build 0a9ab35
• Versão do Docker: Docker versão 1.11.1, compilação 5604cbe
• Versão do sistema operacional: OS X El Capitan 10.11.4

Olá, há alguma novidade sobre isso?

Eu tenho o mesmo problema. As versões do Compose / Docker / OSX são iguais às do @eugenesia .
Eu uso WiFi em casa e no escritório e na minha casa funciona incrivelmente lento. No escritório funciona conforme o esperado (rápido).

Achei que talvez fosse algo relacionado ao servidor DNS do meu ISP (os provedores de internet em casa e no escritório são diferentes) e tentei usar alguns DNS públicos incluindo o do Google, mas não adiantou.

Se eu desligar o WiFi, docker-compose funcionará muito rápido

@KryDos Um novo lançamento deve sair esta semana com algumas melhorias de velocidade

Eu tenho o mesmo problema, depois de atualizar para o docker para mac 1.11.1-beta13, o problema persiste. A solução alternativa, desligando e ligando novamente a (s) rede (s) não funciona mais, os serviços iniciam rapidamente ao desligar a rede, mas ao ligar a rede novamente, os serviços não estão mais acessíveis e o daemon do docker não está respondendo

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

• Versão do Docker Compose: docker-compose versão 1.7.1, build 0a9ab35
• Versão do Docker: Docker versão 1.11.1-beta13, build 7975
• Versão do sistema operacional: OS X El Capitan 10.11.5

Eu tive os mesmos problemas e encontrei uma postagem (desculpe, perdi a referência) mencionando que docker-compose está tentando resolver localunixsocket.local . Você pode obter informações sobre a pesquisa de dns executando sudo tcpdump -A -s0 -nni en0 port 53

Por enquanto, apontei localunixsocket.local para localhost em meu /etc/hosts . Agora tudo é rápido novamente.

127.0.0.1 localunixsocket.local

Obrigado @jewilmeer , isso parece útil

Voltei a usar o virtualbox com docker-machine. O problema não existe e é até 10x mais rápido que o Docker Mac Beta!

@ smith64fx por favor, mantenha seus comentários construtivos; é um beta, não é um produto acabado ainda, então bugs e problemas de desempenho são esperados. É exatamente esse tipo de problema que precisa de relatórios (e testes) para resolvê-los.

comentário super incrível, @jewilmeer! Para mim, tive que adicionar mais alguns endereços a / etc / hosts que descobri usando seu 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

Após essas adições - rápido! Na verdade, incrivelmente rápido, parece muito mais rápido do que quando se usa o Docker Toolbox! woop woop :) (embora essa possa ser uma observação altamente subjetiva!)

Isso é muito estranho, mas parece apontar qual é o problema subjacente ...

No momento, estou enfrentando o mesmo problema e não consigo resolver o problema.
Tentei as sugestões anteriores para editar /etc/hosts . Em nossa rede de escritório, o docker é extremamente lento. Em redes domésticas ou usando tethering para um telefone celular remove todos os atrasos e tudo é rápido.

Estamos usando docker-compose com um contêiner da web vinculado a quatro contêineres de serviço (postgres, redis, rabbitmq, elasticsearch). Conectar-se a qualquer um dos quatro contêineres de serviço diretamente do OSX está bem. Só é lento ao tentar se conectar do contêiner da web a qualquer um dos contêineres de serviço.

Executar tcpdump -vvv -s 0 -l -n port 53 dá a seguinte saída quando conectado a um telefone 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)

e esta é a saída quando em nosso wi-fi do escritório:

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)

Parece algo com pesquisa DNS reversa, mas não tenho certeza de como solucionar o problema. Desativar o wi-fi completamente garante essa lentidão também. Desativar e reativar não ajuda.

É claro que você encontrará sua própria solução logo após postar a pergunta. Parece que um pacote instalado em nosso ambiente de desenvolvimento atualizou as configurações de DNS no OSX que causam o problema. Depois de redefinir o DNS OSX para usar os padrões em /etc/resolv.conf, tudo funciona.

Isso pode estar relacionado ao problema de Bonjour 'possuir' .local e um bug de IPV6?
detalhes: https://news.ycombinator.com/item?id=11567442

Não sei se isso ajuda, mas eu costumava ter esse problema e corrigi-lo alterando meus servidores DNS para 8.8.8.8 e 8.8.4.4 .

Além disso, esse problema só aconteceu na minha rede doméstica. No trabalho eu não tive esse problema.

Também estou enfrentando o mesmo problema, mesmo depois de tentar a correção de @jewilmeer .
docker-compose up funciona bem na rede do meu escritório, mas leva cerca de 7 minutos na rede doméstica.
mesmo comportamento com outros comandos docker-compose, como stop, pull, ps etc.

docker --version
Docker versão 1.12.0-rc2, build 906eacd, experimental

docker-compose --version
docker-compose versão 1.8.0-rc1, compilação 9bf6bc6

docker-machine --version
docker-machine versão 0.8.0-rc1, compilação fffa6c9

Não sei por que, mas tive que remover qualquer elemento de domínio local para fazer funcionar.

/ etc / hosts:
127.0.0.1 localunixsocket

Tenho um problema muito semelhante, mas acho que pode estar relacionado ao uso do DNSCrypt .

@Erwyn Também tive o mesmo problema com o Vodafone Easybox ...
descobriu-se que o Vodafone Easybox vincula a pesquisa de .local domínios ao roteador (para avaliar o nome de host dinâmico do seu roteador, a saber easy.box )
e meu palpite é que essa ligação estava fazendo com que docker-compose esperasse pela resposta do roteador (posso estar completamente errado nisso) ...
mas adicionando
127.0.0.1 localunixsocket.local a etc/hosts resolveu o problema para mim

Oi pessoal,
127.0.0.1 localunixsocket para etc / hosts resolveu o problema para mim

@davidino Thx Bro, funciona perfeitamente! Estou interessado em por que precisamos desta solução alternativa?

Ola pessoal! Mesmo problema aqui. No Brasil, usar wi-fi no escritório demora muito para começar. Depois de alterar os arquivos /etc/hosts , tudo funcionou bem.

Mesmo problema aqui. Trabalhando em um escritório (em WIFI) Não tenho problemas ou atrasos. Trabalhando em um escritório diferente (também com WIFI), eu teria atrasos de aproximadamente 10 minutos.

Adicionar 127.0.0.1 localunixsocket a /etc/hosts _não_ resolveu o problema para mim. Tentei fazer isso em combinação com uma reinicialização, mas ainda sem sorte.

Adicionar 8.8.8.8 e 8.8.4.4 como servidores DNS resolveu o problema.

Obrigado @Typositoire!

Ei, @dadarek , tente adicionar 127.0.0.1 localunixsocket.home <hostname>.home em seu arquivo hosts. Simplesmente funcionou para mim quando adicionei os dois nomes de host. Portanto, você ainda pode usar seu DNS local, se precisar ...

Isso ocorre para mim tanto no canal estável quanto no beta, desconectar a Internet ou adicionar a entrada de host corrige isso para mim.

El Capitan 10.11.4
Docker versão 1.12.0, build 8eab29e, experimental
docker-compose versão 1.8.0, compilação f3628c7
docker-machine versão 0.8.0, compilação b85aac1

Eu tentei o nome do host e a desconexão da Internet em um comando de compilação e nada ajudou ... tentei a mudança de DNS também ... ele fica lá por 5-10 minutos e então inicia o processo de compilação ... Eu posso ver a utilização da CPU ir até 100% no processo docker-compose

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

tão frustrante

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

aliás, a configuração funcionou bem com a caixa de ferramentas e foi executada muito rapidamente ...

com depuração detalhada, posso vê-lo pendurado aqui

[home / docker] - $ docker-compose - aplicativo de compilação verbose

compose.config.config.find: Usando arquivos de configuração: ./docker-compose.yml
docker.auth.auth.load_config: o arquivo não existe
compose.cli.command.get_client: docker-compose versão 1.8.0, compilação f3628c7
versão docker-py: 1.9.0
Versão CPython: 2.7.9
Versão OpenSSL: OpenSSL 1.0.2h 3 de maio de 2016
compose.cli.command.get_client: Docker base_url: http + docker: // localunixsocket
compose.cli.command.get_client: Versão do Docker: KernelVersion = 4.4.15-moby, Os = linux, BuildTime = 2016-07-28T21: 15: 28.963402499 + 00: 00, ApiVersion = 1.24, Versão = 1.12.0, GitCommit = 8eab29e, Arch = amd64, GoVersion = go1.6.3
compose.service.build: Criando aplicativo
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 ')

depois de alguns minutos vai para

docker.api.build._set_auth_headers: Procurando pela configuração de autenticação
docker.api.build._set_auth_headers: Nenhuma configuração de autenticação na memória - carregando do sistema de arquivos
docker.auth.auth.load_config: o arquivo não existe
docker.api.build._set_auth_headers: Nenhuma configuração de autenticação encontrada

então ele trava de novo ...

minha velocidade de internet está boa apenas testada em 60mb / s

ativar Exclude simple hostnames das configurações de proxy funcionou perfeitamente para mim.

NO_PROXY=* docker-compose up

Solução alternativa postada por @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 funciona para mim.

Seria bom receber a dica de @jibingeo no Docker para Mac README.md ou em algum lugar do tutorial.

Olá pessoal, @thaJeztah.

Depois de examinar o código-fonte, descobri que socket.gethostbyname("localunixsocket") está demorando mais de 30s (no meu caso) para ser executado.

Então eu consultei meu DNS local e 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

DNS local funciona perfeitamente com nome 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

Isso significa que o problema real é com o DNS do roteador.

Sou só eu ou fazer uma pesquisa de DNS para localunixsocket parece contra-intuitivo? Parece um nome de host de preenchimento que é usado apenas como um espaço reservado quando algo está esperando endereços do estilo TCP em vez de soquetes de domínio local.

De qualquer forma, a diferença de tempo entre o DNS local e o DNS do Google é interessante ... Eu ficaria curioso para saber o que está causando isso. (infelizmente, acho que você teria que ter outro dump TCP no servidor DNS apontado pelo roteador para saber, a menos que haja um tracert equivalente para pesquisas de DNS que podem preservar servidores intermediários atingidos por um recursivo inquerir)

Isso também pode ser informativo (encontrado em man nslookup no Mac OS X):

AVISO Mac OS X

O comando nslookup não usa o nome do host e a resolução do endereço
ou os mecanismos de roteamento de consulta DNS usados ​​por outros processos em execução no
Mac OS X. Os resultados das consultas de nome ou endereço impressos por nslookup
podem ser diferentes daqueles encontrados por outros processos que usam o Mac OS X
mecanismos de resolução de nomes e endereços nativos. Os resultados do DNS
as consultas também podem ser diferentes das consultas que usam o roteamento DNS do Mac OS X
biblioteca.

Como eles não fornecem nenhum esclarecimento sobre qual mecanismo específico nslookup _does_ usa em comparação com o que o Mac OS X fornece, é difícil dizer se o Docker deveria compartilhar o comportamento de nslookup , ou de outros aplicativos Mac OS X ... (meu palpite é que ele usa os mesmos métodos que nslookup usa, mas provavelmente teríamos que cavar no código para ambos para descobrir isso definitivamente)

Ei @whitelynx

Aqui está o dump de TCP obtido com DNS local e DNS do Google. O comando que eu costumava tirar é

sudo killall -HUP mDNSResponder && docker-compose ps

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

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

Aqui eu posso ver um atraso de ~ 3 segundos com DNS local.

Observação: o roteador que usei aqui é diferente daquele que usei para comentários anteriores

Olá a todos,
após a atualização para docker para mac Version 1.12.1 (build: 12133) eu tive que adicionar o
127.0.0.1 localunixsocket novamente no /etc/hosts

Eu tive que fazer o que David também fez.

Nenhuma estimativa para resolver esse bug muito chato?

Eu apenas tive que adicionar 127.0.0.1 localunixsocket.lan para fazer funcionar. Estou usando o macOS Sierra.

Não sei realmente se é o mesmo problema, mas a resposta do @jibingeo me ajudou.
_docker-compose_ também é muito lento no ambiente da minha empresa usando o Docker Toolbox para Windows. Configurar NO_PROXY=* também me ajudou, mas isso interfere no proxy da minha empresa. Então, tentei um pouco e encontrei uma solução mais específica (supondo que você esteja usando o intervalo de ip padrão do VirtualBox do docker 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 acelera tudo, então o Compose não precisa tentar o proxy da minha empresa para IPs internos.

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

A solução 127.0.0.1 localunixsocket em seu /etc/hosts resolveu o problema para mim.

Muito mais rápido agora

Estou tendo os mesmos problemas. Eu tentei desligar meu wi-fi, adicionando várias entradas ao meu arquivo host sem sucesso. Eu tentei a mesma configuração na minha máquina linux e os resultados são muito mais rápidos.

A compilação parece ser executada em uma velocidade decente, mas uma vez que faço qualquer solicitação nos contêineres em execução, o resultado é horrível. Cerca de 30 segundos para qualquer solicitação, não importa se é uma resposta de texto simples.

Estou executando o Mac OS Sierra (10.12.1) e o Docker para Mac (1.12.1) com uma pilha Rails.

Estou em 10.11.6 (15G31)

Isto é o que está em meu arquivo /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

Estou no docker do canal beta 1.12.3-beta29.2 (13499)

@gardner Eu adicionei isso ao meu arquivo hosts e tentei o beta sem sucesso. Estou realmente começando a achar que tem algo a ver com Sierra. Tenho certeza de que estava funcionando antes da atualização. Vou dar outra chance ao beta para ver se funciona. Vou postar novamente depois de testar.

@gardner Mesmo problema. Agora executando o Docker 1.12.3-beta29.3 (13640). Minha configuração do Linux ainda está funcionando muito mais rápido com 1/4 da RAM.

O melhor que posso dizer é que é um problema de E / S entre a docker e a máquina host. Executei um flamegraph sobre o pedido e ele passa a maior parte do tempo lendo arquivos.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

Este é o mesmo aplicativo, a mesma solicitação em execução localmente.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

Se eu configurar o aplicativo para ser executado no modo de produção, ele será executado com a mesma rapidez dentro do Docker.

Não tenho certeza se isso já é conhecido ou não, mas espero que ajude qualquer pessoa que vier a este tópico tentando descobrir isso.

Edit: Parece que este é o verdadeiro problema que estou enfrentando. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

Também enfrentando esse problema, as mudanças nos hosts fazem um pouco de diferença, mas ainda um pouco lentas.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

Estou vendo isso na seguinte versão do docker estável executando OSX 10.11.6 com a seguinte versão do docker:

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

Estou vendo isso em uma conexão lenta na nuvem (The Cloud em um café em Londres), quando eu desligo o WiFi, a composição é super rápida, caso contrário tudo roda muito devagar ...

A versão mais recente (1.9.0) parece mudar alguma coisa para as pessoas que estão enfrentando o problema?

@ shin- Ainda tenho 1.8.1 no meu docker-compose --version com o Docker para Mac mais recente. Quando podemos esperar uma atualização?

Quando podemos esperar uma resolução para esse problema?

1.9 está no canal beta, não tenho certeza de quando será lançado no estável, provavelmente
em uma semana ou assim.

Em 18 de novembro de 2016, 8h07, "David Richards" [email protected] escreveu:

@ shin- https://github.com/shin- Ainda tenho 1.8.1 em meu docker-compose
--version com o Docker para Mac mais recente. Quando podemos esperar uma atualização?

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

Para mim, o McAfee Endpoint Security foi o motivo do docker-compose ser muito lento. Parece que o mecanismo de varredura ao acessar está realmente acabando com o desempenho de desempacotar o ambiente Python, o que parece acontecer toda vez que docker-compose é executado.

Para mim, remover o domínio de pesquisa .local fez toda a diferença.

@ shin- in the 1.9.0-rc4 Ainda tenho o problema. Não sei o que fiz, mas alguns dias atrás não tive o problema, usando docker-compose por mais de um ano.
docker-compose --version é muito rápido
docker-compose ps é muito lento
Desativar Wifi - ps é rápido

@gsong infelizmente isso não ajudou para mim

Eu também comecei a ter esse problema de repente. Assim como @timsuchanek, estou usando docker-compose há cerca de um ano e docker-compose up trava quase indefinidamente. Como todo mundo, quando desligo o wi-fi funciona.

Estou em docker-compose version 1.9.0, build 2585387

Editar: Adicionar 127.0.0.1 localunixsocket a /etc/hosts corrigiu por agora. Estou no macOS 10.11.6

Quais são as chances de que isso seja devido às .local mudanças introduzidas no yosemite?

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

Eu vi que @afxjzs mencionou isso antes, mas não vi nenhum acompanhamento.

Eu tropecei em algo que funciona para mim, ao tentar fazer o xdebug funcionar:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

na máquina host.

Graças a James Cowie .

Edit: Parece que xdebug foi a raiz do meu problema. Com o xdebug desligado, minha máquina docker é super-rápida, mesmo com / etc / hosts em seu estado padrão. Com ele ativado e meu xdebug.remote_host definido como 10.254.254.254, ele fica lento. As edições sugeridas para / etc / hosts não ajudam, mas definir o alias localhost em en0 como acima corrige o problema.

Isso está acontecendo comigo com o Docker estável mais recente para Mac (1.13.1, docker-compose 1.11.1)

Fazendo NO_PROXY=* obras.

Isso também aconteceu comigo com a atualização mais recente (1.13.1, docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 resolveu meu problema.

Eu tenho o mesmo erro. Adicionando localunixsocket a /etc/hosts . não funcionou. Correção temporária marcando Exclude simple hostnames na guia de proxies.

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

Percebi que qualquer domínio de pesquisa não responsivo torna o docker-compose muito lento. Não é apenas .local eu estava usando .dev .

Eu encontrei o mesmo problema hoje com docker-compose pendurado para sempre até mesmo para exibir ajuda ou --version. Segui o conselho de @jewilmeer sobre como usar o tcpdump e, no meu caso, o problema foi resolvido adicionando 127.0.0.1 prod.python.map.fastly.net aos hosts / etc

Muito estranho, eu acho?

Mesmo problema aqui. Parece que trava duas vezes, cada uma por cerca de 25 segundos. Aqui está a saída de --verbose com cada HANG interceptado

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>

Tentei as soluções alternativas / etc / hosts sem nenhuma melhoria perceptível.

O mesmo problema aqui e nenhuma solução de todo o tópico me ajuda (nem /etc/hosts nem NO_PROXY variável nem Exclude simple hostnames nem alterar DNS para 8.8.8.8 ).

Uma coisa a ser observada: se eu executar o docker com sudo, ele resolverá o problema de velocidade.

Versão mais recente do docker (Docker versão 17.03.1-ce-rc1, build 3476dbf). Tentei versões beta e estáveis.

docker --version leva 32 segundos para gerar a versão no meu caso.

Este problema já existe há quase um ano ...

@mobileka Você está falando sobre docker ou docker-compose ?

@ shin- No meu caso, cada comando cli (seja docker ou docker-compose ) relacionado ao docker tem uma latência de 30 ou mais segundos antes de realmente fornecer resultados ou antes de começar a fazer seu trabalho.

@mobileka Ok - isso definitivamente não tem relação com o problema descrito aqui. Considere criar um problema no repositório Docker para Mac .

@ shin- Desculpe, não percebi que estou em um repositório errado porque os "sintomas" são muito semelhantes: é lento quando a conexão com a Internet está ativa e é rápido quando não há conexão com a Internet.

Obrigado, vou criar um problema no repositório Docker para Mac.

Na chance de isso atingir qualquer outra pessoa, tenho quase certeza de que minha brincadeira (e subsequente confusão) com o Consul adicionei um arquivo de configuração em / etc / resolvers. Isso causou problemas semelhantes a @seeekr relatado ao ver localunixsocket., igual a:

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

Remover o arquivo de / etc / resolvers resolveu o problema imediatamente.

Espero que ajude!

O mesmo problema aqui e nenhuma solução de todo o thread me ajuda (nem / etc / hosts, nem a variável NO_PROXY, nem Excluir nomes de host simples nem alterar DNS para 8.8.8.8).

Eu escrevo um site de brinquedo (a lógica é muito simples e não deve ter problemas de desempenho) e executo-o localmente usando docker-compose. Quase todas as páginas levam minutos para carregar. Alguma instrução?

Os tempos de carregamento da página

MacOS Sierra, 10.12.5.
Docker Community Edition
Versão 17.06.0-ce-mac18 (18433)
Canal: estável
d9b66511e0

Já tinha DNS como 8.8.8.8. Necessário para adicionar localunixsocket.local e localunixsocket em / etc / hosts. No instante em que isso foi adicionado, meu docker-compose em execução ganhou vida.

Não tenho certeza se isso ajuda alguém - mas instalei o dnscrypt e depois de mudar para o docker beta, o docker compose ficou incrivelmente lento. Reinstalar dnscrypt (via brew cask) corrigiu o problema para mim.

Te amo @jewilmeer

Só queria deixar isso aqui. Meus problemas eram arquivos de sessão dentro do meu contexto de construção. Os arquivos pertenciam ao usuário apache e a compilação docker-compose iria apenas travar após esta linha:

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

O mais triste é que parei de usar sessões baseadas em arquivo há muito tempo. Provavelmente deveria limpar meu espaço de trabalho de vez em quando.

O motivo para comentar: seria muito bom se a composição não fosse apenas travada. Eu só descobri o culpado usando o docker build diretamente, o que me informou sobre meus problemas.

@paali você pode explicar o que você fez exatamente?

@ Vad1mo minha configuração completa é bastante complexa (e confusa e em andamento), mas as partes básicas são o projeto Symfony2. Tinha arquivos de sessão antigos na pasta ./app/sessions que pertenciam ao usuário apache (antes do docker times).

Basicamente eu tinha
COPY app app/
em um dos Dockerfiles e docker-compose.yml para construir o Dockerfile perticular.
O comando usado:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

Conforme observado, o processo de construção nunca começou realmente, mas congelou após as linhas sobre cabeçalhos de autenticação. Fazer a compilação no docker me deu diretamente:

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

Na próxima vez, tentarei o docker imediatamente, mas nada parecia sugerir qual era o verdadeiro problema. Estou no Docker para Mac 7.06.1-ce-mac24.

Alguma palavra sobre uma solução real para isso, além de dizer a todos para adicionar uma regra de host ou desligar os proxies?

+1

+1

+1

O que corrigiu para mim foi ir para Preferências do sistema / Rede / Avançado / DNS / Domínios de pesquisa e remover a entrada ".local". que eu coloquei lá. Isso fez com que o macOS povoasse os domínios de pesquisa apenas com o valor padrão, "localdomain". E então docker-compose tornou-se responsivo novamente.

docker respondia sempre.

Não sei, mas acho que talvez docker esteja encontrando corretamente um recurso no sistema usando um endereço IP ou um nome local estável, enquanto docker-compose está confiando de forma insegura em localdomain sempre sendo definido como um dos domínios de pesquisa. Mas não sei!

Eu correria a linha para monitorar o dns que estava na postagem original na correção:

sudo tcpdump -A -s0 -nni en0 porta 53

Isso me mostrou que o que eu precisava adicionar ao meu arquivo host era:

127.0.0.1 localunixsocket.localdomain

parece que algo mudou de .local para .localdomain?

Desde então, fiz uma nova instalação do 10.12 Sierra. Reinstalei o docker e não consegui reproduzir o problema.

Corri para este problema hoje, meu primeiro dia no Mac.
A composição do Docker apenas foi paralisada, literalmente após inserir a linha em /etc/hosts ela começou a funcionar conforme o esperado.
Eu estava usando WiFi , todos no escritório com a mesma versão em Ethernet nunca ouviram falar desse problema.
Docker: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

Mesmo bug aqui. Tenho que adicionar as três linhas a / etc / hosts para resolver este problema.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Mesmo bug. Isso funcionou para mim.

$ 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

Eu adicionei 127.0.0.1 localunixsocket em /etc/hosts e funcionou para mim, obrigado!
(mas ainda é um bug wtf)

Ainda é um problema na versão mais recente. As correções acima parecem não fazer nada por mim, em algum ponto fica tão lento que trava. A solução alternativa para mim é reiniciar o Docker para mac de vez em quando.

Confirmado que 127.0.0.1 localunixsocket em /etc/hosts acelera drasticamente as coisas, corrija!

adicionar 127.0.0.1 localunixsocket em /etc/hosts ajuda. Estou usando docker-compose version 1.18.0, build 8dd22a9

A solução recomendada por @norbertsienkiewicz funcionou perfeitamente para mim. Diminuiu meu tempo de docker-compose up de mais de 10 minutos para menos de um minuto (versão 1.18.0).

Na verdade, estou mais curioso para saber por que isso começou a acontecer em primeiro lugar. Parece um pouco bobo para mim ter que modificar meu arquivo hosts como uma solução alternativa para um problema que foi recentemente introduzido e declarar que ele é a "solução".

Aqui está o backtrace que causa a pesquisa DNS espúria:

  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)

Eu só tive esse problema depois de mudar de sem fio para com fio. De volta ao wireless e tudo está certo no mundo.

As alterações em / etc / host são da máquina host ou do contêiner do docker ??

Qual arquivo de hosts modificar?

1. Arquivo de hosts macOS?
2. A VM Linux servindo como host docker?
3. O próprio contêiner?

Não sei por que, mas tive que remover qualquer elemento de domínio local para fazer funcionar.

/ etc / hosts:
127.0.0.1 localunixsocket

Gênio!!!