Vraag Docker-containers kunnen DNS niet oplossen op Ubuntu 14.04 Desktop Host


Ik heb een probleem met mijn Docker-containers op Ubuntu 14.04 LTS. Docker werkte prima gedurende twee dagen en plotseling verloor ik alle netwerkconnectiviteit in mijn containers. De foutoutput hieronder leidde me aanvankelijk te geloven dat apt-get probeert de DNS via IPv6 op te lossen.

Ik heb IPv6 op mijn hostmachine uitgeschakeld en nog steeds, alle afbeeldingen verwijderd, basis ubuntu getrokken en nog steeds tegen het probleem aangelopen.

Ik heb mijn /etc/resolve.conf-naamservers gewijzigd van mijn lokale DNS-server naar de openbare DNS-servers van Google (8.8.8.8 en 8.8.4.4) en heb nog steeds geen geluk. Ik heb ook de DNS ingesteld op Google in de DOCKER_OPTS van / etc / default / docker en docker opnieuw opgestart.

Ik heb ook geprobeerd om coreos te trekken, en yum kon DNS ook niet oplossen.

Het is raar, want terwijl DNS niet werkt, krijg ik nog steeds een antwoord als ik dezelfde updateservers pings die apt-get niet kan oplossen.

Ik sta niet achter een proxy, ik gebruik een zeer standaard lokaal netwerk en deze versie van Ubuntu is up-to-date en nieuw (ik heb twee dagen geleden geïnstalleerd om dichter bij docker te zijn).

Ik heb dit grondig onderzocht via andere berichten over stackoverflow- en github-problemen, maar heb geen enkele resolutie gevonden. Ik heb geen idee hoe dit probleem kan worden opgelost, kan iemand helpen?

Foutbericht

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

Container 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

Apt-get update mislukt ook als ik IPv4 forceer:

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  

43
2017-11-08 18:26


oorsprong




antwoorden:


Woo, ik vond een bericht op github dat mijn probleem oploste.

Nadat Steve K. erop wees dat het niet echt een DNS-probleem was en een connectiviteitsprobleem was, kon ik het vinden een bericht op github die beschreef hoe dit probleem op te lossen.

Blijkbaar is de docker0-netwerkbrug opgehangen. Door het installeren van bridge-utils en het uitvoeren van het volgende kreeg mijn Docker in werkende staat:

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

54
2017-11-08 19:09



u hoeft uw afbeeldingen niet opnieuw in te delen. resolv.conf wordt elke keer gegenereerd wanneer u een nieuwe container start. dus je moet de oude container verwijderen en een nieuwe starten. ik heb dit probleem gisteren aangehaald. Als u zich in het bedrijfsintranet bevindt, kunt u ook --dns-search = your.company.domain doorgeven aan de docker-daemon in / etc / default / docker in de env-variabele DOCKER_OPTS bij de --dns --dns-vlaggen. - Alexander.Iljushkin
Dit heeft ook mijn problemen met de dock hersteld. - BobMcGee
Op arch linux die ik nodig had ip link set down docker0 in plaats van ifconfig docker0 down en systemctl restart docker in plaats van service docker start. Om alle afbeeldingen te verwijderen, deed ik dat docker rmi $(docker images -q) - meshy
Dat werkte de eerste keer voor mij. Toen ben ik opnieuw opgestart en het probleem verscheen weer: het reproduceren van die stappen loste het probleem niet opnieuw op. Ik heb geen idee waar dit over gaat. - user626921
Ik zag net dat mijn docker0-interface niet werkte, ik werd uitgevoerd /etc/init.d/docker restart en het is terug naar het bedrijfsleven - lolesque


In een poging om extra waarde toe te voegen aan een probleem dat ik ook heb ervaren; met een alternatief antwoord:

Mijn netwerk was kantoorgerelateerd en de instellingen van Google DNS waren geblokkeerd, zodat de container IP-adressen kon pingen, maar geen domeinnamen.

Van mijn gastheer /etc/resolv.conf oorspronkelijk leek;

#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

Dit komt doordat Network Manager de DNS-serverdetails maskeert.

Helaas volgens de dokwerkhandleidingen docker filtert eventuele localhost IP-adressen uit bij het bouwen van het resolv.conf van de container en vervangt deze door de DNS IP's van Google. Wat in mijn geval veroorzaakte dat domeinnamen verboden zijn.

Ik moest:

  • Reset mijn /etc/default/docker standaard in, zodat containers de resolv.conf-inhoud van mijn host gebruiken.
  • Bewerk /etc/NetworkManager/NetworManager.conf en becommentarieer de lijn dns=dnsmasq. Dit is zodat NM de daadwerkelijke DNS IP-adressen kan opgeven in plaats van 127.0.0.1.
  • Start NM opnieuw met sudo service network-manager restart.
  • Start docker-service opnieuw met sudo service docker restart.

Het uitvoeren van een container zou het dan mogelijk maken apt-get update/upgrade, bijvoorbeeld.


10
2017-07-26 09:43



Dit werkte echt voor mij. En ik stond achter intranet van het bedrijf - Mincă Daniel Andrei
Deze oplossing werkt geweldig voor Ubuntu 16.04 en eerder. Zie voor Ubuntu 18.04 en hoger serverfault.com/a/918568 - wisbucky
Bedankt! Dit werkte, terwijl het geaccepteerde antwoord dat niet deed. :) - Devolus


Uw fout is hier:

 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]

Dit is geen fout bij DNS, in plaats daarvan probeert uw systeem verbinding te maken met IPv6-hosts en niet. Vermoedelijk omdat u geen IPv6-toegang op uw host heeft. De daadwerkelijke opzoeking van het IPv6-adres lukt. (De ubuntu-mirror / het archief is beschikbaar via zowel IPv6 als IPv4. Je had gewoon de pech om een ​​IPv6-versie te gebruiken omdat je systeem denkt dat het zou moeten werken.)

U zou dat moeten oplossen, door miredo installeren, of probeer het opnieuw totdat je een IPv4-mirror hebt geraakt.

Nogmaals, het belangrijkste om hier te realiseren is dat DNS niet de schuld is, zoals je kunt zien aan je eigen ping-tests.


7
2017-11-08 18:38



Bedankt voor het snelle antwoord en om te verduidelijken dat het eigenlijk geen DNS-probleem is, dat waardeer ik. Ik heb miredo geïnstalleerd - niet meer nodig. Het is ook vermeldenswaard dat wanneer ik apt-get update uitvoer -o Acquire :: ForceIPv4 = true apt-get update nog steeds mislukt, ik mijn oorspronkelijke bericht met dat antwoord heb bijgewerkt. Ik heb geprobeerd UFW uit te schakelen, denkend dat dat misschien het geval was, en ik heb nog steeds geen geluk gehad. - Thomas V.
Raar - je ziet dat je IPv4-connectiviteit hebt omdat je ping succesvol is. Maar u kunt geen verbinding maken met de mirror, ongeacht of u een probleem hebt met een vreemde routering / netwerkverbinding (wat ik denk dat dit de reden is waarom u hier berichten plaatst!) - Steve Kemp


Docker officieel doc geeft instrumenten om een ​​DNS-server te configureren voor gebruik door Docker

  1. Open de /etc/default/docker bestand om te bewerken:

    sudo nano /etc/default/docker
    
  2. Voeg een instelling toe voor Docker:

    DOCKER_OPTS="--dns 8.8.8.8"
    
  3. Vervangen 8.8.8.8 met een lokale DNS-server zoals 192.168.1.1. Jij kan specificeer ook meerdere DNS-servers. Gescheiden met spaties, voor voorbeeld:

    --dns 8.8.8.8 --dns 192.168.1.1
    

    Waarschuwing: als u dit doet op een laptop die verbinding maakt met verschillende netwerken, zorg er dan voor dat u een openbare DNS-server kiest.

    PS: nm-tool kan worden gebruikt om de DNS-server van de lokale host te controleren

  4. Sla het bestand op en sluit het.

  5. Start de Docker-daemon opnieuw.

    sudo restart docker
    

7
2018-05-27 05:48



Merk op dat dit het oude configuratiebestand voor Docker Upstart en SysVinit is. De huidige manier voor systemd (sinds Ubuntu 16.04) is om te gebruiken /etc/docker/daemon.json voor docker daemon-instellingen zoals dns. - wisbucky


Als het een DNS-resolverprobleem is, dan is hier de oplossing:

Het eerste wat je moet controleren, is verlopen cat /etc/resolv.conf in de docker container. Als het een ongeldige DNS-server heeft, zoals nameserver 127.0.x.x, dan kan de container de domeinnamen niet omzetten naar ip-adressen, dus ping google.com zal mislukken.

Het tweede ding dat je moet controleren, is lopen cat /etc/resolv.conf op de host machine. Docker kopieert in feite de host's /etc/resolv.conf naar de container telkens wanneer een container wordt gestart. Dus als de gastheer is /etc/resolv.conf is fout, dan gebeurt dat ook met de Docker-container.

Als je dat van de gastheer hebt gevonden /etc/resolv.conf is fout, dan heb je 2 opties:

  1. Maak de DNS-server vast in daemon.json. Dit is gemakkelijk, maar niet ideaal als u verwacht dat de DNS-server verandert.

  2. Los de hosts op /etc/resolv.conf. Dit is een beetje lastiger, maar het wordt dynamisch gegenereerd en u bent niet hardcoding de DNS-server.


1. DNS-server met harde code in docker daemon.json

  • Bewerk /etc/docker/daemon.json

    {
        "dns": ["10.1.2.3", "8.8.8.8"]
    }
    
  • Start de docker-daemon opnieuw om ervoor te zorgen dat die wijzigingen van kracht worden:
    sudo systemctl restart docker

  • Wanneer u nu een container start / start, wordt Docker gevuld /etc/resolv.conf met de waarden van daemon.json.


2. Maak de hosts vast /etc/resolv.conf

A. Ubuntu 16.04 en eerder

  • Voor Ubuntu 16.04 en eerder, /etc/resolv.conf werd dynamisch gegenereerd door NetworkManager.

  • Geef commentaar op de regel dns=dnsmasq (met een #) in /etc/NetworkManager/NetworkManager.conf

  • Start de NetworkManager opnieuw op om te regenereren /etc/resolv.conf :
    sudo systemctl restart network-manager

  • Verifiëren op de host: cat /etc/resolv.conf

B. Ubuntu 18.04 en later

  • Ubuntu 18.04 is gewijzigd om te gebruiken systemd-resolved genereren /etc/resolv.conf. Nu gebruikt het standaard een lokale DNS-cache 127.0.0.53. Dat zal niet werken in een container, dus zal Docker standaard de 8.8.8.8 DNS-server van Google gebruiken, die mogelijk kapot gaat voor mensen achter een firewall.

  • /etc/resolv.conf is eigenlijk een symlink (ls -l /etc/resolv.conf) die wijst naar /run/systemd/resolve/stub-resolv.conf (127.0.0.53) standaard in Ubuntu 18.04.

  • Wijzig gewoon de symboliek waarnaar verwezen wordt /run/systemd/resolve/resolv.conf, die de echte DNS-servers vermeldt:
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

  • Verifiëren op de host: cat /etc/resolv.conf

Nu zou je een geldige moeten hebben /etc/resolv.conf op de host voor docker om in de containers te kopiëren.


6
2018-06-27 23:06



Bedankt hiervoor, verloor echt mijn hoofd in een poging om te begrijpen wat er gebeurde met Docker-containers en 18.04 IP-adressen op een VPN. Fixing /etc/resolv.conf voor 18.04 werkte voor mij! - George Papas
optie B werkte voor mij .. - codeSetter


Voor andere lezers die hier komen tijdens het gebruik van boot2docker, heb ik dit probleem opgelost. In feite wees het bovenstaande antwoord me op de goede richting.

Om de een of andere reden konden containers in boot2docker hostnamen niet oplossen.

Dus heb ik net boot2docker opnieuw opgestart en de containers gestart. Nu kunnen hostnamen weer correct worden opgelost.

Ik veronderstel dat het probleem was boot2docker te starten terwijl het netwerk op de host werd aangesloten, waardoor boot2docker opstartte en een niet-werkende status begon.


0
2018-06-23 01:42





Ik had hetzelfde probleem op Windows. Deze opdracht heeft het voor mij laten werken: docker-machine restart


0
2017-08-11 22:16





Start de Docker-daemon opnieuw op Debian9

service docker restart 

en de verbindingen en netwerken werken prima


0
2018-06-07 15:30





Had een soortgelijk probleem, maar ook het oplossen van problemen tussen containers in een door de gebruiker gedefinieerd netwerk leek een beetje te schilferen. Sommigen konden niets zoals jou oplossen.

Het probleem was een verplaatst / var / lib / docker. Om ruimte-redenen werd het gemount via nfs. Door een lokaal bestandssysteem toe te voegen en de bestanden daar naartoe te verplaatsen, wordt het probleem opgelost.


-1
2017-08-10 10:54



Als u denkt dat een vraag kan worden beantwoord door een antwoord op een soortgelijke vraag, markeer deze dan als een duplicaat van die vraag. Als u dat niet kunt, moet u een opmerking achterlaten in plaats van het een apart antwoord te maken. - Jenny D


ik heb Docker version 1.12.6, build 78d1802 en het was genoeg om de docker voor mij opnieuw te starten (op Ubuntu 16.04).

$ sudo systemctl restart docker

-1
2017-09-21 16:52