Los contenedores Docker no pueden resolver DNS en Ubuntu 14.04 Desktop Host

48

Me encuentro con un problema con mis contenedores Docker en Ubuntu 14.04 LTS. Docker funcionó bien durante dos días, y de repente perdí toda la conectividad de red dentro de mis contenedores. La salida de error a continuación inicialmente me llevó a creer que era porque apt-get está tratando de resolver el DNS a través de IPv6.

Inhabilité IPv6 en mi máquina host y aún así, eliminé todas las imágenes, extraje ubuntu base y aún me encontré con el problema.

Cambié mis servidores de nombres /etc/resolve.conf de mi servidor DNS local a los servidores DNS públicos de Google (8.8.8.8 y 8.8.4.4) y todavía no tengo suerte. También configuré el DNS en Google en DOCKER_OPTS de / etc / default / docker y reinicié docker.

También intenté extraer coreos, y yum tampoco pudo resolver DNS.

Es extraño porque si bien el DNS no funciona, sigo recibiendo una respuesta cuando hago ping en los mismos servidores de actualización que apt-get no puede resolver.

No estoy detrás de un proxy, estoy en una red local muy estándar, y esta versión de Ubuntu está actualizada y actualizada (la instalé hace dos días para estar más cerca de Docker).

He investigado a fondo esto a través de otras publicaciones sobre problemas de stackoverflow y github, pero no he encontrado ninguna resolución. No tengo ideas sobre cómo resolver este problema, ¿alguien puede ayudarme?

Mensaje de error

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

Contenedor 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

Además, la actualización de apt-get falla cuando forzo 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
ubuntu  networking  domain-name-system  docker  lxc 
— Thomas V.
fuente
Para mí, funcionó después de un reinicio.
— ssi-anik

Respuestas:

64

Woo, encontré una publicación en github que resolvió mi problema.

Después de que Steve K. señaló que en realidad no era un problema de DNS y era un problema de conectividad, pude encontrar una publicación en github que describía cómo solucionar este problema.

Aparentemente, el puente de red docker0 estaba colgado. Instalar bridge-utils y ejecutar lo siguiente hizo que mi Docker funcionara correctamente:

apt-get install bridge-utils
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
service docker restart
— Thomas V.
fuente
1
no necesitas volver a crear tus imágenes. resolv.conf se genera cada vez que ejecuta un nuevo contenedor. por lo tanto, debe eliminar el contenedor antiguo y comenzar otro. Ayer me solucionaron este problema. Además, si está en la intranet corporativa, puede pasar --dns-search = your.company.domain al dacker de docker en / etc / default / docker en la variable env DOCKER_OPTS cerca de las banderas --dns --dns.
— Alexander.Iljushkin
Esto solucionó mis problemas de Docker también.
— BobMcGee
3
En Arch Linux necesitaba en ip link set down docker0lugar de ifconfig docker0 downy en systemctl restart dockerlugar de service docker start. Para eliminar todas las imágenes, lo hicedocker rmi $(docker images -q)
— meshy
Eso funcionó la primera vez para mí. Luego reinicié y el problema reapareció: la reproducción de esos pasos no solucionó el problema nuevamente. No tengo ni idea de qué se trata.
— user626921
1
Acabo de ver que mi interfaz docker0 estaba inactiva, ejecuté /etc/init.d/docker restarty volvió a funcionar
— lolesque el
14

Si se trata de un problema de resolución de DNS, aquí está la solución:

Lo primero que debe verificar es ejecutar cat /etc/resolv.confen el contenedor acoplable . Si tiene un servidor DNS no válido, como nameserver 127.0.x.x, entonces el contenedor no podrá resolver los nombres de dominio en direcciones IP, por ping google.comlo que fallará.

La segunda cosa a verificar se ejecuta cat /etc/resolv.confen la máquina host . Docker básicamente copia los hosts /etc/resolv.confal contenedor cada vez que se inicia un contenedor. Entonces, si el host /etc/resolv.confestá equivocado, también lo hará el contenedor docker.

Si descubrió que el host /etc/resolv.confestá equivocado, entonces tiene 2 opciones:

  1. Codifique el servidor DNS en daemon.json. Esto es fácil, pero no es ideal si espera que cambie el servidor DNS.

  2. Arreglar los anfitriones /etc/resolv.conf. Esto es un poco más complicado, pero se genera dinámicamente y no está codificando el servidor DNS.

1. Hardcode servidor DNS en docker daemon.json

  • Editar /etc/docker/daemon.json

    {
    "dns": ["10.1.2.3", "8.8.8.8"]
}

  • Reinicie el Docker Daemon para que esos cambios surtan efecto:
    sudo systemctl restart docker

  • Ahora, cuando ejecuta / inicia un contenedor, Docker se completará /etc/resolv.confcon los valores de daemon.json.

2. Arreglar los hosts /etc/resolv.conf

A. Ubuntu 16.04 y anterior

  • Para Ubuntu 16.04 y versiones anteriores, /etc/resolv.conffue generado dinámicamente por NetworkManager.

  • Comente la línea dns=dnsmasq(con a #) en /etc/NetworkManager/NetworkManager.conf

  • Reinicie el NetworkManager para regenerar /etc/resolv.conf:
    sudo systemctl restart network-manager

  • Verificar en el host: cat /etc/resolv.conf

B. Ubuntu 18.04 y posterior

  • Ubuntu 18.04 cambió para usar systemd-resolvedpara generar/etc/resolv.conf . Ahora, por defecto, utiliza un caché de DNS local 127.0.0.53. Eso no funcionará dentro de un contenedor, por lo que Docker usará de forma predeterminada el servidor DNS 8.8.8.8 de Google, lo que puede dañar a las personas detrás de un firewall.

  • /etc/resolv.confen realidad es un enlace simbólico ( ls -l /etc/resolv.conf) que apunta a /run/systemd/resolve/stub-resolv.conf(127.0.0.53) de forma predeterminada en Ubuntu 18.04.

  • Simplemente cambie el enlace simbólico al que apunta /run/systemd/resolve/resolv.conf, que enumera los servidores DNS reales:
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

  • Verificar en el host: cat /etc/resolv.conf

Ahora debería tener un válido /etc/resolv.confen el host para que Docker lo copie en los contenedores.

— Wisbucky
fuente
Gracias por esto, realmente estaba perdiendo la cabeza tratando de entender lo que estaba sucediendo con los contenedores acoplables y 18.04 resolviendo IP en una VPN. ¡Arreglar /etc/resolv.conf para 18.04 funcionó para mí!
— George Papas
la opción B funcionó para mí ..
— codeSetter
Seguramente 2B no sobrevivirá a una actualización del systemdpaquete ...
— Auspex
13

En un intento de agregar valor adicional a un problema que también experimenté; con una respuesta alternativa:

Mi red estaba relacionada con la oficina y la configuración de DNS de Google estaba bloqueada para que el contenedor pudiera hacer ping a las direcciones IP pero no a los nombres de dominio.

Mi anfitrión se /etc/resolv.confparecía originalmente;

#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

Esto se debe a que Network Manager realiza algún tipo de enmascaramiento de los detalles del servidor DNS.

Desafortunadamente, de acuerdo con los manuales de la ventana acoplable, la ventana acoplable filtrará las direcciones IP de host local al crear la resolv.conf del contenedor y las reemplazará con las IP DNS de Google. Lo que en mi caso hizo que los nombres de dominio estuvieran fuera de los límites.

Tuve que:

  • Restablezca mi /etc/default/dockervalor predeterminado para que los contenedores usen el contenido resolv.conf de mi host.
  • Edite /etc/NetworkManager/NetworManager.confy comente la línea dns=dnsmasq. Esto es para que NM pueda especificar las direcciones IP DNS reales en lugar de 127.0.0.1.
  • Reinicie NM con sudo service network-manager restart.
  • Reinicie el servicio acoplable con sudo service docker restart.

Ejecutar un contenedor le permitiría hacerlo apt-get update/upgrade, por ejemplo.

— David 'el jengibre calvo'
fuente
3
Esto realmente funcionó para mí. Y estaba detrás de la intranet de la empresa
— Daniel Andrei Mincă
1
Esta solución funciona muy bien para Ubuntu 16.04 y versiones anteriores. Para Ubuntu 18.04 y posterior, consulte serverfault.com/a/918568
— wisbucky el
¡Gracias! Esto funcionó, mientras que la respuesta aceptada no. :)
— Devolus
8

Tu error está aquí:

 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]

Esto no es un error con DNS, sino que su sistema está intentando conectarse a hosts IPv6 y falla. Presumiblemente porque no tiene acceso IPv6 en su host. La búsqueda real de la dirección IPv6 tiene éxito. (El espejo / archivo ubuntu está disponible tanto en IPv6 como en IPv4. Tuviste la mala suerte de golpear uno IPv6 porque tu sistema cree que debería funcionar).

Debería solucionarlo instalando miredo o volver a intentarlo hasta que llegue a un espejo IPv4.

Una vez más, lo importante a tener en cuenta aquí es que el DNS no tiene la culpa, como puede ver en sus propias pruebas de ping.

1
Gracias por la rápida respuesta y aclarando que en realidad no es un problema de DNS, lo agradezco. Instalé miredo, no te vayas. También vale la pena señalar que cuando ejecuto apt-get update -o Acquire :: ForceIPv4 = true apt-get update todavía falla, he actualizado mi publicación original con esa respuesta. He intentado deshabilitar UFW pensando que tal vez ese era el caso, y todavía no he tenido suerte.
— Thomas V.
Extraño: puede ver que tiene conectividad IPv4 porque su ping tiene éxito. Pero no se puede conectar al espejo sin sugiere que tiene algún problema de enrutamiento par / redes (que supongo que es por eso que está publicando aquí!)
8

El documento oficial de Docker proporciona instrumentos para configurar un servidor DNS para que Docker lo use

  1. Abra el /etc/default/dockerarchivo para editar:

    sudo nano /etc/default/docker

  2. Agregue una configuración para Docker:

    DOCKER_OPTS="--dns 8.8.8.8"

  3. Reemplace 8.8.8.8con un servidor DNS local como 192.168.1.1. También puede especificar múltiples servidores DNS. Los separó con espacios, por ejemplo:

    --dns 8.8.8.8 --dns 192.168.1.1

    Advertencia: si está haciendo esto en una computadora portátil que se conecta a varias redes, asegúrese de elegir un servidor DNS público.

    PD: nm-toolse puede usar para verificar el servidor DNS del host local

  4. Guarde y cierre el archivo.

  5. Reinicia el demonio Docker.

    sudo service docker restart
— tryer3000
fuente
Tenga en cuenta que este es el archivo de configuración anterior para Docker Upstart y SysVinit. La forma actual de systemd (desde Ubuntu 16.04) es usar la /etc/docker/daemon.jsonconfiguración de Docker Daemon como dns.
— wisbucky
0

Para otros lectores que vienen aquí mientras usan boot2docker, así es como lo solucioné. De hecho, la respuesta anterior me indicó la dirección correcta.

Básicamente, por alguna razón, los contenedores dentro de boot2docker no pudieron resolver los nombres de host.

Así que simplemente reinicié boot2docker y comencé los contenedores. Ahora los nombres de host pueden resolverse correctamente nuevamente.

Supongo que el problema fue iniciar boot2docker mientras se conectaba la red en el host, lo que provocó que boot2docker se iniciara y entrara en un estado que no funciona.

— Ojo
fuente
0

Tuve el mismo problema en Windows. Este comando me funcionó:docker-machine restart

— Speedplane
fuente
0

Reinicie el demonio Docker en Debian9

service docker restart

y las conexiones y redes funcionan bien

— Nolwennig
fuente
-1

Tuve un problema similar, pero también la resolución de nombres entre contenedores dentro de una red definida por el usuario parecía un poco escasa. Algunos no pudieron resolver nada como tú.

El problema fue un / var / lib / docker movido. Por razones de espacio, se montó a través de nfs. Agregar un sistema de archivos local y mover los archivos allí resuelve el problema.

— michi.0x5d
fuente
Si cree que una pregunta puede ser respondida con una pregunta similar, márquela como un duplicado de esa pregunta. Si no puede hacer eso, debe dejar un comentario en lugar de responderlo por separado.
— Jenny D dice Reinstate Monica
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.