Контейнери Docker не можуть вирішити DNS на хості на робочому столі Ubuntu 14.04

48

У мене виникають проблеми з моїми контейнерами 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 та перезапустив докер.

Я також спробував витягнути Coreos, і Yum також не міг вирішити DNS.

Це дивно, тому що, хоча DNS не працює, я все одно отримую відповідь, коли підпилюю ті самі сервери оновлення, які apt-get не може вирішити.

Я не за проксі, я в дуже стандартній локальній мережі, і ця версія Ubuntu актуальна та нова (я встановив два дні тому, щоб бути ближче до докера).

Я ретельно досліджував це через інші публікації з питань stackoverflow та github, але не знайшов жодного рішення. У мене немає ідей, як вирішити цю проблему, хтось може допомогти?

Повідомлення про помилку

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

Контейнер 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 не вдається, коли я змушую 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
ubuntu  networking  domain-name-system  docker  lxc 
— Томас В.
джерело
Для мене це спрацювало після перезавантаження.
— ssi-anik

Відповіді:

64

Ву, я знайшов допис на github, який вирішив мою проблему.

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

Мабуть, мережевий міст docker0 був підвішений. Встановлення Bridge-утиліти та виконання наступних параметрів призвело до роботи мого Docker:

apt-get install bridge-utils
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
service docker restart
— Томас В.
джерело
1
вам не потрібно перезавантажувати зображення. resoluv.conf генерується щоразу, коли ви запускаєте новий контейнер. тож вам потрібно вийняти старий контейнер і запустити ще один. я вчора був розладнаний з цією проблемою. Крім того, якщо ви перебуваєте в корпоративному інтрамережі, ви можете передати --dns-search = your.company.domain до демон-докеру в / etc / default / docker у змінній DOCKER_OPTS env поблизу прапорів --dns --dns.
— Олександр.Ілюшкін
Це вирішило і мої проблеми з докером.
— BobMcGee
3
На арку linux мені потрібно було ip link set down docker0замість ifconfig docker0 downі systemctl restart dockerзамість service docker start. Щоб видалити всі зображення, я зробивdocker rmi $(docker images -q)
— meshy
Це працювало вперше для мене. Потім я перезавантажився, і проблема з’явилася знову: відтворення цих кроків не вирішило проблему знову. Я поняття не маю, про що йдеться.
— user626921
1
Щойно побачив, що мій інтерфейс docker0 не працює, я виконаний, /etc/init.d/docker restartі він повернувся до справи
— lolesque
14

Якщо це проблема з розв’язувачем DNS, ось таке рішення:

Перше, що потрібно перевірити, це запустити cat /etc/resolv.confв контейнер докера . Якщо у нього недійсний DNS-сервер, наприклад nameserver 127.0.x.x, контейнер не зможе вирішити доменні імена в ip-адреси, тому ping google.comне вдасться.

Друге, що потрібно перевірити, працює cat /etc/resolv.confна хост-машині . Docker в основному копіює хост /etc/resolv.confу контейнер щоразу, коли контейнер запускається. Тож, якщо хост /etc/resolv.confпомиляється, то так буде і з контейнером докера.

Якщо ви виявили, що хост /etc/resolv.confнеправий, то у вас є два варіанти:

  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"]
}

  • Перезапустіть демон докера, щоб ці зміни вступили в силу:
    sudo systemctl restart 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 за замовчуванням використовує 8.8.8.8 сервер DNS Google, який може зламатися для людей, що знаходяться за брандмауером.

  • /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 для копіювання в контейнери.

— wisbucky
джерело
Дякую за це, я справді втрачав розум, намагаючись зрозуміти, що відбувається з докерними контейнерами та 18.04 розв’язуванням IP-адрес на VPN. Виправлення /etc/resolv.conf за 18.04 працювало на мене!
— Джордж Папас
варіант B працював на мене ..
— codeSetter
Напевно 2B не переживе оновлення systemdпакету ...
— Auspex
13

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

Моя мережа була пов'язана з офісом, і налаштування 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 OVERWRITTEN
nameserver 127.0.1.1
search companyDomain.co.za

Це пов’язано з тим, що Менеджер мережі робить якесь маскування деталей сервера DNS.

На жаль, відповідно до посібників докер, докер буде фільтрувати будь-які IP-адреси localhost під час створення контейнера resv.conf та заміняти їх на IP-адреси DNS Google. Що в моєму випадку спричинило завищення доменних імен.

Мені довелося:

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

apt-get update/upgradeНаприклад, запуск контейнера дозволив би це зробити , наприклад.

— Девід "лисий імбир"
джерело
3
Це насправді працювало для мене. І я стояв за інтранет компанії
— Даніель Андрій Мінка
1
Це рішення чудово підходить для Ubuntu 16.04 та новіших версій. Для Ubuntu 18.04 та новіших версій див. Сервер default.com/a/918568
— wisbucky
Дякую! Це спрацювало, поки прийнятої відповіді не було. :)
— Devolus
8

Ваша помилка тут:

 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.

1
Дякую за швидку відповідь та уточнення, що це насправді не проблема DNS, я ціную це. Я встановив miredo - не йду. Варто також зазначити, що коли я запускаю apt-get update -o Acquire :: ForceIPv4 = справжнє оновлення apt-get все ще не вдається, я оновив свій оригінальний пост з цією відповіддю. Я намагався відключити UFW, думаючи, що, можливо, це було так, і досі не пощастило.
— Томас В.
Дивно - ви можете бачити, що у вас IPv4-з'єднання, оскільки ваш ping успішний. Але ви не можете підключитися до дзеркала, незважаючи на те, що у вас є проблеми з маршрутизацією / мережею (
8

Офіційний документ Docker надає інструменти для налаштування 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-сервер.

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

  4. Збережіть і закрийте файл.

  5. Перезапустіть демон Докера.

    sudo service docker restart
— tryer3000
джерело
Зауважте, що це старий конфігураційний файл для Docker Upstart та SysVinit. Поточний спосіб для systemd (починаючи з Ubuntu 16.04) - це використовувати /etc/docker/daemon.jsonдля докерських налаштувань демона, таких як dns.
— wisbucky
0

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

В основному, чомусь контейнери всередині boot2docker не могли вирішити імена хостів.

Тому я просто перезапустив boot2docker і запустив контейнери. Тепер імена хостів можуть знову правильно вирішитись.

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

— Око
джерело
0

Перезапустіть демон Docker на Debian9

service docker restart

і з'єднання та мережі справно працюють

— Нолвенніг
джерело
-1

Мав аналогічну проблему, але вирішення імен між контейнерами всередині визначеної користувачем мережі здавалося дещо хиткими. Деякі не могли вирішити щось подібне до вас.

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

— michi.0x5d
джерело
Якщо ви вважаєте, що на питання можна відповісти відповідним запитанням, будь-ласка, позначте його як дублікат цього питання. Якщо ви не можете цього зробити, вам слід залишити коментар, а не робити окрему відповідь.
— Дженні Д каже, що поверніть Моніку
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.