Os contêineres do Docker não conseguem resolver o DNS no Host do Ubuntu 14.04 Desktop

48

Estou com um problema com meus contêineres do Docker no Ubuntu 14.04 LTS. O Docker funcionou bem por dois dias e, de repente, perdi toda a conectividade de rede dentro de meus contêineres. O erro de saída abaixo inicialmente me levou a acreditar que era porque o apt-get está tentando resolver o DNS via IPv6.

Desativei o IPv6 na minha máquina host e ainda assim, removi todas as imagens, puxei o ubuntu base e ainda encontrei o problema.

Alterei meus servidores de nome /etc/resolve.conf do servidor DNS local para os servidores DNS públicos do Google (8.8.8.8 e 8.8.4.4) e ainda não tenho sorte. Também configurei o DNS para o Google no DOCKER_OPTS de / etc / default / docker e reiniciei o docker.

Também tentei puxar coreos e o yum também não conseguiu resolver o DNS.

É estranho porque, embora o DNS não funcione, ainda recebo uma resposta quando sigo os mesmos servidores de atualização que o apt-get não consegue resolver.

Não estou atrás de um proxy, estou em uma rede local muito padrão e esta versão do Ubuntu está atualizada e atualizada (instalei há dois dias para estar mais perto do docker).

Eu pesquisei isso completamente em outras postagens sobre problemas de stackoverflow e github, mas não encontrei nenhuma resolução. Estou sem idéias de como resolver esse problema, alguém pode ajudar?

Mensagem de erro

➜  arthouse git:(docker) ✗ docker build --no-cache .
Sending build context to Docker daemon 51.03 MB
Sending build context to Docker daemon 
Step 0 : FROM ubuntu:14.04
 ---> 5506de2b643b
Step 1 : RUN apt-get update
 ---> Running in 845ae6abd1e0
Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease   
Err http://archive.ubuntu.com trusty-proposed InRelease  
Err http://archive.ubuntu.com trusty Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
Err http://archive.ubuntu.com trusty-updates Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
Err http://archive.ubuntu.com trusty-security Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
Err http://archive.ubuntu.com trusty-proposed Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/InRelease  
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/InRelease  
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-security/InRelease  
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/InRelease  
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/Release.gpg  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-security/Release.gpg  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/Release.gpg  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Container IFCONFIG / PING

➜  code  docker run -it ubuntu /bin/bash
root@7bc182bf87bb:/# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:04  
          inet addr:172.17.0.4  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:4/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:738 (738.0 B)  TX bytes:648 (648.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@7bc182bf87bb:/# ping google.com
PING google.com (74.125.226.0) 56(84) bytes of data.
64 bytes from lga15s42-in-f0.1e100.net (74.125.226.0): icmp_seq=1 ttl=56 time=12.3 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 12.367/12.367/12.367/0.000 ms
root@7bc182bf87bb:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=44 time=21.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=44 time=21.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=44 time=21.7 ms

Além disso, a atualização do apt-get falha quando eu forço o IPv4:

root@6d925cdf84ad:/# sudo apt-get update -o Acquire::ForceIPv4=true
Err http://archive.ubuntu.com trusty InRelease

Err http://archive.ubuntu.com trusty-updates InRelease

Err http://archive.ubuntu.com trusty-security InRelease

Err http://archive.ubuntu.com trusty-proposed InRelease

Err http://archive.ubuntu.com trusty Release.gpg
  Unable to connect to archive.ubuntu.com:http: [IP: 91.189.88.153 80]
Err http://archive.ubuntu.com trusty-updates Release.gpg
  Unable to connect to archive.ubuntu.com:http: [IP: 91.189.88.153 80]
Err http://archive.ubuntu.com trusty-security Release.gpg
  Unable to connect to archive.ubuntu.com:http: [IP: 91.189.88.153 80]
Err http://archive.ubuntu.com trusty-proposed Release.gpg
  Unable to connect to archive.ubuntu.com:http: [IP: 91.189.88.153 80]
Reading package lists... Done
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/InRelease

— Thomas V.
fonte

Para mim, funcionou após um reinício.

— ssi-anik

64

Uau, encontrei um post no github que resolveu meu problema.

Depois que Steve K. apontou que não era realmente um problema de DNS e era um problema de conectividade, consegui encontrar uma postagem no github que descrevia como corrigir esse problema.

Aparentemente, a ponte de rede docker0 foi desligada. Instalar bridge-utils e executar o seguinte colocou meu Docker em ordem de funcionamento:

apt-get install bridge-utils
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
service docker restart

— Thomas V.
fonte

1

você não precisa rebulidar suas imagens. O resolv.conf é gerado toda vez que você executa um novo contêiner. então você precisa remover o contêiner antigo e iniciar outro. Ontem eu estava com esse problema. Além disso, se você estiver na intranet corporativa, poderá passar --dns-search = your.company.domain para o daemon docker em / etc / default / docker na variável env DOCKER_OPTS env perto dos sinalizadores --dns --dns.

— Alexander.Iljushkin

Isso corrigiu meus problemas no docker também.

— BobMcGee

3

No arch linux eu precisava em ip link set down docker0vez de ifconfig docker0 downe em systemctl restart dockervez de service docker start. Para excluir todas as imagens, fizdocker rmi $(docker images -q)

— meshy

Isso funcionou da primeira vez para mim. Depois reiniciei e o problema reapareceu: a reprodução dessas etapas não corrigiu o problema novamente. Eu não tenho idéia do que se trata.

— user626921

1

Só vi que minha interface docker0 estava para baixo, eu executado /etc/init.d/docker restarte ele está de volta aos negócios

— lolesque

14

Se for um problema do resolvedor de DNS, aqui está a solução:

A primeira coisa a verificar é executar cat /etc/resolv.confno contêiner do docker . Se ele tiver um servidor DNS inválido, como, por exemplo nameserver 127.0.x.x, o contêiner não conseguirá resolver os nomes de domínio em endereços IP, portanto ping google.comfalhará.

A segunda coisa a verificar é executar cat /etc/resolv.confna máquina host . O Docker basicamente copia o host /etc/resolv.confpara o contêiner toda vez que um contêiner é iniciado. Portanto, se o host /etc/resolv.confestiver errado, o contêiner de dock também estará.

Se você descobriu que o host /etc/resolv.confestá errado, você tem 2 opções:

Codifique o servidor DNS em daemon.json. Isso é fácil, mas não ideal, se você espera que o servidor DNS seja alterado.
Corrija os hosts /etc/resolv.conf. Isso é um pouco mais complicado, mas é gerado dinamicamente e você não está codificando o servidor DNS.

1. Servidor DNS codificado no docker daemon.json

Editar /etc/docker/daemon.json
```
{
    "dns": ["10.1.2.3", "8.8.8.8"]
}
```
Reinicie o daemon do docker para que essas alterações entrem em vigor:
sudo systemctl restart docker
Agora, quando você executa / inicia um contêiner, o docker será preenchido /etc/resolv.confcom os valores de daemon.json.

2. Corrija os hosts /etc/resolv.conf

A. Ubuntu 16.04 e versões anteriores

Para o Ubuntu 16.04 e versões anteriores, /etc/resolv.confera gerado dinamicamente pelo NetworkManager.
Comente a linha dns=dnsmasq(com a #) em /etc/NetworkManager/NetworkManager.conf
Reinicie o NetworkManager para gerar novamente /etc/resolv.conf:
sudo systemctl restart network-manager
Verifique no host: cat /etc/resolv.conf

B. Ubuntu 18.04 e posterior

O Ubuntu 18.04 foi alterado para usar systemd-resolvedpara gerar/etc/resolv.conf . Agora, por padrão, ele usa um cache DNS local 127.0.0.53. Isso não funcionará dentro de um contêiner; portanto, o Docker usará como padrão o servidor DNS 8.8.8.8 do Google, que pode ser interrompido por pessoas protegidas por um firewall.
/etc/resolv.confé na verdade um link simbólico ( ls -l /etc/resolv.conf) que aponta para /run/systemd/resolve/stub-resolv.conf(127.0.0.53) por padrão no Ubuntu 18.04.
Basta alterar o link simbólico para apontar /run/systemd/resolve/resolv.conf, que lista os servidores DNS reais:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Verifique no host: cat /etc/resolv.conf

Agora você deve ter um válido /etc/resolv.confno host para o docker copiar nos contêineres.

— wisbucky
fonte

Obrigado por isso, estava realmente perdendo a cabeça tentando entender o que estava acontecendo com os contêineres do docker e 18.04 resolvendo IPs em uma VPN. Corrigir /etc/resolv.conf para 18.04 funcionou para mim!

— George Papas

a opção B funcionou para mim ..

— codeSetter

Certamente 2B não vai sobreviver a uma atualização do systemdpacote ...

— Auspex

13

Na tentativa de agregar valor adicional a um problema, também experimentei; com uma resposta alternativa:

Minha rede estava relacionada ao escritório e as configurações de DNS do Google foram bloqueadas para que o contêiner pudesse efetuar ping nos endereços IP, mas não nos nomes de domínio.

Meu anfitrião era /etc/resolv.conforiginalmente;

#Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search companyDomain.co.za

Isso ocorre porque o Network Manager faz algum tipo de mascaramento dos detalhes do servidor DNS.

Infelizmente, de acordo com os manuais do docker, o docker filtrará todos os endereços IP do host local ao criar o resolv.conf do contêiner e os substituirá pelos IPs DNS do Google. O que, no meu caso, fez com que os nomes de domínio estivessem fora dos limites.

Eu precisei:

Redefina my /etc/default/dockerpara o padrão, para que os contêineres usem o conteúdo resolv.conf do meu host.
Edite /etc/NetworkManager/NetworManager.confe comente a linha dns=dnsmasq. Isso significa que o NM pode especificar os endereços IP DNS reais em vez de 127.0.0.1.
Reinicie o NM com sudo service network-manager restart.
Reinicie o serviço de docker com sudo service docker restart.

A execução de um contêiner permitiria apt-get update/upgrade, por exemplo.

— David 'o gengibre careca'
fonte

3

Isso realmente funcionou para mim. E eu estava por trás da intranet da empresa

— Daniel Andrei Mincă

1

Esta solução funciona muito bem para o Ubuntu 16.04 e versões anteriores. Para o Ubuntu 18.04 e

— versões

Obrigado! Isso funcionou, enquanto a resposta aceita não. :)

— Devolus

8

Seu erro está aqui:

 Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8c01::19).
 connect (101: Network is unreachable) [IP: 2001:67c:1360:8c01::19 80]

Este não é um erro no DNS; seu sistema está tentando se conectar aos hosts IPv6 e está falhando. Presumivelmente, porque você não tem acesso IPv6 no seu host. A pesquisa real do endereço IPv6 foi bem-sucedida. (O espelho / arquivo morto do ubuntu está disponível tanto no IPv6 quanto no IPv4. Você teve a infelicidade de encontrar um IPv6 porque o seu sistema acredita que deveria funcionar.)

Você deve corrigir isso instalando o miredo ou tentar novamente até atingir um espelho IPv4.

Novamente, o importante a ser percebido aqui é que o DNS não é o culpado, como você pode ver pelos seus próprios testes de ping.

1

Obrigado pela resposta rápida e por esclarecer que não é realmente um problema de DNS, agradeço. Eu instalei o miredo - não vai. Também é importante notar que, quando eu executo o apt-get update -o Acquire :: ForceIPv4 = true, a atualização do apt-get ainda falha, atualizei minha postagem original com essa resposta. Tentei desativar o UFW pensando que talvez fosse esse o caso, e ainda não tive sorte.

— Thomas V.

Estranho - você pode ver que possui conectividade IPv4 porque seu ping foi bem-sucedido. Mas você não pode conectar-se ao espelho, independentemente sugere que você tem algum encaminhamento ímpar / problema de rede (que eu acho que é por isso que você está postando aqui!)

8

O documento oficial do Docker fornece instrumentos para configurar um servidor DNS para uso do Docker

Abra o /etc/default/dockerarquivo para edição:
```
sudo nano /etc/default/docker
```
Adicione uma configuração para o Docker:
```
DOCKER_OPTS="--dns 8.8.8.8"
```
Substitua 8.8.8.8por um servidor DNS local, como 192.168.1.1. Você também pode especificar vários servidores DNS. Separei-os com espaços, por exemplo:
```
--dns 8.8.8.8 --dns 192.168.1.1
```
Aviso: se você estiver fazendo isso em um laptop conectado a várias redes, escolha um servidor DNS público.

PS: nm-toolpode ser usado para verificar o servidor DNS do host local
Salve e feche o arquivo.
Reinicie o daemon do Docker.
```
sudo service docker restart
```

— tryer3000
fonte

Observe que esse é o arquivo de configuração antigo do Docker Upstart e do SysVinit. A maneira atual do systemd (desde o Ubuntu 16.04) é usar /etc/docker/daemon.jsonpara configurações do daemon do docker , como dns.

— wisbucky

0

Para outros leitores que vêm aqui enquanto usam o boot2docker, aqui está como eu consertei. De fato, a resposta acima me indicou a direção certa.

Basicamente, por algum motivo, os contêineres no boot2docker não conseguiram resolver os nomes de host.

Então, eu apenas reiniciei o boot2docker e iniciei os contêineres. Agora, os nomes de host podem resolver corretamente novamente.

Suponho que o problema foi iniciar o boot2docker enquanto a rede no host estava sendo conectada, o que fez com que o boot2docker fosse inicializado e entrado em um estado não funcional.

— Olho
fonte

0

Eu tive o mesmo problema no Windows. Este comando fez funcionar para mim:docker-machine restart

— speedplane
fonte

0

Reinicie o daemon Docker no Debian9

service docker restart

e as conexões e redes funcionam bem

— Nolwennig
fonte

-1

Tinha um problema semelhante, mas também a resolução de nomes entre contêineres dentro de uma rede definida pelo usuário parecia um pouco esquisita. Alguns não conseguiram resolver nada como você.

O problema foi um / var / lib / docker movido. Por razões de espaço, ele foi montado via nfs. Adicionar um sistema de arquivos local e mover os arquivos para lá resolve o problema.

— michi.0x5d
fonte

Se você acha que uma pergunta pode ser respondida por uma resposta semelhante, marque-a como uma duplicata dessa pergunta. Se você não puder fazer isso, deixe um comentário em vez de torná-lo uma resposta separada.

— Jenny D diz Reinstate Monica