Les conteneurs Docker ne peuvent pas résoudre DNS sur Ubuntu 14.04 Desktop Host

Question

Je rencontre un problème avec mes conteneurs Docker sur Ubuntu 14.04 LTS. Docker a bien fonctionné pendant deux jours, puis j'ai soudainement perdu toute connectivité réseau à l'intérieur de mes conteneurs. La sortie d'erreur ci-dessous m'a initialement fait croire que c'était parce qu'apt-get essayait de résoudre le DNS via IPv6.

J'ai désactivé IPv6 sur ma machine hôte et malgré tout, j'ai supprimé toutes les images, tiré la base ubuntu et j'ai quand même rencontré le problème.

J'ai changé mes serveurs de noms /etc/resolve.conf de mon serveur DNS local en serveurs DNS publics de Google (8.8.8.8 et 8.8.4.4) et je n'ai toujours pas de chance. J'ai également défini le DNS sur Google dans le DOCKER_OPTS de/etc/default/docker et redémarré docker.

J'ai également essayé de tirer des coreos, et yum n'a pas pu résoudre le DNS non plus.

C'est bizarre parce que même si DNS ne fonctionne pas, j'obtiens toujours une réponse lorsque je ping sur les mêmes serveurs de mise à jour qu'apt-get ne peut pas résoudre.

Je ne suis pas derrière un proxy, je suis sur un réseau local très standard, et cette version d'Ubuntu est à jour et fraîche (je l'ai installée il y a deux jours pour être plus proche de docker).

J'ai fait des recherches approfondies à ce sujet dans d'autres articles sur les problèmes de stackoverflow et de github, mais je n'ai trouvé aucune résolution. Je n'ai plus d'idées sur la façon de résoudre ce problème, quelqu'un peut-il m'aider?

Message d'erreur

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

Conteneur 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

De plus, la mise à jour apt-get échoue lorsque je force 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. · Accepted Answer

Woo, j'ai trouvé un post sur github qui a résolu mon problème.

Après que Steve K. ait souligné qu'il ne s'agissait pas réellement d'un problème DNS et d'un problème de connectivité, j'ai pu trouver n message sur github qui décrivait comment résoudre ce problème.

Apparemment, le pont réseau docker0 a été raccroché. L'installation de bridge-utils et l'exécution des éléments suivants ont permis à mon Docker de fonctionner:

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

wisbucky · Answer

S'il s'agit d'un problème de résolveur DNS, voici la solution:

La première chose à vérifier est exécutée cat /etc/resolv.conf dans le conteneur docker . S'il possède un serveur DNS non valide, tel que nameserver 127.0.x.x, le conteneur ne pourra pas résoudre les noms de domaine en adresses IP, donc ping google.com échouera.

La deuxième chose à vérifier est exécutée cat /etc/resolv.conf sur la machine hôte . Docker copie essentiellement le /etc/resolv.conf au conteneur à chaque démarrage d'un conteneur. Donc, si l'hôte /etc/resolv.conf est faux, le conteneur docker aussi.

Si vous avez constaté que l'hôte /etc/resolv.conf est faux, alors vous avez 2 options:

Codez en dur le serveur DNS dans daemon.json. C'est facile, mais pas idéal si vous vous attendez à ce que le serveur DNS change.
Réparez le /etc/resolv.conf. C'est un peu plus délicat, mais il est généré dynamiquement et vous ne codez pas en dur le serveur DNS.

1. Serveur DNS Hardcode dans docker daemon.json

Éditer /etc/docker/daemon.json
```
{ "dns": ["10.1.2.3", "8.8.8.8"] } 
```
Redémarrez le démon docker pour que ces modifications prennent effet:
Sudo systemctl restart docker
Maintenant, lorsque vous exécutez/démarrez un conteneur, docker remplira /etc/resolv.conf avec les valeurs de daemon.json.

2. Réparez le /etc/resolv.conf

A. Ubuntu 16.04 et versions antérieures

Pour Ubuntu 16.04 et versions antérieures, /etc/resolv.conf a été généré dynamiquement par NetworkManager.
Commentez la ligne dns=dnsmasq (avec un #) dans /etc/NetworkManager/NetworkManager.conf
Redémarrez le NetworkManager pour régénérer /etc/resolv.conf:
Sudo systemctl restart network-manager
Vérifiez sur l'hôte: cat /etc/resolv.conf

B. Ubuntu 18.04 et versions ultérieures

Ubuntu 18.04 a changé pour utiliser systemd-resolved générer /etc/resolv.conf . Maintenant, par défaut, il utilise un cache DNS local 127.0.0.53. Cela ne fonctionnera pas à l'intérieur d'un conteneur, donc Docker utilisera par défaut le serveur DNS 8.8.8.8 de Google, qui peut tomber en panne pour les personnes derrière un pare-feu.
/etc/resolv.conf est en fait un lien symbolique (ls -l /etc/resolv.conf) qui pointe vers /run/systemd/resolve/stub-resolv.conf (127.0.0.53) par défaut dans Ubuntu 18.04.
Modifiez simplement le lien symbolique pour pointer sur /run/systemd/resolve/resolv.conf, qui répertorie les vrais serveurs DNS:
Sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Vérifiez sur l'hôte: cat /etc/resolv.conf

Vous devriez maintenant avoir un /etc/resolv.conf sur l'hôte pour docker à copier dans les conteneurs.

David &#39;the bald ginger&#39; · Answer

Pour essayer d'ajouter de la valeur à un problème que j'ai également rencontré; avec une réponse alternative:

Mon réseau était lié au bureau et les paramètres DNS de Google étaient bloqués afin que le conteneur puisse envoyer une requête ping aux adresses IP mais pas aux noms de domaine.

Le /etc/resolv.conf De mon hôte ressemblait à l'origine;

#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

Cela est dû au fait que Network Manager fait une sorte de masquage des détails du serveur DNS.

Malheureusement, selon le manuels des dockers docker filtrera toutes les adresses IP des hôtes locaux lors de la construction du resolv.conf du conteneur et les remplacera par les IP DNS de Google. Ce qui dans mon cas a rendu les noms de domaine hors limites.

J'ai dû:

Réinitialisez mon /etc/default/docker Par défaut pour que les conteneurs utilisent à la place le contenu resolv.conf de mon hôte.
Modifiez /etc/NetworkManager/NetworManager.conf Et commentez la ligne dns=dnsmasq. Il en est ainsi NM peut spécifier les adresses IP DNS réelles au lieu de 127.0.0.1.
Redémarrez NM avec Sudo service network-manager restart.
Redémarrez le service Docker avec Sudo service docker restart.

L'exécution d'un conteneur lui permettrait alors de faire apt-get update/upgrade, Par exemple.

tryer3000 · Answer

Docker official doc donne des instruments pour configurer un serveur DNS à utiliser par Docker

Ouvrez le /etc/default/docker fichier à modifier:
```
Sudo nano /etc/default/docker 
```
Ajoutez un paramètre pour Docker:
```
DOCKER_OPTS="--dns 8.8.8.8" 
```
Remplacer 8.8.8.8 avec un serveur DNS local tel que 192.168.1.1. Vous pouvez également spécifier plusieurs serveurs DNS. Les séparer avec des espaces, par exemple:
```
--dns 8.8.8.8 --dns 192.168.1.1 
```
Avertissement: si vous faites cela sur un ordinateur portable qui se connecte à différents réseaux, assurez-vous de choisir un serveur DNS public.

PS: nm-tool peut être utilisé pour vérifier le serveur DNS hôte local
Enregistrez et fermez le fichier.
Redémarrez le démon Docker.
```
Sudo service docker restart 
```

user9565 · Answer

Votre erreur est ici:

 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]

Ce n'est pas une erreur avec DNS, mais votre système essaie de se connecter aux hôtes IPv6 et échoue. Vraisemblablement parce que vous n'avez pas d'accès IPv6 sur votre hôte. La recherche réelle de l'adresse IPv6 réussit. (Le miroir/archive Ubuntu est disponible à la fois sur IPv6 et IPv4. Vous avez eu la malchance de toucher un IPv6 car votre système pense qu'il devrait fonctionner.)

Vous devez soit résoudre ce problème en installant miredo , soit réessayer jusqu'à ce que vous atteigniez un miroir IPv4.

Encore une fois, la chose importante à réaliser ici est que le DNS n'est pas à blâmer, comme vous pouvez le voir par vos propres tests ping.

Eye · Answer

Pour les autres lecteurs qui viennent ici en utilisant boot2docker, voici comment j'ai corrigé. En fait, la réponse ci-dessus m'a indiqué la bonne direction.

Fondamentalement, pour une raison quelconque, les conteneurs à l'intérieur de boot2docker n'ont pas pu résoudre les noms d'hôte.

J'ai donc juste redémarré boot2docker et démarré les conteneurs. Désormais, les noms d'hôtes peuvent à nouveau se résoudre correctement.

Je suppose que le problème démarrait boot2docker alors que le réseau sur l'hôte était connecté, ce qui a causé le démarrage et le démarrage de boot2docker.

Nolwennig · Answer

Redémarrez le démon Docker sur Debian9

service docker restart

et les connexions et les réseaux fonctionnent bien

speedplane · Answer

J'ai eu le même problème sous Windows. Cette commande l'a fait fonctionner pour moi: docker-machine restart