contenant Ubuntu docker ne apt-get update

Question

J'ai donc une question assez étrange avec mon installation docker:

Si je lance

apt-get update 

intérieur par exemple un récipient debian (docker run -it --rm debian), il échoue toujours avec l'erreur comme

Err:1 http://security.ubuntu.com/ubuntu xenial-security InRelease 
Temporary failure resolving 'security.ubuntu.com' 

Maintenant, cela semble être un problème de DNS tel que discuté dans tant d'autres messages similaires, mais ici vient mon tour sur cette question: Lorsque je tente alors de ping l'hôte

ping security.ubuntu.com 

cela fonctionne parfaitement bien. Le domaine est résolu et les pings fonctionnent. par exemple.

$ docker run -it —rm debian 
root@0b6a6ec41a37:/# ping google.com 
PING google.com (172.217.19.174): 56 data bytes 
64 bytes from 172.217.19.174: icmp_seq=0 ttl=55 time=0.943 ms 

J'ai ensuite essayé un nslookup dans un récipient busybox (docker run -it --rm busybox) qui fonctionne aussi parfaitement bien.

J'ai commencé à étudier cela parce que je voulais configurer nextcloud avec docker et l'interface d'administration signale que le serveur ne pouvait pas vérifier une connexion Internet active, car il ne peut pas résoudre par exemple. github.com.

Le prochain bit étonnant vient quand je me connecte ensuite au conteneur nextcloud en cours d'exécution et fais mes tests sur la ligne de commande. ping fonctionne à nouveau bien et cette fois même apt-get update fonctionne ?!

J'ai effectué ces tests à la fois avec ufw activé et désactivé. Même résultat

Je suis maintenant assez confus quant à ce qui se passe. Quelque chose doit être faux, soit sur mon serveur ou mon réseau autour de lui mais je ne peux pas comprendre quel pourrait être le problème.

Si quelqu'un a déjà eu un tel problème, il serait bon d'entendre votre prise/solution. Merci :)

Environnement:
Hôte: Ubuntu LTS-16.04.03
Docker: 17.09.0-ce

Mon daemon.json:

{ 
    "graph": "/mnt/nfs/nas/docker", 
    "iptables": true, 
    "dns": ["10.0.16.1"], 
    "userland-proxy": true, 
    "ip": "127.0.0.1" 
} 

// Modifier 02-10- En ce qui concerne le resolv.conf et les paramètres DNS: Oui, j'ai essayé d'omettre le champ "dns" dans le daemon.json, puis il prend juste la valeur de l'hôte resolv.conf et j'ai également essayé d'utiliser "8.8.8.8" avec le même résultat. Mon hôte resolv.conf contient:

nameserver 10.0.16.1 

Answer 1

Je semble l'avoir corrigé mais je ne suis pas entièrement sûr quelle partie l'a corrigé. j'ai fait ce qui suit:

Après beaucoup d'essais et d'échec j'ai décidé de docker complètement purge et tous les dossiers connexes de mon système (j'ai aussi enlevé le pont restant et réinitialiser mon iptables), ne laissant que le daemon.json ne contenant que:

{ 
    "graph": "/mnt/nfs/nas/docker" 
} 

Puis j'ai réinstallé docker. Il n'a pas créé le dossier /var/lib/docker car j'ai spécifié un volume NFS comme racine du graphique. J'ai alors essayé à nouveau, mais cette fois, il ne pouvait même pas démarrer le conteneur! docker info m'a donné un "avertissement" que mon partage nfs ne supporte pas "d_type". J'ai ensuite arrêté docker, retiré mon daemon.json et redémarré. Cela a bien sûr créé le /var/lib/docker et maintenant je pouvais lancer le conteneur et tout a bien fonctionné.

Je suppose que ma purge du docker config et bridge l'a corrigé ou peut-être que mon précédent déplacement de la racine graphique vers mon volume nfs l'a cassé.

Donc tout se comporte comme il se doit mais j'aurais quand même aimé avoir mes volumes sur mon volume NAS monté. Je pourrais probablement passer à un pilote FS différent pour docker, peut-être alors il aurait travaillé depuis le début.