Los contenedores Docker no pueden resolver DNS en el host de escritorio Ubuntu 14.04

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

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

Cambié mi/etc / resolve.conf servidores de nombres 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 aunque DNS no funciona, sigo recibiendo una respuesta cuando hago ping a 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 fresca (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 ayudar?

Mensaje de Error

➜  arthouse git:(docker) ✗ docker build --no-cache .Sending build context to Docker daemon 51.03 MBSending build context to Docker daemon Step 0 : FROM ubuntu:14.04 ---> 5506de2b643bStep 1 : RUN apt-get update ---> Running in 845ae6abd1e0Err http://archive.ubuntu.com trusty InReleaseErr http://archive.ubuntu.com trusty-updates InReleaseErr 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/bashroot@7bc182bf87bb:/# ifconfigeth0      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.comPING 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 0msrtt min/avg/max/mdev = 12.367/12.367/12.367/0.000 msroot@7bc182bf87bb:/# ping 8.8.8.8PING 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 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=44 time=21.7 ms64 bytes from 8.8.8.8: icmp_seq=3 ttl=44 time=21.7 ms

Además, apt-get update falla cuando fuerzo IPv4:

root@6d925cdf84ad:/# sudo apt-get update -o Acquire::ForceIPv4=trueErr http://archive.ubuntu.com trusty InReleaseErr http://archive.ubuntu.com trusty-updates InReleaseErr http://archive.ubuntu.com trusty-security InReleaseErr http://archive.ubuntu.com trusty-proposed InReleaseErr 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... DoneW: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/InRelease  

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 que era un problema de conectividad, pude encontrar una publicación en github eso describe cómo solucionar este problema.

Aparentemente, el puente de red docker0 estaba colgado. La instalación de bridge-utils y la ejecución de lo siguiente pusieron en funcionamiento mi Docker:

apt-get install bridge-utilspkill dockeriptables -t nat -Fifconfig docker0 downbrctl delbr docker0service docker restart

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

Lo primero que hay que comprobar es ejecutar cat /etc/resolv.conf en el contenedor docker. 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 lo que ping google.com fracasará.

La segunda cosa a verificar es ejecutar cat /etc/resolv.conf en el máquina host. Docker básicamente copia el host /etc/resolv.conf al contenedor cada vez que se inicia un contenedor. Así que si el anfitrión /etc/resolv.conf está mal, entonces también lo estará el contenedor docker.

Si ha encontrado que el anfitrión /etc/resolv.conf está mal, entonces tienes 2 opciones:

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

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


1. Servidor DNS de código fijo en el demonio docker.json

  • Editar /etc/docker/daemon.json

    {    "dns": ["10.1.2.3", "8.8.8.8"]}
  • Reinicie el demonio de Docker para que esos cambios surtan efecto:
    sudo systemctl restart docker

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


2. Arregle los hosts /etc/resolv.conf

A. Ubuntu 16.04 y versiones anteriores

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

  • Comentar fuera de la línea dns=dnsmasq (con una #) 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 posteriores

  • Ubuntu 18.04 cambiado de uso systemd-resolved generar /etc/resolv.conf. Ahora, de forma predeterminada, utiliza una caché 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, que puede romperse para las personas detrás de un firewall.

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

  • Simplemente cambie el enlace simbólico para apuntar a /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 usted debe tener una válida /etc/resolv.conf en el host para que docker copie en los contenedores.

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 se bloqueó para que el contenedor pudiera hacer ping a las direcciones IP pero no a los nombres de dominio.

Mi host /etc/resolv.conf originalmente parecía;

#Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)#DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTENnameserver 127.0.1.1search 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 el manuales de docker docker filtrará cualquier dirección IP de host local al crear la resolución del contenedor.conf y reemplácelas con las direcciones IP DNS de Google. Lo que en mi caso hizo que los nombres de dominio estuvieran fuera de los límites.

Tuve que:

  • Restablecer mi /etc/default/docker para hacerlo de forma predeterminada, use la resolución de mi host.contenido conf en su lugar.
  • Editar /etc/NetworkManager/NetworManager.conf y comentar 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 Docker con sudo service docker restart.

La ejecución de un contenedor le permitiría hacer apt-get update/upgrade por ejemplo.

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

  1. Abra la /etc/default/docker archivo para editar:

    sudo nano /etc/default/docker
  2. Agregar una configuración para Docker:

    DOCKER_OPTS="--dns 8.8.8.8"
  3. Reemplazar 8.8.8.8 con un servidor DNS local como 192.168.1.1. También puede especificar varios servidores DNS. Separados 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.

    PS: nm-tool se puede usar para verificar el servidor DNS del host local

  4. Guarde y cierre el archivo.

  5. Reinicie el demonio de Docker.

    sudo service docker restart

Su 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 a IPv6 en su host. La búsqueda real de la dirección IPv6 se realiza correctamente. (El espejo/archivo de ubuntu está disponible tanto en IPv6 como en IPv4. Simplemente tuvo la mala suerte de encontrar uno IPv6 porque su sistema cree que debería funcionar.)

Deberías arreglar eso, por instalación de miredo, o vuelva 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.

Para otros lectores que vienen aquí mientras usan boot2docker, así es como lo arreglé. De hecho, la respuesta anterior me señaló en la dirección correcta.

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

Así que reinicié boot2docker e inicié los contenedores. Ahora los nombres de host pueden resolverse correctamente de nuevo.

Supongo que el problema estaba iniciando boot2docker mientras se conectaba la red en el host, lo que provocó que boot2docker se iniciara y entrara en un estado que no funcionaba.

Me encontré con este problema cuando permití que el instalador de Ubuntu instalara el paquete Docker snap. Cuando abandoné eso y cambié al paquete oficial de Docker, el problema se resolvió solo.

sudo snap remove dockercurl -fsSL https://get.docker.com -o get-docker.shsh get-docker.sh

Abrir el archivo /lib/systemd/system/docker.service

En ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sockañadir
--dns 8.8.8.8

Como esto:

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --dns 8.8.8.8

Reiniciar el servicio Docker

Tuve el mismo problema en Windows. Este comando lo hizo funcionar para mí: docker-machine restart

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

El problema era 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.

Para mí, funcionó después de un reinicio.