2017-02-14 5 views
3

Текущая версия докера: 1.13.1, build 092cba3.Все внешние DNS-запросы терпят неудачу из контейнера докеров

Содержание /etc/resolv.conf:

search mycompany.local 
nameserver 127.0.0.11 
options ndots:0 

(реальное название компании затемненный).

nslookup на самом хосте на 100% отлично, но изнутри контейнера любое внешнее имя хоста не работает (невозможно запустить событие apt-get update). Те же симптомы сохраняются во всех моих хостах в кластере с четырьмя узлами. Обратите внимание, что внутреннее разрешение имен служб работает между контейнерами.

Выполнение такого же приложения непосредственно на моем ноутбуке (в той же сети офиса).

Это становится немного медленной движущейся катастрофой.

В состав кластера по-прежнему входит сборка до 1.12, которая может иметь любой подшипник.

+0

Хорошо, я вижу, что запись сервера имен для 127.0.0.11, вероятно, (?) Проблема. Дублирующие тесты [отсюда] (http://www.networkcomputing.com/data-centers/docker-networking-basic-dns-configuration/2052420654) дают рабочий контейнер. Может ли это быть докер-сочинение, которое вызывает проблему? – demaniak

+0

О, моя ДУША. После всех этих усилий кажется, что основной DNS-сервер имел некоторую серьезную головную боль. После нашей поддержки ребята пересчитали сервис dns, внезапно все снова начинает работать. ПОЧЕМУ мое тестирование nslookup на хостах не сработало - я не знаю. – demaniak

ответ

0

В Linux lo или локальный интерфейс будет иметь адрес 127.0.0.1/8 (т. Е. Netmask 255.0.0.0). Это маска подсеть охватывает весь этот диапазон:

127.0.0.0 - 127.255.255.255 

Поскольку 127.0.0.11 попадет в этот диапазон, подключение к этому адресу будет пытаться маршрут через интерфейс lo (внутри контейнер) в качестве подключенного маршрута. Если в вашем контейнере этот адрес не сконфигурирован внутренне и имеет DNS-ресивер, прослушивающий этот адрес, это приведет к таймауту соединения.

Возможно, вы можете решить эту проблему путем маршрутизации 127.0.0.11 из основного интерфейса контейнера (например, eth0) или путем изменения адреса DNS-резольвера, чтобы он находился вне 127.0.0.0/8.

Вы также можете указать IP-адреса DNS-сервера явно.

docker run --dns 1.2.3.4     # set one server 
docker run --dns 1.2.3.4 --dns 5.6.7.8 # set multiple servers 

Или с помощью докер-compose.yml:

dns: 1.2.3.4 

dns: 
    - 1.2.3.4 
    - 5.6.7.8 
+0

Спасибо за ответ. Я считаю, что вы технически верны, но после работы [это] (http://www.networkcomputing.com/data-centers/docker-networking-basic-dns-configuration/2052420654) я изо всех сил пытаюсь понять, ПОЧЕМУ я в конечном итоге с 127.0.0.11 в '/ etc/resolv.conf'. Запустив тот же контейнер, что и эта ссылка (без компоновки), правильный сервер имен приземляется в resolv. Кроме того, на прошлой неделе это все еще работало нормально. Единственным существенным изменением было обновление докеры 1.13 – demaniak

+0

@demaniak Является ли IP-адрес сервера имен в вашей системе до 1.13-контейнера чем-то иным, чем '127.0.0. *'? Обычно IP-сервер имен в системе хостинга Linux просто передается как контейнер контейнера (по крайней мере, по моему опыту). –

+0

до этого беспорядка, у меня не было причин обнюхивать внутренности DNS, поэтому я могу сказать наверняка следующее: сами хосты имеют собственный сервер имен в 10.0.0. * Range и dns работает. Все контейнеры для этого приложения, развернутые с составлением в этом кластере, имеют сервер имен 127.0.0.11 (с ошибкой внешнего имени). hm, возможно, отредактируйте вопрос, чтобы очистить это: внутреннее разрешение имен службы действительно кажется прекрасным. Обычно не считают, что «DNS» per se. – demaniak

0

Вот настройки я использую:

  1. Установка Dnsmasq.
  2. Пробег echo interface=docker0 > /etc/dnsmasq.d/docker
  3. Restart dnsmasq.
  4. Добавить --dns 172.17.0.1 вам докер-бежать или демон Docker (добавляя его к DOCKER_OPTS переменной в/и т.д./по умолчанию/грузчиком или редактирования ExecStart директиву/Lib /systemd/system/docker.service).
  5. Restart Docker.

Теперь у вас есть все ваши контейнеры, указывающие на Dnsmasq как DNS-резольвер. Другая сторона - это то, что в ваших записях в/etc/hosts также разрешены.