Сети / Запросы
Во многих приложениях вам потребуется более одного контейнера по двум основным причинам:

  1. Сосредоточение каждого контейнера на одной основной задаче (например, на запуске веб-сервера или базы данных) считается хорошей идеей.
  2. Настроить контейнер для выполнения более чем одной «основной задачи» очень сложно (например, запустить веб-сервер И базу данных).

Многоконтейнерные приложения очень распространены, особенно при работе с «настоящими приложениями».
Некоторым из этих контейнеров часто необходимо взаимодействовать следующими способами:

  1. либо друг с другом
  2. или с хост-машиной
  3. или со всемирной паутиной

Общение со всемирной паутиной (WWW)

К счастью, общение с WWW (т. е. отправка HTTP-запросов или других видов запросов на другие серверы) очень просто.

Рассмотрим этот пример JavaScript — хотя он будет работать всегда, независимо от того, какую технологию вы
используете:

fetch('https://some-api.com/my-data').then(...)

Этот очень простой фрагмент кода пытается отправить запрос GET на сайт some-api.com/my-data.
Это будет работать сразу после установки, никаких дополнительных настроек не требуется! Приложение, работающее в
контейнере, не будет иметь проблем с отправкой этого запроса.

Связь с хост-машиной

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

Одно важное замечание: если вы развертываете контейнер на сервере (то есть на другом компьютере), маловероятно
, что вам потребуется взаимодействовать с этим компьютером. Связь с хост-компьютером обычно является
требованием во время разработки — например, потому что вы запускаете некоторую базу данных разработки на своем компьютере.
Опять же, рассмотрим этот пример JS:

fetch('https://some-api.com/my-data').then(…)
fetch('localhost:3000/demo').then(…)

Этот фрагмент кода пытается отправить запрос GET на какой-либо веб-сервер, работающий на локальном хост-компьютере (т. е. за пределами контейнера, но не в WWW).
На вашем локальном компьютере это сработает, а внутри контейнера не удастся. Поскольку локальный хост внутри контейнера относится к среде контейнера, а не к вашему локальному хост-компьютеру, на котором работает контейнер / Docker!
Но Docker поможет вам!
Вам просто нужно изменить этот фрагмент следующим образом. :
host.docker.internal — это специальный адрес/идентификатор, который транслируется в IP-адрес машины, на которой размещен Контейнер, Docker.
Важно: «Переведено» не означает, что Docker идет дальше и изменяет исходный код. Вместо этого
он просто обнаруживает исходящий запрос и может разрешить IP-адрес для этого запроса. Итак, ваш окончательный код будет таким:

fetch('https://some-api.com/my-data').then(…)
fetch('host.docker.internal:3000/demo').then(…)

Взаимодействие с другими контейнерами

Связь с другими контейнерами также довольно проста. У вас есть два основных варианта:

  1. Вручную узнать IP другого контейнера (хотя он может измениться)
  2. Используйте сети Docker и поместите взаимодействующие контейнеры в одну и ту же сеть.

Вариант 1 не очень хорош, поскольку вам нужно искать IP-адрес самостоятельно, и он может измениться с течением
времени.
Однако вариант 2 идеален. С помощью Docker вы можете создавать сети через сеть докеров, чтобы создать
SOME_NAME, а затем вы можете подключить несколько контейнеров к одной и той же сети.

Вот так:
И cont1, и cont2 будут в одной сети.
Теперь вы можете просто использовать имена контейнеров, чтобы позволить им взаимодействовать друг с другом — опять же,
Docker разрешит вам IP-адрес (см. выше).

fetch('host.docker.internal:3000/demo').then(…)

docker run -network my-network –name cont1 my-image
docker run -network my-network –name cont2 my-other-image

код будет таким.

fetch('cont1/my-data').then(…)