Контейнеры Docker не могут разрешить DNS на хосте рабочего стола Ubuntu 14.04

docker
1

Я столкнулся с проблемой с моими контейнерами Docker в Ubuntu 14.04 LTS.Докер работал нормально в течение двух дней, а затем внезапно я потерял все сетевые подключения внутри своих контейнеров. Приведенный ниже вывод об ошибке изначально заставил меня поверить, что это связано с тем, что apt-get пытается разрешить DNS через IPv6.

Я отключил IPv6 на своем хост-компьютере и все равно удалил все изображения, вытащил базовую ubuntu и все равно столкнулся с проблемой.

Я изменил свои серверы имен /etc/resolve.conf с моего локального DNS-сервера на общедоступные DNS-серверы Google (8.8.8.8 и 8.8.4.4), и мне все еще не повезло. Я также установил DNS на Google в DOCKER_OPTS /etc/default/docker и перезапустил docker.

Я также попытался вытащить coreos, и yum тоже не смог разрешить DNS.

Это странно, потому что, хотя DNS не работает, я все равно получаю ответ, когда я проверяю те же серверы обновлений, которые apt-get не может разрешить.

Я не пользуюсь прокси-сервером, я нахожусь в очень стандартной локальной сети, и эта версия Ubuntu является актуальной и свежей (я установил два дня назад, чтобы быть ближе к docker).

Я тщательно исследовал это в других сообщениях о проблемах stackoverflow и github, но не нашел никакого решения. У меня нет идей относительно того, как решить эту проблему, кто-нибудь может помочь?

сообщение об ошибке

➜  arthouse git:(docker) ✗ docker build --no-cache .Sending build context to Docker daemon 51.03 MBSending build context to Docker daemon Step 0 : FROM ubuntu:14.04 ---> 5506de2b643bStep 1 : RUN apt-get update ---> Running in 845ae6abd1e0Err http://archive.ubuntu.com trusty InReleaseErr http://archive.ubuntu.com trusty-updates InReleaseErr 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.

Контейнер IFCONFIG/PING

➜  code  docker run -it ubuntu /bin/bashroot@7bc182bf87bb:/# ifconfigeth0      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.comPING 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 0msrtt min/avg/max/mdev = 12.367/12.367/12.367/0.000 msroot@7bc182bf87bb:/# ping 8.8.8.8PING 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 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=44 time=21.7 ms64 bytes from 8.8.8.8: icmp_seq=3 ttl=44 time=21.7 ms

Кроме того, обновление apt-get завершается ошибкой, когда я принудительно подключаю IPv4:

root@6d925cdf84ad:/# sudo apt-get update -o Acquire::ForceIPv4=trueErr http://archive.ubuntu.com trusty InReleaseErr http://archive.ubuntu.com trusty-updates InReleaseErr http://archive.ubuntu.com trusty-security InReleaseErr http://archive.ubuntu.com trusty-proposed InReleaseErr 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... DoneW: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/InRelease
2

Ууу, я нашел сообщение на github, которое решило мою проблему.

После того, как Стив К. указал, что на самом деле это была не проблема с DNS, а проблема с подключением, я смог найти сообщение на github в нем описано, как устранить эту проблему.

По-видимому, сетевой мост docker0 был отключен. Установка bridge-utils и выполнение следующего привели мой докер в рабочее состояние:

apt-get install bridge-utilspkill dockeriptables -t nat -Fifconfig docker0 downbrctl delbr docker0service docker restart
3

Если это проблема с распознавателем DNS, вот решение:

Первое, что нужно проверить, это запустить cat /etc/resolv.conf в контейнер docker. Если у него неверный DNS-сервер, например nameserver 127.0.x.x, то контейнер не сможет преобразовать доменные имена в ip-адреса, поэтому ping google.com потерпит неудачу.

Второе, что нужно проверить, это запустить cat /etc/resolv.conf на хост-машина. Docker в основном копирует хост- /etc/resolv.conf к контейнеру при каждом запуске контейнера. Так что, если хозяин /etc/resolv.conf если это неправильно, то так же будет и с контейнером docker.

Если вы обнаружили, что хост- /etc/resolv.conf это неправильно, тогда у вас есть 2 варианта:

  1. Жестко закодируйте DNS-сервер в файле daemon.json. Это легко, но не идеально, если вы ожидаете, что DNS-сервер изменится.

  2. Исправьте ошибки хостов /etc/resolv.conf. Это немного сложнее, но оно генерируется динамически, и вы не жестко кодируете DNS-сервер.

1. Жестко закодируйте DNS-сервер в docker daemon.json

  • Редактировать /etc/docker/daemon.json

    {    "dns": ["10.1.2.3", "8.8.8.8"]}

  • Перезапустите демон docker, чтобы эти изменения вступили в силу:
    sudo systemctl restart docker

  • Теперь, когда вы запускаете / запускаете контейнер, docker заполнит /etc/resolv.conf со значениями из daemon.json.

2. Исправьте ошибки хостов /etc/resolv.conf

A. Ubuntu 16.04 и более ранние версии

  • Для Ubuntu 16.04 и более ранних версий, /etc/resolv.conf был динамически сгенерирован NetworkManager.

  • Закомментируйте строку dns=dnsmasq (с помощью #) в /etc/NetworkManager/NetworkManager.conf

  • Перезапустите NetworkManager для восстановления /etc/resolv.conf :
    sudo systemctl restart network-manager

  • Проверка на хосте: cat /etc/resolv.conf

B. Ubuntu 18.04 и более поздние версии

  • Ubuntu 18.04 изменен на использование systemd-resolved для создания /etc/resolv.conf. Теперь по умолчанию он использует локальный DNS-кэш 127.0.0.53. Это не будет работать внутри контейнера, поэтому Docker по умолчанию будет использовать DNS-сервер Google 8.8.8.8, который может сломаться для людей, находящихся за брандмауэром.

  • /etc/resolv.conf на самом деле это символическая ссылка (ls -l /etc/resolv.conf) , который указывает на /run/systemd/resolve/stub-resolv.conf (127.0.0.53) по умолчанию в Ubuntu 18.04.

  • Просто измените символическую ссылку, чтобы она указывала на /run/systemd/resolve/resolv.conf, в котором перечислены реальные DNS - серверы:
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

  • Проверка на хосте: cat /etc/resolv.conf

Теперь у вас должен быть действительный /etc/resolv.conf на хосте для docker для копирования в контейнеры.

4

В попытке добавить дополнительную ценность к проблеме, с которой я также столкнулся; с альтернативным ответом:

Моя сеть была связана с офисом, и настройки DNS Google были заблокированы, чтобы контейнер мог проверять IP-адреса, но не доменные имена.

Моего хозяина /etc/resolv.conf первоначально выглядело как;

#Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)#DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTENnameserver 127.0.1.1search companyDomain.co.za

Это связано с тем, что сетевой менеджер выполняет какую-то маскировку сведений о DNS-сервере.

К сожалению, согласно руководства по docker docker отфильтрует любые IP-адреса localhost при создании resolv.conf контейнера и заменит их DNS-IP-адресами Google. Что в моем случае привело к тому, что доменные имена были недоступны.

Я должен был:

  • Сбросить мой /etc/default/docker по умолчанию контейнеры so вместо этого используют содержимое resolv.conf моего хоста.
  • Редактировать /etc/NetworkManager/NetworManager.conf и прокомментируйте строку dns=dnsmasq. Это делается для того, чтобы NM мог указывать фактические IP-адреса DNS вместо 127.0.0.1.
  • Перезапустить NM с помощью sudo service network-manager restart.
  • Перезапустите службу docker с помощью sudo service docker restart.

Запуск контейнера затем позволил бы ему выполнять apt-get update/upgrade, например.

5

Докер официальный документ предоставляет инструменты для настройки DNS-сервера для использования Docker

  1. Откройте /etc/default/docker файл для редактирования:

    sudo nano /etc/default/docker

  2. Добавьте настройку для Docker:

    DOCKER_OPTS="--dns 8.8.8.8"

  3. Заменять 8.8.8.8 с локальным DNS-сервером, таким как 192.168.1.1. Вы также можете указать несколько DNS-серверов. Разделите их пробелами, например:

    --dns 8.8.8.8 --dns 192.168.1.1

    Предупреждение: Если вы делаете это на ноутбуке, который подключается к различным сетям, обязательно выберите общедоступный DNS-сервер.

    пс: nm-tool может использоваться для проверки DNS-сервера локального хоста

  4. Сохраните и закройте файл.

  5. Перезапустите демон Docker.

    sudo service docker restart
6

Ваша ошибка здесь:

 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]

Это не ошибка с DNS, вместо этого ваша система пытается подключиться к хостам IPv6 и терпит неудачу. Предположительно, потому, что у вас нет доступа IPv6 на вашем хосте. Фактический поиск адреса IPv6 завершается успешно. (Зеркало/архив ubuntu доступно как по IPv6, так и по IPv4. Вам просто не повезло, что вы попали на IPv6, потому что ваша система считает, что он должен работать.)

Вы должны либо исправить это, либо установка miredo, или повторяйте попытку до тех пор, пока вы не попадете на зеркало IPv4.

Опять же, здесь важно понимать, что DNS не виноват, как вы можете видеть из ваших собственных тестов ping.

7

Для других читателей, которые приходят сюда при использовании boot2docker, вот как я исправил. На самом деле, приведенный выше ответ указал мне правильное направление.

По сути, по какой-то причине контейнеры внутри boot2docker не смогли разрешить имена хостов.

Поэтому я просто перезапустил boot2docker и запустил контейнеры. Теперь имена хостов снова могут разрешаться правильно.

Я полагаю, проблема заключалась в запуске boot2docker во время подключения к сети на хосте, что привело к запуску boot2docker и переходу в нерабочее состояние.

8

Я столкнулся с этой проблемой, когда разрешил установщику Ubuntu установить пакет Docker snap. Когда я отказался от этого и переключился на официальный пакет Docker, проблема разрешилась сама собой.

sudo snap remove dockercurl -fsSL https://get.docker.com -o get-docker.shsh get-docker.sh
9

Откройте файл /lib/systemd/system/docker.service

В ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sockдобавлять
--dns 8.8.8.8

Подобный этому:

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --dns 8.8.8.8

Перезапустите службу docker

10

У меня была такая же проблема в Windows. Эта команда заставила его работать на меня: docker-machine restart

11

Была аналогичная проблема, но и разрешение имен между контейнерами внутри определяемой пользователем сети, казалось, было немного неустойчивым. Некоторые не могли решить ничего подобного тебе.

Проблема заключалась в перемещении /var/lib/docker. По соображениям экономии места он был смонтирован через nfs. Добавление локальной файловой системы и перемещение файлов туда решает проблему.

12

Для меня это сработало после перезагрузки.