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

48

Je rencontre un problème avec mes conteneurs Docker sur Ubuntu 14.04 LTS. Docker a bien fonctionné pendant deux jours, puis j'ai soudain perdu toute la connectivité réseau à l'intérieur de mes conteneurs. Les erreurs ci-dessous m'indiquent que c'est parce qu'apt-get tente de résoudre le DNS via IPv6.

J'ai désactivé IPv6 sur mon ordinateur hôte et, malgré tout, j'ai supprimé toutes les images, extrait la base d'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 vers les serveurs DNS publics de Google (8.8.8.8 et 8.8.4.4) et je n'ai toujours pas eu de chance. J'ai également paramétré le DNS sur Google dans DOCKER_OPTS de / etc / default / docker et le docker redémarré.

J'ai aussi 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 le DNS ne fonctionne pas, j'obtiens toujours une réponse lorsque je coche 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 effectué des recherches approfondies à ce sujet dans d'autres publications sur les problèmes de stackoverflow et de github, mais je n'ai trouvé aucune solution. Je suis à court d'idées sur la façon de résoudre ce problème, quelqu'un peut-il 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, apt-get update é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.
source

Pour moi, cela a fonctionné après un redémarrage.

— ssi-anik

64

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 d'un problème de DNS ni d'un problème de connectivité, j'ai pu trouver un message sur github décrivant comment résoudre ce problème.

Apparemment, le pont réseau docker0 était suspendu. L'installation de bridge-utils et l'exécution des programmes suivants ont permis à mon Docker de fonctionner correctement:

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

— Thomas V.
source

1

vous n'avez pas besoin de rebulider vos images. resolv.conf est généré à chaque fois que vous exécutez un nouveau conteneur. il faut donc enlever l'ancien conteneur et en démarrer un autre. J'ai été emballé ce problème hier. De plus, si vous êtes sur l'intranet d'entreprise, vous pouvez passer --dns-search = votre-entreprise.domaine au démon docker dans / etc / default / docker dans la variable env DOCKER_OPTS à proximité des indicateurs --dns --dns.

— Alexander.Iljushkin

Cela a également corrigé mes problèmes liés au menu fixe.

— BobMcGee

3

Sous Linux, il me fallait ip link set down docker0au lieu de ifconfig docker0 downet systemctl restart dockerau lieu de service docker start. Pour effacer toutes les images, je l'ai faitdocker rmi $(docker images -q)

— maillé le

Cela a fonctionné la première fois pour moi. Ensuite, j'ai redémarré et le problème est réapparu: reproduire ces étapes n'a pas résolu le problème à nouveau. Je n'ai aucune idée de ce dont il s'agit.

— user626921

1

Je viens de voir que mon interface docker0 était en panne, j'ai exécuté /etc/init.d/docker restartet il est de retour aux affaires

— lolesque

14

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

La première chose à vérifier est exécutée cat /etc/resolv.confdans le conteneur de menu fixe . 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 et ping google.coméchouera.

La deuxième chose à vérifier est exécutée cat /etc/resolv.confsur la machine hôte . Docker copie fondamentalement l'hôte /etc/resolv.confdans le conteneur à chaque démarrage d'un conteneur. Donc, si l'hôte /etc/resolv.confest faux, le conteneur docker le sera également.

Si vous avez trouvé que l'hôte /etc/resolv.confest incorrect, vous avez 2 options:

Coder 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.
Fixez les hôtes /etc/resolv.conf. Ceci est un peu plus compliqué, mais il est généré dynamiquement et vous ne codez pas en dur le serveur DNS.

1. Serveur DNS hardcode dans le menu fixe daemon.json

Modifier /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 se remplira /etc/resolv.confavec les valeurs de daemon.json.

2. Réparez les hôtes /etc/resolv.conf

A. Ubuntu 16.04 et versions antérieures

Pour Ubuntu 16.04 et les versions antérieures, a /etc/resolv.confété généré dynamiquement par NetworkManager.
Commentez la ligne dns=dnsmasq(avec a #) dans /etc/NetworkManager/NetworkManager.conf
Redémarrez 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 plus tard

Ubuntu 18.04 a été modifié pour utiliser systemd-resolvedpour 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. Par conséquent, Docker utilise par défaut le serveur DNS 8.8.8.8 de Google, qui peut tomber en panne pour les utilisateurs derrière un pare-feu.
/etc/resolv.confest 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.
Il suffit de changer le lien symbolique vers /run/systemd/resolve/resolv.conflequel pointer , 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 devez maintenant avoir une /etc/resolv.confcopie valide sur l'hôte pour que docker puisse copier dans les conteneurs.

— sage
source

Merci pour cela, je perdais vraiment la raison en essayant de comprendre ce qui se passait avec les conteneurs Docker et la résolution 18.04 des IP sur un VPN. La fixation de /etc/resolv.conf pour 18.04 a fonctionné pour moi!

— George Papas

l'option B a fonctionné pour moi ..

— codeSetter

2B ne survivra sûrement pas à une mise à jour du systemdpaquet ...

— Auspex

13

Pour tenter d'ajouter de la valeur à un problème que j'ai aussi 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.

Mon hôte a /etc/resolv.confressemblé à 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 masque les détails du serveur DNS.

Malheureusement, conformément aux manuels de docker, docker filtrera toutes les adresses IP d’hôte local lors de la construction de resolv.conf du conteneur et les remplacera par les adresses IP DNS de Google. Ce qui dans mon cas a provoqué des noms de domaine interdits.

J'ai dû:

Réinitialiser ma /etc/default/dockervaleur par défaut pour que les conteneurs utilisent plutôt le contenu resolv.conf de mon hôte.
Editez /etc/NetworkManager/NetworManager.confet commentez la ligne dns=dnsmasq. C'est ainsi que 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 le faire apt-get update/upgrade, par exemple.

— David 'le gingembre chauve'
source

3

Cela a réellement fonctionné pour moi. Et j'étais derrière l'intranet de la société

— Daniel Andrei Mincă

1

Cette solution fonctionne très bien pour Ubuntu 16.04 et les versions antérieures. Pour Ubuntu 18.04 et les versions

— wisbucky le

Merci! Cela a fonctionné, contrairement à la réponse acceptée. :)

— Devolus

8

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. Probablement 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 / l’archive ubuntu est disponible sur IPv6 et IPv4. Vous n’avez pas eu la chance de choisir un IPv6, car votre système pense que cela devrait fonctionner.)

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

Là encore, il est important de comprendre que le DNS n’est pas à blâmer, comme vous pouvez le constater avec vos propres tests de ping.

1

Merci pour la réponse rapide et la clarification qu'il ne s'agit pas d'un problème de DNS, je l'apprécie. J'ai installé miredo - no go. Il est également intéressant de noter que lorsque j'exécute apt-get update -o Acquire :: ForceIPv4 = true, la mise à jour d'apt-get échoue toujours, j'ai mis à jour mon message d'origine avec cette réponse. J'ai essayé de désactiver UFW en pensant que c'était peut-être le cas et que je n'ai toujours pas eu de chance.

— Thomas V.

Bizarre - vous pouvez voir que vous avez une connectivité IPv4 parce que votre ping réussit. Mais vous ne pouvez pas vous connecter au miroir même si cela laisse à penser que vous rencontrez un problème de routage / réseau étrange (ce qui explique pourquoi vous postez ici!)

8

La documentation officielle de Docker donne aux instruments la possibilité de configurer un serveur DNS pour une utilisation par Docker

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

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

— tryer3000
source

Notez qu'il s'agit de l'ancien fichier de configuration pour Docker Upstart et SysVinit. La méthode actuelle pour systemd (depuis Ubuntu 16.04) consiste à utiliser /etc/docker/daemon.jsonpour les paramètres du démon docker tels que dns.

— Wisbucky

0

Pour les autres lecteurs qui viennent ici tout 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 dans boot2docker ne pouvaient pas résoudre les noms d'hôte.

Je viens donc de redémarrer boot2docker et de démarrer les conteneurs. Les noms d'hôte peuvent désormais être résolus correctement.

Je suppose que le problème était de démarrer boot2docker alors que le réseau sur l'hôte était en cours de connexion, ce qui a provoqué le démarrage de boot2docker et son entrée dans un état inactif.

— Œil
source

0

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

— avion rapide
source

0

Redémarrez le démon Docker sur Debian9

service docker restart

et les connexions et les réseaux fonctionnent bien

— Nolwennig
source

-1

Avait un problème similaire, mais aussi la résolution de noms entre les conteneurs à l'intérieur d'un réseau défini par l'utilisateur semblait être un peu floconneuse. Certains ne pouvaient rien résoudre comme toi.

Le problème était un / var / lib / docker déplacé. Pour des raisons d'espace, il a été monté via NFS. Ajouter un système de fichiers local et y déplacer les fichiers résout le problème.

— michi.0x5d
source

Si vous pensez pouvoir répondre à une question par une réponse à une question similaire, veuillez la marquer comme un doublon de cette question. Si vous ne pouvez pas faire cela, vous devriez laisser un commentaire plutôt que d'en faire une réponse séparée.

— Jenny D dit Réintégrer Monica