Представьте, что у меня есть такая установка:
1.0.0.1
; Частное имя хоста: machine1.internal.domain
2.0.0.1
; Публичное имя хоста: machine1.example.com
1.0.0.2
; Частное имя хоста: machine2.internal.domain
2.0.0.2
; Публичное имя хоста: machine2.example.com
Эти 2 машины находятся в DMZ.
Machine1 необходимо подключиться к machine2, используя внутреннее имя хоста. Важно одно: мы не хотим, чтобы трафик между ними выходил за пределы DMZ. И имя хоста machine2.internal.domain
жестко запрограммирован в приложении, работающем на машине №1.
Без установки Dockerized:
machine2.internal.domain
, уже все хорошо./etc/hosts
в machine1: machine2.internal.domain 1.0.0.2
С настройкой Dockerized я знаю, когда разрешение имен не работает, контейнер Docker не может достичь machine2, поскольку он не наследует записи в /etc/hosts
хост-машины.
Как мне заставить эту штуку работать наилучшим образом? ... для обоих случаев: разрешение DNS работает и не работает.
Я рассмотрел следующие варианты для случая 2:
docker run --add-host machine2.internal.domain:1.0.0.2 ...
machine2.internal.domain
дважды: один раз в /etc/hosts
и однажды в команде запуска Dockerdocker blabla --net=host
Если у вас есть внутренний DNS-сервер, вы можете запустить приложение Docker с параметром --dns = [].
Настройте свой внутренний DNS-сервер в качестве сервера пересылки на настоящий DNS, когда поиск имени завершается неудачно, чтобы любые внутренние имена использовали внутренний адрес.
Другой вариант - записать пользовательский файл hosts в образ докера, что нормально, если они исправлены, но не всегда идеально.
Третий способ - рассмотреть возможность использования чего-то вроде skydns. Если ваши докеры работают под управлением CoreOS или если у вас есть кластер etcd2, он тоже подойдет.
Безусловно, лучший вариант - заставить ваши хосты работать через какой-то механизм обнаружения, где все есть, а не полагаться на DNS. Однако обычно для этого требуется что-то вроде etcd2 или consul.