Os contêineres do Docker não podem resolver o DNS no host de desktop do Ubuntu 14.04

43

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

Eu desabilitei o IPv6 na minha máquina host e ainda assim, removi todas as imagens, baixei o Ubuntu, e ainda corri para o problema.

Mudei meus servidores de nomes /etc/resolve.conf do meu servidor DNS local para os servidores DNS públicos do Google (8.8.8.8 e 8.8.4.4) e ainda não tive sorte. Eu também configurei o DNS para o Google no DOCKER_OPTS do / etc / default / docker e reiniciei o docker.

Eu também tentei extrair o 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 faço ping nos 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 (eu instalei dois dias atrás para estar mais perto do docker).

Eu pesquisei isso por meio de outras postagens sobre problemas no stackoverflow e no github, mas não encontrei nenhuma resolução. Estou sem ideias de como resolver este 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.

Contêiner 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, o apt-get update 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  
    
por Thomas V. 08.11.2014 / 19:26

10 respostas

54

Woo, encontrei uma postagem 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, eu consegui encontrar uma postagem no github que descreve como corrigir esse problema.

Aparentemente, a ponte de rede docker0 foi desligada. A instalação do bridge-utils e a execução do seguinte incluem o meu Docker em funcionamento:

apt-get install bridge-utils
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
service docker restart
    
por 08.11.2014 / 20:09
10

Na tentativa de adicionar 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 fazer ping de endereços IP, mas não nomes de domínio.

O /etc/resolv.conf de meu host originalmente parecia:

#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 o manuais de encaixe , a janela de encaixe filtrará todos os endereços IP de localhost ao criar o resolv.conf do contêiner e substituí-los pelos IPs de DNS do Google. O que no meu caso causou nomes de domínio fora dos limites.

Eu tive que:

  • Redefinir meu /etc/default/docker como padrão para que os contêineres usem o conteúdo resolv.conf do meu host.
  • Edite /etc/NetworkManager/NetworManager.conf e comente a linha dns=dnsmasq . Isso é tão NM pode especificar os endereços IP do DNS em vez de 127.0.0.1.
  • Reinicie o NM com sudo service network-manager restart .
  • Reinicie o serviço de encaixe com sudo service docker restart .

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

    
por 26.07.2016 / 11:43
7

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]

Isso não é um erro com o DNS, em vez disso, seu sistema está tentando se conectar a hosts IPv6 e falhando. Presumivelmente porque você não tem acesso IPv6 no seu host. A pesquisa real do endereço IPv6 é bem-sucedida. (O espelho / arquivo do ubuntu está disponível tanto no IPv6 quanto no IPv4. Você teve o azar de acertar um IPv6 porque seu sistema acredita que ele deveria funcionar.)

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

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

    
por 08.11.2014 / 19:38
7

Documento oficial do Docker fornece instrumentos para configurar um servidor DNS para uso pelo Docker

  1. Abra o arquivo /etc/default/docker para edição:

    sudo nano /etc/default/docker
    
  2. Adicione uma configuração para o Docker:

    DOCKER_OPTS="--dns 8.8.8.8"
    
  3. Substitua 8.8.8.8 por um servidor DNS local, como 192.168.1.1 . Você pode também especifica vários servidores DNS. Separa-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-tool pode ser usado para verificar o servidor DNS do host local

  4. Salve e feche o arquivo.

  5. Reinicie o daemon do Docker.

    sudo restart docker
    
por 27.05.2015 / 07:48
6

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

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

A segunda coisa a verificar é executar cat /etc/resolv.conf na máquina host . O Docker basicamente copia o /etc/resolv.conf do host para o contêiner toda vez que um contêiner é iniciado. Portanto, se o /etc/resolv.conf do host estiver errado, o mesmo acontecerá com o contêiner do docker.

Se você descobriu que o /etc/resolv.conf do host está errado, então você tem duas opções:

  1. Codifique o servidor DNS no daemon.json. Isso é fácil, mas não é ideal se você espera que o servidor DNS mude.

  2. Corrija /etc/resolv.conf dos hosts. Isso é um pouco mais complicado, mas é gerado dinamicamente e você não está codificando o servidor DNS.

1. Hardcode DNS server in docker daemon.json

  • Edite o /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ê executar / iniciar um contêiner, o docker preencherá /etc/resolv.conf com os valores de daemon.json .

2. Corrigir /etc/resolv.conf dos hosts

Ubuntu 16.04 e anteriores

  • Para o Ubuntu 16.04 e anteriores, /etc/resolv.conf foi gerado dinamicamente pelo NetworkManager.

  • Comente a linha dns=dnsmasq (com # ) em /etc/NetworkManager/NetworkManager.conf

  • Reinicie o NetworkManager para gerar /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-resolved para 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, de modo que o Docker usará como padrão o servidor DNS 8.8.8.8 do Google, que pode ser usado por pessoas protegidas por 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 para /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 /etc/resolv.conf válido no host para o Docker copiar nos contêineres.

    
por 28.06.2018 / 01:06
0

Para outros leitores que vêm aqui usando boot2docker, aqui está como eu consertei. Na verdade, a resposta acima me indicou a direção certa.

Basicamente, por algum motivo, os contêineres dentro do boot2docker não puderam resolver nomes de host.

Então eu apenas reiniciei o boot2docker e iniciei os containers. Agora os nomes de host podem ser resolvidos corretamente novamente.

Suponho que o problema era iniciar o boot2docker enquanto a rede no host estava sendo conectada, o que fazia com que o boot2docker inicializasse e entrasse em um estado não funcional.

    
por 23.06.2015 / 03:42
0

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

    
por 12.08.2016 / 00:16
0

Reinicie o daemon do Docker no Debian9

service docker restart

e as conexões e redes funcionam bem

    
por 07.06.2018 / 17:30
-1

Teve um problema semelhante, mas também a resolução de nomes entre contêineres dentro de uma rede definida pelo usuário parecia ser 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, foi montado via nfs. Adicionar um sistema de arquivos local e mover os arquivos para lá resolve o problema.

    
por 10.08.2017 / 12:54
-1

Eu tenho Docker version 1.12.6, build 78d1802 e foi o suficiente para reiniciar o docker para mim (no Ubuntu 16.04).

$ sudo systemctl restart docker
    
por 21.09.2017 / 18:52