Ошибка соединения узла с бэкендом Python внутри докера

Question

У меня есть угловое приложение, размещенное с помощью Node, а также есть бэкэнд с флешкой Python для других операций с Python. Поскольку это 2 отдельных модуля, я создал отдельные образы докеров для узла + угловая и колба питона. Для изоляции я также использовал сеть докеров для этих контейнеров.

Я создал изображения и запустил контейнеры с помощью следующих команд:

docker container run -d -p 5000:5000 --network reporter-net --name backend backend-server
docker container run -d -p 3000:3000 --network reporter-net --name frontend frontend-server

Но из внешнего интерфейса я вызывал бэкэнд с помощью URL-адреса

http://backend:5000

главным образом потому, что я думал, что связь происходит от контейнера узла к этому бэкэнду Python. Я также попытался вызвать Python Backend, используя этот URL http://backend:5000, и это работало без проблем.

После развертывания этой архитектуры она не может взаимодействовать с бэкэндом. Позже я понял от коллег, что во время работы угловой код будет загружен в браузер, а затем браузер напрямую вызывает бэкэнд Python.

В этом случае, очевидно, браузер не может определить http://backend:5000. Когда я попытался заменить его на http://localhost:5000,, он работал (оба на одной машине).

Но как я могу решить эту проблему во время работы в производстве? Потому что в производстве контейнер python может находиться на разных серверах, как в микросервисах. Так что может быть сложно получить ip сервера бэкэнда Python, а также он необходим перед созданием образа.

Есть ли другое простое решение для этого? Я слишком много думаю? И я также думаю об использовании ALB перед внутренними серверами (на производстве), чтобы мы могли создавать изображения внешнего интерфейса с помощью http://:5000, и он перенаправит запрос на любой http://backend:5000.

В поисках решения.

Answer 1

Если вы планируете запускать контейнеры Python на нескольких серверах одновременно для масштабирования, тогда лучшим вариантом будет ALB.

Если вы планируете использовать только один экземпляр контейнера для одного экземпляра EC2, вы можете использовать как ALB, так и CLB. Но если вы планируете запускать несколько экземпляров этих контейнеров на одном экземпляре EC2, то вам понадобится функция динамического сопоставления портов, которая является частью службы ECS, чтобы ваш ALB (CLB в этом случае не был опцией) мог обнаружить ваши контейнеры. порты внутри своей целевой группы (так как вы не можете жестко их кодировать). И даже если вы не собираетесь запускать несколько копий одного и того же контейнера на одном и том же экземпляре EC2, я все равно рекомендую использовать службу ECS, так как она решает много вопросов для вас.

Затем вы можете использовать общедоступное DNS-имя вашего балансировщика нагрузки в качестве конечной точки для вызова из вашего приложения Angular без каких-либо проблем.

Я бы не стал полагаться на управление связью через IP-адреса. Даже если у вас уже запущены экземпляры EC2 и вы получили их IP-адреса, если какой-либо из этих экземпляров остановлен и запущен, его общедоступный IP-адрес освобождается, и вы получите новый при запуске. Вы можете использовать Elastic IP здесь, но это еще одна вещь, о которой вам нужно позаботиться. И это становится еще хуже, когда мы говорим о контейнеризации, или, точнее, о запуске нескольких копий одного контейнера на одном виртуальном хосте.