doker.io DNS nie działa, próbuje użyć 8.8.8.8


33

Mam nową instalację Ubuntu 14.04 i chcę używać Dockera do uruchamiania starych rzeczy, które wymagają wersji 12.04. DNS wewnątrz Dockera nie działa.

Plik resolv.conf mojego laptopa wygląda następująco:

nameserver 127.0.0.1

Co najwyraźniej nie działa z Dockerem. Dlatego próbuje ustawić serwery nazw na 8.8.8.8 i 8.8.4.4; kiedy robię

$ sudo docker run -i -t ubuntu /bin/bash

To mówi:

WARNING: Local (127.0.0.1) DNS resolver found in resolv.conf and containers can't use it. Using default external servers : [8.8.8.8 8.8.4.4]

I rzeczywiście, w instancji Docker resolv.conf wygląda następująco:

nameserver 8.8.8.8
nameserver 8.8.4.4

Mogę pingować oba z powodzeniem z poziomu instancji Docker. Jednak nie ma DNS (np. ping google.comKończy się niepowodzeniem).

Dane wyjściowe ifconfig wewnątrz Dockera:

eth0      Link encap:Ethernet  HWaddr aa:e9:9f:83:9d:92  
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::a8e9:9fff:fe83:9d92/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:648 (648.0 B)  TX bytes:738 (738.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:1500  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)

Co teraz?

Odpowiedzi:


23

Kiedy pakiet Ubuntu Docker został zaktualizowany do użycia systemd, porzucił obsługę /etc/default/dockerpliku konfiguracyjnego, więc wstępne rozwiązanie sugerowane przez rocketman10404 nie będzie już działać (wyłączenie dnsmasqnadal będzie działać, ale ma tę wadę, że uniemożliwia automatyczne aktualizowanie serwera DNS przez Ubuntu) .

Naprawianie w nowym daemon.jsonpliku konfiguracyjnym

Znajdź serwer DNS swojej sieci:

$ nmcli dev show | grep 'IP4.DNS'
IP4.DNS[1]:                             10.0.0.2

Otwórz lub utwórz, jeśli nie istnieje, /etc/docker/daemon.jsoni dodaj ustawienia DNS do ExecStartlinii:

# /etc/docker/daemon.json
{
    "dns": ["10.0.0.2", "8.8.8.8"]
}

Uruchom ponownie demona dokera:

$ sudo service docker restart

Napisałem szczegółowy post na blogu, a także zgłosiłem błąd dotyczący tego problemu, jeśli chcesz uzyskać więcej informacji.

(Pierwotnie rozwiązałem go, otwierając /lib/systemd/system/docker.service i dodając ustawienia DNS do wiersza ExecStart , ale to źle - nie powinniśmy bezpośrednio edytować plików systemowych .)


Dzięki za twoje rozwiązanie - było pomocne w drodze, którą podjąłem do mojego rozwiązania - które moim zdaniem jest nieco bardziej eleganckie dopasowanie do moich okoliczności i osobliwości uruchamiania Dockera na Ubuntu (lub innych dystrybucjach pulpitu, które używają NetworkManager + dnsmasq).
— Adrian

16

Sam nie używam Dockera, więc normalnie nie wchodziłbym tutaj w pytanie dotyczące Dockera, ale akurat czytałem o tym i natknąłem się na dokumentację Dockera, która wydaje się rozwiązać ten konkretny problem . Podsumowując ...

Dokumentacja sugeruje kilka obejść. Pierwszym jest określenie serwera DNS, który ma być używany przez demona dokera dla kontenerów, poprzez dodanie następującego wiersza do /etc/default/docker:

docker_OPTS="--dns 8.8.8.8"

gdzie podany DNS może być lokalnym serwerem DNS, takim jak 192.168.1.1 (brama). Następnie uruchom ponownie za pomocą

sudo restart docker

Alternatywne rozwiązanie polega na wyłączeniu dnsmasq w NetworkManager przez komentowanie konfiguracji w następujący /etc/NetworkManager/NetworkManager.confsposób:

#dns=dnsmasq

następnie uruchom ponownie oba

sudo restart network-manager
sudo restart docker

3
wyłączenie dnsmasq działało dla mnie.
— bennyl

2
To drugie podejście będzie oczywiście oznaczać, że menedżer sieci nie może kontrolować dnsmasq, co oznacza na przykład, że nie może zmienić serwera dns podczas zmiany sieci, w tym przejścia na VPN. To pierwsze podejście wydaje mi się lepsze, ale chciałbym mieć możliwość, aby dnsmasq również nasłuchiwał na IP dokującego (172.17.0.1), więc mogę wskazać na to hosty dokujące.
— mc0e

1
Ponieważ Ubuntu przeszło na konfigurację Dockera za pomocą sytemd, /etc/default/dockernie ma już żadnego efektu. Zobacz moje rozwiązanie, jak to rozwiązać w świecie post-init.d / upstart.
— Robin Winslow,

/etc/NetworkManager/NetworkManager.confnie istnieje na Ubuntu 18.04 LTS. : /
— XtraSimplicity

Zauważ, że w niektórych konfiguracjach Ubuntu 18.04 (np. Minimalny obraz na Amazon) systemd-resolveddomyślnie działa jako buforujący serwer DNS i spowoduje WARNING: Local (127.0.0.1) DNS resolver found in resolv.conf and containers can't use it.problem (konfiguracje Ubuntu 16.04 domyślnie nie włączają go). Obejściem tego problemu jest wyłączenie systemd-resolvedlub użycie --dnsopcji podczas uruchamiania kontenera, jak wspomniano w głównej odpowiedzi.
— Anon

9

Wpadłem na to w mojej konkretnej sytuacji

  • Uruchamianie kontenerów Docker na mojej lokalnej maszynie programistycznej
  • Który jest podłączony do VPN
  • Niektóre z naszych skryptów kompilacji kontenerów wykonują takie czynności, jak uruchamianie npm installz niestandardowego repozytorium w sieci VPN w kontenerze.
    • Działa to z potoku CI, ale nie z naszych maszyn deweloperskich, ponieważ npmnie można przeprowadzić pomyślnego wyszukiwania DNS
    • Mieliśmy również problemy z kontenerami, które muszą wyszukiwać, aby wywoływać zewnętrzne interfejsy API REST

Ubuntu domyślnie używa dnsmasquruchomionego przez NetworkManager do buforowania żądań DNS i konfiguruje, /etc/resolv.confaby wskazywać na to wystąpienie127.0.1.1

  • Klient VPN, którego używamy, nie jest zgodny z NetworkManager i wymusza jego własnego, /etc/resolv.confktóry zastępuje konfigurację NetworkManager
  • To konfiguruje serwery DNS dla VPN
  • Docker /etc/resolv.confdomyślnie ukrywa twój cień w kontenerze
    • Zwykle w systemie Ubuntu przekazuje serwery Google DNS do kontenera (ponieważ wie o dnsmasqsytuacji.
    • Ale z przyjemnością przekazuje konfigurację serwera VPN DNS do kontenera
    • Nie ma trasy z kontenera na docker0moście sieciowym do serwerów DNS przez tap0adapter VPN .
  • Ergo, wszystkie wyszukiwania DNS w kontenerze kończą się niepowodzeniem, ponieważ nie mogą dotrzeć do jedynych serwerów DNS, w które jest wyposażony
  • Ponadto niektóre sieci blokują żądania do serwerów Google DNS, ponieważ chcą mieć możliwość podglądania wszystkich wyszukiwań DNS

Rozwiązanie :

Bardziej eleganckie byłoby używanie NetworkManagera i jego dnsmasqinstancji w sposób, w jaki został zaprojektowany.

  1. Powiedz Dockerowi, aby używał twojej dnsmasqinstancji dla DNS

    • Dodaj lub edytuj plik, /etc/docker/daemon.jsonaby poinformować dokera o użyciu docker0adaptera mostu dla DNS

      {
        "dns": ["172.17.0.1"]
      }
      
  2. Skonfiguruj dnsmasqinstancję NM, aby nasłuchiwała również mostków Docker, ponieważ domyślnie nasłuchuje tylko 127.0.1.1 - utwórz plik/etc/NetworkManager/dnsmasq.d/docker-bridge.conf

    # Default Docker bridge
    interface=docker0
    # Other Docker bridges
    interface=br-*
    
  3. Nie podoba mi się niegrzeczne zachowanie tego klienta VPN i wolę używać DNS po stronie VPN do wyszukiwania VPN (jeśli masz uprzejmego klienta VPN, który używa poprawnie skonfigurowanego NetworkManagera, nie musisz tego robić )

    • Wyłącz funkcję DNS w kliencie VPN (przestaje nadpisywać resolv.confpo połączeniu, a teraz cały DNS przechodzi dnsmasqponownie)
    • Dodaj plik konfiguracyjny, aby dnsmasqodpowiednio kierować żądania DNS dla swojej domeny - dodaj plik `/etc/NetworkManager/dnsmasq.d/vpn-dns.conf

      server=/myprivatedomain.net/10.0.0.1  
      # or whatever your private DNS server is
      
    • Opcjonalnie dodaj domenę wyszukiwania dla swojej domeny, aby móc używać krótkich nazw

      • Właśnie dodałem naszą domenę lokalną do listy wyszukiwania w moim domyślnym połączeniu sieciowym
  4. Uruchom ponownie NetworkManager i Docker

    sudo service network-manager restart
    sudo service docker restart
    

W tym momencie kontenery Docker powinny być w stanie obejść się nslookupbez problemów, gdy jesteś w VPN, dla domen zarówno wewnątrz, jak i poza VPN.


1
Niewielką poprawką, która nie wymaga zakodowania na stałe adresu IP mostka dokera0, jest użycie interfejsu zamiast dyrektywy nasłuchiwania adresu: interfejs = doker0
— siwyd

Niesamowite wyjaśnienia i instrukcje. +1 zasłużony.
— ereOn

Pozdrawiam @simonwydooghe - Włączyłem twoją sugestię - możesz również używać symboli wieloznacznych w tym polu, więc dodałem wzór dla wszystkich nazw mostów używanych w sieciach innych niż domyślne (przynajmniej tak, jak w przypadku docker-compose).
— Adrian

1
Wygląda na to, że wartość dns w daemon.json musi być tablicą, w przeciwnym razie cannot unmarshal string into Go value of type []stringpojawia się błąd: po ponownym uruchomieniu usługi dokowania.
— Slaven Rezic

Aktualizacja dla Bionic: 18.04 już nie używa wewnętrznej instancji dnsmasq zarządzanej przez NetworkManager dla DNS i zamiast tego używa systemd-rozwiązany; co powoduje własne problemy, ponieważ nie można tego skonfigurować do nasłuchiwania mostka docker0. Uciekłem się do wyłączenia go, ponownej instalacji dnsmasq NetworkManagera i prawidłowej konfiguracji.
— Adrian

2

Oto jak skonfigurowałem dokera na moim serwerze Ubuntu 14.04 działającym bez głowy.

Korzystam z serwera Ubuntu 14.04 z zainstalowaną następującą wersją dokera.

#docker version
Client version: 0.9.1
Go version (client): go1.2.1
Git commit (client): 3600720
Server version: 0.9.1
Git commit (server): 3600720
Go version (server): go1.2.1

Plik /etc/init/docker.io.conf i skrypt zawiera następujący wiersz:

# modify these in /etc/default/$UPSTART_JOB (/etc/default/docker)
    DOCKER=/usr/bin/$UPSTART_JOB
    DOCKER_OPTS=

Powyższa odpowiedź pomogła mi znaleźć powyższy plik.

Odkomentowałem następujące elementy w /etc/default/docker.io i dodałem mój lokalny serwer DNS:

# Use DOCKER_OPTS to modify the daemon startup options.  
DOCKER_OPTS="--dns 192.168.X.X"

Uruchomiłem ponownie usługę z:

sudo service docker.io restart

Biegł docker run <image> /bin/bash

Brak komunikatów dns podczas uruchamiania kontenera.

Uruchomiłem nowy kontener, zainstalowałem dnsutils.

Ran dig, a komunikat serwera jest prawidłowym lokalnym serwerem DNS.


0

Miałem podobny problem, zgłosiłem go StackOverflow . Wygląda na to, że nie mogłem 8.8.8.8przesłać zapytania do serwera nazw określonego w domyślnej instalacji Docker w systemie Ubuntu; jednak mogę pingować. W takim przypadku skorzystaj z serwera DNS, do którego możesz faktycznie wysłać zapytanie. Przetestuj za pomocą

nslookup - dns.server.name

i uruchom kontener przez

docker run --dns=ip.addr.of.dns

Muszę jeszcze znaleźć sposób na https://askubuntu.com/q/607172/30266, aby uzyskać rozwiązanie automagiczne.


Moja odpowiedź może być dla ciebie wystarczająco automagiczna ...
— Adrian,

0

Możesz użyć lokalnego resolvera DNS hosta (np. dnsmasq) Z kontenerów Docker, jeśli są one w sieci zdefiniowanej przez użytkownika . W takim przypadku kontener /etc/resolv.confbędzie miał serwer nazw 127.0.0.11(zwany także wbudowanym serwerem DNS Dockera ), który może poprawnie przekazywać żądania DNS na adres zwrotny hosta.

$ cat /etc/resolv.conf
nameserver 127.0.0.1
$ docker run --rm alpine cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
$ docker network create demo
557079c79ddf6be7d6def935fa0c1c3c8290a0db4649c4679b84f6363e3dd9a0
$ docker run --rm --net demo alpine cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0    

Jeśli go użyjesz docker-compose, automatycznie skonfiguruje niestandardową sieć dla twoich kontenerów (w formacie pliku v2 + ). Należy jednak pamiętać, że chociaż docker-composedziała kontenery w sieci zdefiniowanej przez użytkownika, nadal buduje je w sieci domyślnej . Aby użyć sieci niestandardowej do kompilacji, możesz określić networkparametr w konfiguracji kompilacji (wymaga formatu pliku v3.4 + ).

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.