host.docker.internal против имени контейнера при ссылке на ip

ProgramBox

host.docker.internal против имени контейнера при ссылке на ip

Post author:admin
Запись опубликована:20 июля, 2022
Post category:Вопросы по программированию

#docker #docker-compose

Вопрос:

При определении служб в файле docker-compose, когда я использую host.docker.internal IP-адрес хоста и когда мне нужно использовать имя контейнера?

1. Вам никогда не нужно использовать host.docker.internal для подключения к другой службе, определенной в том же файле компоновки. В документации к Docker в разделе Compose описывается, какие имена хостов и параметры конфигурации доступны.

2. @DavidMaze Там есть отрывок, в котором говорится: «У хоста есть изменяющийся IP-адрес (или его нет, если у вас нет доступа к сети). Мы рекомендуем вам подключиться к специальному DNS-имени host.docker.internal, которое преобразуется во внутренний IP-адрес, используемый хостом. Это предназначено для разработки и не будет работать в производственной среде за пределами Docker Desktop для Windows «. docs.docker.com/desktop/windows/networking

3. Итак, вопрос в том, почему это не будет работать в производственной среде?

4. Обычно вы не используете приложение типа «desktop» в рабочей среде. И наоборот, в рабочей среде я бы не удивился, увидев такие вещи, как базы данных на выделенном оборудовании или в облачных сервисах, которые также не будут «одним и тем же хостом»; вам нужно убедиться, что у вас есть хороший способ настроить их местоположение во время развертывания.

Ответ №1:

Здесь проиллюстрированы все возможные потоки связи :

(1): неконтейнеризованный процесс взаимодействует с контейнером

(2): контейнер обменивается данными с другим контейнером

(3) : противоположное направление (1)

(1): контейнер должен перенаправить порт на хост, чтобы неконтейнеризованный процесс мог получить к нему доступ

 services:
   c1:
    ...
     ports:
       - hostport:containerport

(2): контейнер c1 просто использует имя службы (имя контейнера — c2) для связи с c2

(3): контейнер c2 должен использовать частный IP-адрес хоста ( hostname -i ).

Для (3) есть несколько моментов:

Диапазон сети хоста не должен перекрываться с диапазоном сети Docker, иначе маршрутизатор Docker не отправит запрос.
Хост не должен включать брандмауэр, который блокирует порты, используемые неконтейнеризованным процессом.
ЕСЛИ вы используете Docker для рабочего стола, host.docker.internal это псевдоним частного IP-адреса хоста. тогда вам не нужно вычислять частный IP-адрес хоста hostname -i .

1. красиво проиллюстрировано — спасибо за понимание 😉

2. Добро пожаловать, человек! 🙂

3. Там есть отрывок, в котором говорится: «У хоста есть изменяющийся IP-адрес (или его нет, если у вас нет доступа к сети). Мы рекомендуем вам подключиться к специальному DNS-имени host.docker.internal, которое преобразуется во внутренний IP-адрес, используемый хостом. Это предназначено для разработки и не будет работать в производственной среде за пределами Docker Desktop для Windows «. docs.docker.com/desktop/windows/networking

4. Итак, вопрос в том, почему это не будет работать в производственной среде?

5. Используйте частный IP ( hostname -i ) вашего хоста в рабочей среде, предполагая, что существует перекрытие между сетевым диапазоном docker и host.

Ответ №2:

Если вы хотите подключиться из контейнера к службе на хосте, используйте host.docker.internal . Имейте в виду, что это специальное DNS-имя доступно только в Windows и macOS.

Используйте имя контейнера для сетевого взаимодействия между контейнерами.