Kontenery Docker nie mogą rozpoznać DNS na Ubuntu 14.04 Desktop Host


48

Mam problem z moimi kontenerami Docker na Ubuntu 14.04 LTS. Docker działał dobrze przez dwa dni, a potem nagle straciłem łączność sieciową w moich kontenerach. Poniższy wynik błędu początkowo prowadzi mnie do wniosku, że tak było, ponieważ apt-get próbuje rozwiązać DNS przez IPv6.

Wyłączyłem IPv6 na moim hoście i nadal usunąłem wszystkie obrazy, wyciągnąłem podstawowe Ubuntu i nadal napotkałem problem.

Zmieniłem moje serwery nazw /etc/resolve.conf z mojego lokalnego serwera DNS na publiczne serwery DNS Google (8.8.8.8 i 8.8.4.4) i nadal nie mam szczęścia. Ustawiłem także DNS na Google w DOCKER_OPTS / etc / default / docker i zrestartowałem dokera.

Próbowałem także wyciągnąć Coreos, a yum nie mógł również rozwiązać DNS.

To dziwne, ponieważ chociaż DNS nie działa, nadal otrzymuję odpowiedź, gdy pinguję te same serwery aktualizacji, których apt-get nie może rozwiązać.

Nie jestem za serwerem proxy, jestem w bardzo standardowej sieci lokalnej, a ta wersja Ubuntu jest aktualna i świeża (zainstalowałem dwa dni temu, aby być bliżej dokera).

Dokładnie przestudiowałem to w innych postach dotyczących problemów z przepełnieniem stosu i github, ale nie znalazłem rozwiązania. Nie mam pomysłów, jak rozwiązać ten problem, czy ktoś może pomóc?

Komunikat o błędzie

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

Kontener 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

Ponadto aktualizacja apt-get kończy się niepowodzeniem, gdy wymuszam 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  

Dla mnie zadziałało po ponownym uruchomieniu.
ssi-anik

Odpowiedzi:


63

Woo, znalazłem post na githubie, który rozwiązał mój problem.

Po tym, jak Steve K. wskazał, że tak naprawdę nie był to problem DNS i był to problem z łącznością, mogłem znaleźć post na github, który opisał, jak rozwiązać ten problem.

Najwyraźniej most sieciowy docker0 został rozłączony. Zainstalowanie narzędzi mostowych i uruchomienie następujących sprawiło, że mój doker działał:

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

1
nie musisz zmieniać swoich zdjęć. resolv.conf jest generowany przy każdym uruchomieniu nowego kontenera. więc musisz usunąć stary pojemnik i uruchomić inny. Wczoraj miałem problem z tym problemem. Ponadto, jeśli jesteś w firmowym intranecie, możesz przekazać --dns-search = twoja.firma.domain do demona dokera w / etc / default / docker w zmiennej DOCKER_OPTS env obok flag --dns --dns.
Alexander.Iljushkin

To rozwiązało również problemy z dokerem.
BobMcGee,

3
Na arch. Linuxie potrzebowałem ip link set down docker0zamiast ifconfig docker0 downi systemctl restart dockerzamiast service docker start. Aby usunąć wszystkie obrazy, zrobiłemdocker rmi $(docker images -q)
meshy

To zadziałało dla mnie po raz pierwszy. Następnie uruchomiłem się ponownie i problem pojawił się ponownie: odtworzenie tych kroków nie rozwiązało problemu ponownie. Nie mam pojęcia o co chodzi.
user626921,

1
Właśnie zobaczyłem, że mój interfejs docker0 jest wyłączony, wykonałem /etc/init.d/docker restartgo i wróciłem do biznesu
lolesque,

14

Jeśli jest to problem z usługą rozpoznawania nazw DNS, oto rozwiązanie:

Pierwszą rzeczą do sprawdzenia jest uruchomienie cat /etc/resolv.confw kontenerze dokera . Jeśli ma nieprawidłowy serwer DNS, na przykład nameserver 127.0.x.x, kontener nie będzie mógł rozpoznać nazw domen na adresy IP, więc ping google.comsię nie powiedzie.

Drugą rzeczą do sprawdzenia jest uruchomienie cat /etc/resolv.confna komputerze hosta . Docker w zasadzie kopiuje hosta /etc/resolv.confdo kontenera przy każdym uruchomieniu kontenera. Jeśli więc host nie /etc/resolv.confma racji, kontener dokera również.

Jeśli stwierdzisz, że host nie /etc/resolv.confjest prawidłowy, masz 2 opcje:

  1. Zakoduj serwer DNS w daemon.json. Jest to łatwe, ale nie idealne, jeśli spodziewasz się zmiany serwera DNS.

  2. Napraw hosty /etc/resolv.conf. Jest to trochę trudniejsze, ale jest generowane dynamicznie i nie kodujesz na stałe serwera DNS.


1. Serwer DNS z kodem stałym w oknie dokowanym daemon.json

  • Edytować /etc/docker/daemon.json

    {
        "dns": ["10.1.2.3", "8.8.8.8"]
    }
    
  • Zrestartuj demona dokera, aby zmiany odniosły skutek:
    sudo systemctl restart docker

  • Teraz, gdy uruchomisz / uruchomisz kontener, /etc/resolv.confokno dokowane zapełni się wartościami z daemon.json.


2. Napraw hosty /etc/resolv.conf

A. Ubuntu 16.04 i wcześniejsze

  • Dla systemu Ubuntu 16.04 i wcześniejszych /etc/resolv.confzostał dynamicznie wygenerowany przez NetworkManager.

  • Skomentuj wiersz dns=dnsmasq(za #) w /etc/NetworkManager/NetworkManager.conf

  • Uruchom ponownie NetworkManager, aby zregenerować /etc/resolv.conf:
    sudo systemctl restart network-manager

  • Sprawdź na hoście: cat /etc/resolv.conf

B. Ubuntu 18.04 i nowsze

  • Ubuntu 18.04 zmieniono systemd-resolvedna generowanie/etc/resolv.conf . Teraz domyślnie używa lokalnej pamięci podręcznej DNS 127.0.0.53. To nie będzie działać w kontenerze, więc Docker przejdzie do serwera DNS Google 8.8.8.8, co może się zepsuć dla osób za zaporą ogniową.

  • /etc/resolv.confjest w rzeczywistości symlink ( ls -l /etc/resolv.conf), który /run/systemd/resolve/stub-resolv.confdomyślnie wskazuje na (127.0.0.53) w Ubuntu 18.04.

  • Po prostu zmień dowiązanie symboliczne na wskazujące /run/systemd/resolve/resolv.conf, które zawiera listę prawdziwych serwerów DNS:
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

  • Sprawdź na hoście: cat /etc/resolv.conf

Teraz powinieneś mieć poprawne /etc/resolv.confna hoście, aby doker mógł skopiować do kontenerów.


Dzięki za to, naprawdę traciłem rozum, próbując zrozumieć, co się dzieje z kontenerami dokerów i 18.04 rozwiązywaniem adresów IP w sieci VPN. Naprawienie /etc/resolv.conf dla 18.04 działało dla mnie!
George Papas,

opcja B działała dla mnie ..
codeSetter

Na pewno 2B nie przetrwa aktualizacji systemdpakietu ...
Auspex

13

Próbując dodać dodatkową wartość do problemu, którego również doświadczyłem; z alternatywną odpowiedzią:

Moja sieć była związana z biurem, a ustawienia Google DNS zostały zablokowane, aby kontener mógł pingować adresy IP, ale nie nazwy domen.

Mój gospodarz /etc/resolv.confpoczątkowo wyglądał;

#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

Wynika to z tego, że Menedżer sieci dokonuje pewnego rodzaju maskowania szczegółów serwera DNS.

Niestety, zgodnie z podręcznikami dokera doker odfiltruje adresy IP lokalnego hosta podczas budowania resolv.conf kontenera i zastąpi je adresami IP DNS Google. Co w moim przypadku spowodowało, że nazwy domen były niedostępne.

Musiałem:

  • Zresetuj mój /etc/default/dockerdo domyślnych, aby zamiast tego pojemniki korzystały z zawartości resolv.conf mojego hosta.
  • Edytuj /etc/NetworkManager/NetworManager.confi komentuj linię dns=dnsmasq. Dzieje się tak, dlatego NM może podać rzeczywiste adresy IP DNS zamiast 127.0.0.1.
  • Uruchom ponownie NM za pomocą sudo service network-manager restart.
  • Uruchom ponownie usługę dokowania za pomocą sudo service docker restart.

Uruchomienie kontenera pozwoliłoby na to apt-get update/upgradena przykład.


3
To faktycznie działało dla mnie. I byłem za firmowym intranetem
Daniel Andrei Mincă

1
To rozwiązanie działa świetnie na Ubuntu 16.04 i wcześniejszych. W przypadku Ubuntu 18.04 i nowszych, patrz serverfault.com/a/918568
wisbucky

Dzięki! To zadziałało, a zaakceptowana odpowiedź nie. :)
Devolus

8

Twój błąd jest tutaj:

 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]

To nie jest błąd z DNS, zamiast tego twój system próbuje połączyć się z hostami IPv6 i kończy się niepowodzeniem. Prawdopodobnie dlatego, że nie masz dostępu do IPv6 na swoim hoście. Rzeczywiste wyszukiwanie adresu IPv6 kończy się powodzeniem. (Kopia lustrzana / archiwum ubuntu jest dostępna zarówno na IPv6, jak i IPv4. Po prostu nie udało ci się trafić na IPv6, ponieważ twój system uważa, że ​​powinien działać.)

Powinieneś to naprawić, instalując miredo , lub spróbuj ponownie, aż trafisz w lustro IPv4.

Ponownie ważne jest, aby zdać sobie sprawę z tego, że DNS nie jest winny, jak widać z własnych testów ping.


1
Dziękuję za szybką odpowiedź i wyjaśnienie, że tak naprawdę nie jest to problem DNS, doceniam to. Zainstalowałem miredo - nie idź. Warto również zauważyć, że kiedy uruchamiam apt-get update -o Acquire :: ForceIPv4 = true aktualizacja apt-get nadal kończy się niepowodzeniem, zaktualizowałem swój pierwotny post z tą odpowiedzią. Próbowałem wyłączyć UFW, myśląc, że może tak było i nadal nie miałem szczęścia.
Thomas V.

Dziwne - widać, że masz połączenie IPv4, ponieważ ping się powiódł. Ale nie możesz połączyć się z

8

Oficjalny dokument Docker udostępnia instrumenty do skonfigurowania serwera DNS do użytku przez Docker

  1. Otwórz /etc/default/dockerplik do edycji:

    sudo nano /etc/default/docker
    
  2. Dodaj ustawienie Dockera:

    DOCKER_OPTS="--dns 8.8.8.8"
    
  3. Zamień 8.8.8.8na lokalny serwer DNS, taki jak 192.168.1.1. Możesz także określić wiele serwerów DNS. Rozdziel je spacjami, na przykład:

    --dns 8.8.8.8 --dns 192.168.1.1
    

    Ostrzeżenie: jeśli robisz to na laptopie, który łączy się z różnymi sieciami, wybierz publiczny serwer DNS.

    PS: nm-toolmożna użyć do sprawdzenia lokalnego serwera DNS hosta

  4. Zapisz i zamknij plik.

  5. Uruchom ponownie demona Docker.

    sudo service docker restart
    

Zauważ, że jest to stary plik konfiguracyjny dla Docker Upstart i SysVinit. Obecnym sposobem dla systemd (od Ubuntu 16.04) jest użycie /etc/docker/daemon.jsonustawień demona dokera, takich jak dns.
wisbucky

0

Dla innych czytelników, którzy przychodzą tutaj podczas korzystania z boot2docker, oto jak to naprawiłem. W rzeczywistości powyższa odpowiedź wskazała mi właściwy kierunek.

Zasadniczo z jakiegoś powodu kontenery w boot2docker nie mogły rozpoznać nazw hostów.

Właśnie zrestartowałem boot2docker i uruchomiłem kontenery. Teraz nazwy hostów mogą poprawnie rozwiązać ponownie.

Przypuszczam, że problem polegał na uruchomieniu boot2docker podczas podłączania sieci na hoście, co spowodowało uruchomienie boot2docker i przejście w stan niedziałający.


0

Miałem ten sam problem w systemie Windows. To polecenie sprawiło, że działało dla mnie:docker-machine restart


0

Zrestartuj demona Docker na Debian9

service docker restart

a połączenia i sieci działają dobrze


-1

Miał podobny problem, ale również rozwiązywanie nazw między kontenerami w sieci zdefiniowanej przez użytkownika wydawało się nieco niestabilne. Niektórzy nie mogli rozwiązać czegoś takiego jak ty.

Problem polegał na przeniesieniu / var / lib / docker. Ze względu na miejsce został zamontowany przez NFS. Dodanie lokalnego systemu plików i przeniesienie tam plików rozwiązuje problem.


Jeśli uważasz, że na pytanie można odpowiedzieć w odpowiedzi na podobne pytanie, oznacz je jako duplikat tego pytania. Jeśli nie możesz tego zrobić, powinieneś zostawić komentarz zamiast uczynić z niego osobną odpowiedź.
Jenny D mówi Przywróć Monikę
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.