I contenitori Docker non sono in grado di risolvere DNS sull'host desktop Ubuntu 14.04


48

Sto riscontrando un problema con i miei contenitori Docker su Ubuntu 14.04 LTS. Docker ha funzionato bene per due giorni, poi all'improvviso ho perso tutta la connettività di rete all'interno dei miei contenitori. L'output dell'errore riportato di seguito inizialmente mi porta a credere che sia stato perché apt-get sta cercando di risolvere il DNS tramite IPv6.

Ho disabilitato IPv6 sul mio computer host e ancora, ho rimosso tutte le immagini, ho estratto Ubuntu di base e ho riscontrato ancora un problema.

Ho cambiato i miei nameserver /etc/resolve.conf dal mio server DNS locale ai server DNS pubblici di Google (8.8.8.8 e 8.8.4.4) e non ho ancora avuto fortuna. Ho anche impostato il DNS su Google nel DOCKER_OPTS di / etc / default / docker e docker riavviato.

Ho anche provato a estrarre coreos e yum non è riuscito a risolvere il DNS.

È strano perché mentre DNS non funziona, ricevo ancora una risposta quando eseguo il ping degli stessi server di aggiornamento che apt-get non è in grado di risolvere.

Non sono dietro un proxy, sono su una rete locale molto standard e questa versione di Ubuntu è aggiornata e aggiornata (ho installato due giorni fa per essere più vicino alla finestra mobile).

Ho studiato a fondo questo tramite altri post su stackoverflow e problemi di github, ma non ho trovato alcuna soluzione. Sono fuori di idee su come risolvere questo problema, qualcuno può aiutare?

Messaggio di errore

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

Contenitore 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

Inoltre, l'aggiornamento apt-get non riesce quando 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  

Per me, ha funzionato dopo un riavvio.
ssi-anik,

Risposte:


64

Woo, ho trovato un post su github che ha risolto il mio problema.

Dopo che Steve K. ha sottolineato che in realtà non era un problema DNS e un problema di connettività, sono stato in grado di trovare un post su github che descriveva come risolvere questo problema.

Apparentemente il bridge di rete docker0 è stato appeso. L'installazione di bridge-utils e l'esecuzione di quanto segue hanno portato il mio Docker in ordine:

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

1
non è necessario riutilizzare le tue immagini. resolv.conf viene generato ogni volta che si esegue un nuovo contenitore. quindi è necessario rimuovere il vecchio contenitore e avviarne un altro. mi è stato risolto questo problema ieri. inoltre, se ci si trova nella Intranet aziendale, è possibile passare --dns-search = your.company.domain al demone docker in / etc / default / docker nella variabile env DOCKER_OPTS vicino ai flag --dns --dns.
Alexander.Iljushkin, il

Ciò ha risolto anche i miei problemi con la finestra mobile.
BobMcGee

3
Su Arch Linux avevo bisogno ip link set down docker0invece di ifconfig docker0 downe systemctl restart dockerinvece di service docker start. Per eliminare tutte le immagini, l'ho fattodocker rmi $(docker images -q)
meshy

Quello ha funzionato la prima volta per me. Quindi ho riavviato e il problema è riapparso: la riproduzione di questi passaggi non ha risolto nuovamente il problema. Non ho idea di cosa si tratti.
user626921,

1
Ho appena visto che la mia interfaccia docker0 era inattiva, l'ho eseguita /etc/init.d/docker restarted è tornata al lavoro
Lolesque,

14

Se si tratta di un problema del resolver DNS, ecco la soluzione:

La prima cosa da controllare viene eseguita cat /etc/resolv.confnel contenitore della finestra mobile . Se ha un server DNS non valido, ad esempio nameserver 127.0.x.x, il contenitore non sarà in grado di risolvere i nomi di dominio in indirizzi IP, quindi ping google.comfallirà.

La seconda cosa da verificare viene eseguita cat /etc/resolv.confsul computer host . Docker fondamentalmente copia l'host /etc/resolv.confnel contenitore ogni volta che viene avviato un contenitore. Quindi, se l'host /etc/resolv.confè sbagliato, lo sarà anche il contenitore della finestra mobile.

Se hai scoperto che l'host /etc/resolv.confè sbagliato, hai 2 opzioni:

  1. Hardcode del server DNS in daemon.json. Questo è facile, ma non ideale se si prevede che il server DNS cambi.

  2. Correggi gli host /etc/resolv.conf. Questo è un po 'più complicato, ma viene generato in modo dinamico e non stai codificando il server DNS.


1. Server DNS hardcode in docker daemon.json

  • modificare /etc/docker/daemon.json

    {
        "dns": ["10.1.2.3", "8.8.8.8"]
    }
    
  • Riavvia il daemon docker per rendere effettive le modifiche:
    sudo systemctl restart docker

  • Ora quando si esegue / avvia un contenitore, la finestra mobile verrà popolata /etc/resolv.confcon i valori da daemon.json.


2. Correggi gli host /etc/resolv.conf

A. Ubuntu 16.04 e precedenti

  • Per Ubuntu 16.04 e precedenti, è /etc/resolv.confstato generato dinamicamente da NetworkManager.

  • Commenta la riga dns=dnsmasq(con a #) in /etc/NetworkManager/NetworkManager.conf

  • Riavvia NetworkManager per rigenerare /etc/resolv.conf:
    sudo systemctl restart network-manager

  • Verifica sull'host: cat /etc/resolv.conf

B. Ubuntu 18.04 e versioni successive

  • Ubuntu 18.04 è stato modificato per utilizzare systemd-resolvedper generare/etc/resolv.conf . Ora, per impostazione predefinita, utilizza una cache DNS locale 127.0.0.53. Ciò non funzionerà all'interno di un container, quindi Docker passerà automaticamente al server DNS 8.8.8.8 di Google, che potrebbe rompersi per le persone dietro un firewall.

  • /etc/resolv.confè in realtà un symlink ( ls -l /etc/resolv.conf) che punta a /run/systemd/resolve/stub-resolv.conf(127.0.0.53) per impostazione predefinita in Ubuntu 18.04.

  • Basta cambiare il collegamento simbolico a cui puntare /run/systemd/resolve/resolv.conf, che elenca i server DNS reali:
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

  • Verifica sull'host: cat /etc/resolv.conf

Ora dovresti avere un valido /etc/resolv.confsull'host per la finestra mobile da copiare nei contenitori.


Grazie a questo, stavo davvero perdendo la mia mente cercando di capire cosa stesse succedendo con i contenitori docker e la risoluzione 18.04 degli IP su una VPN. Riparare /etc/resolv.conf per 18.04 ha funzionato per me!
George Papas,

l'opzione B ha funzionato per me ..
codeSetter

Sicuramente 2B non sopravviverà ad un aggiornamento del systemdpacchetto ...
Auspex,

13

Nel tentativo di aggiungere ulteriore valore a un problema ho anche riscontrato; con una risposta alternativa:

La mia rete era collegata all'ufficio e le impostazioni DNS di Google erano bloccate in modo che il contenitore potesse eseguire il ping degli indirizzi IP ma non dei nomi di dominio.

/etc/resolv.confOriginariamente il mio ospite sembrava;

#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

Ciò è dovuto al fatto che Network Manager esegue una sorta di mascheramento dei dettagli del server DNS.

Sfortunatamente, secondo i manuali della finestra mobile, la finestra mobile filtrerà tutti gli indirizzi IP localhost durante la creazione del file resolv.conf del contenitore e li sostituirà con gli IP DNS di Google. Che nel mio caso ha causato l'off-limits dei nomi di dominio.

Dovevo:

  • Ripristina my /etc/default/dockerin modo predefinito in modo che i contenitori utilizzino invece il contenuto resolv.conf del mio host.
  • Modifica /etc/NetworkManager/NetworManager.confe commenta la riga dns=dnsmasq. In questo modo NM può specificare gli indirizzi IP DNS effettivi anziché 127.0.0.1.
  • Riavviare NM con sudo service network-manager restart.
  • Riavviare il servizio docker con sudo service docker restart.

L'esecuzione di un contenitore consentirebbe quindi di farlo apt-get update/upgrade, ad esempio.


3
Questo ha funzionato davvero per me. Ed ero dietro la intranet aziendale
Daniel Andrei Mincă,

1
Questa soluzione funziona benissimo per Ubuntu 16.04 e precedenti. Per Ubuntu 18.04 e
versioni

Grazie! Questo ha funzionato, mentre la risposta accettata no. :)
Devolus,

8

Il tuo errore è qui:

 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]

Questo non è un errore con DNS, ma il tuo sistema sta tentando di connettersi agli host IPv6 e non riesce. Presumibilmente perché non hai accesso IPv6 sul tuo host. La ricerca effettiva dell'indirizzo IPv6 ha esito positivo. (Il mirror / archivio ubuntu è disponibile sia su IPv6 che su IPv4. Sei stato abbastanza sfortunato da raggiungerne uno IPv6 perché il tuo sistema crede che dovrebbe funzionare.)

Dovresti risolvere il problema installando miredo o riprovare fino a quando non colpisci un mirror IPv4.

Ancora una volta la cosa importante da capire qui è che non è colpa del DNS, come puoi vedere dai tuoi test ping.


1
Grazie per la risposta rapida e per aver chiarito che in realtà non è un problema DNS, lo apprezzo. Ho installato miredo - no go. Vale anche la pena notare che quando eseguo apt-get update -o Acquire :: ForceIPv4 = vero aggiornamento apt-get ancora non riesce, ho aggiornato il mio post originale con quella risposta. Ho provato a disabilitare l'UFW pensando che forse era così, e ancora non ho avuto fortuna.
Thomas V.

Strano: puoi vedere che hai la connettività IPv4 perché il tuo ping ha successo. Ma non puoi connetterti al mirror indipendentemente dal fatto che tu abbia qualche strano problema di routing / rete (che immagino sia il motivo per cui stai postando qui!)

8

Il documento ufficiale Docker fornisce strumenti per configurare un server DNS per l'utilizzo da parte di Docker

  1. Apri il /etc/default/dockerfile per la modifica:

    sudo nano /etc/default/docker
    
  2. Aggiungi un'impostazione per Docker:

    DOCKER_OPTS="--dns 8.8.8.8"
    
  3. Sostituisci 8.8.8.8con un server DNS locale come 192.168.1.1. È inoltre possibile specificare più server DNS. Separati con spazi, ad esempio:

    --dns 8.8.8.8 --dns 192.168.1.1
    

    Avviso: se lo stai facendo su un laptop che si collega a varie reti, assicurati di scegliere un server DNS pubblico.

    PS: nm-toolpuò essere utilizzato per controllare il server DNS host locale

  4. Salva e chiudi il file.

  5. Riavvia il demone Docker.

    sudo service docker restart
    

Si noti che questo è il vecchio file di configurazione per Docker Upstart e SysVinit. Il modo corrente per systemd (da Ubuntu 16.04) è quello di utilizzare le /etc/docker/daemon.jsonimpostazioni del demone docker come dns.
Wisbucky,

0

Per altri lettori che vengono qui durante l'utilizzo di boot2docker, ecco come ho risolto. In effetti, la risposta sopra mi ha indicato la giusta direzione.

Fondamentalmente, per qualche motivo i contenitori all'interno di boot2docker non sono stati in grado di risolvere i nomi host.

Quindi ho appena riavviato boot2docker e avviato i contenitori. Ora i nomi host possono risolversi correttamente.

Suppongo che il problema sia stato l'avvio di boot2docker mentre la rete sull'host era connessa, il che ha causato l'avvio di boot2docker ed entrare in uno stato non funzionante.


0

Ho avuto lo stesso problema su Windows. Questo comando ha funzionato per me:docker-machine restart


0

Riavvia il demone Docker su Debian9

service docker restart

e le connessioni e le reti funzionano bene


-1

Aveva un problema simile, ma anche la risoluzione dei nomi tra contenitori all'interno di una rete definita dall'utente sembrava un po 'instabile. Alcuni non sono stati in grado di risolvere nulla come te.

Il problema è stato spostato / var / lib / docker. Per ragioni di spazio è stato montato tramite nfs. L'aggiunta di un filesystem locale e lo spostamento dei file lì risolve il problema.


Se ritieni che una risposta a una domanda simile possa rispondere a una domanda, contrassegnala come duplicata di tale domanda. Se non riesci a farlo, dovresti lasciare un commento piuttosto che renderlo una risposta separata.
Jenny D dice Reinstate Monica il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.