Подключитесь к хосту A из докера, работающего на хосте B

Question

Разрабатываю распределенную систему и рассматриваю ситуацию: Мое приложение работает в докере, работающем на хосте A, и я хочу вызвать api из другой службы, работающей на физическом хосте B (без докера). Могу ли я сделать это, позвонив по IP-адресу или DNS-адресу?

Другая ситуация, которая касается вышеуказанной проблемы: Я разрабатываю распределенную систему локально, используя docker-compose, и определяю там службы: ServiceA, ServiceB и так далее. Если ServiceA должен позвонить в ServiceB через порт 8080, я звоню http://ServiceB:8080/, и он работает нормально. В производстве каждый сервис должен работать на разных хостах с разными IP. Так это хороший способ, чтобы я запускал каждую службу на разных хостах, и я буду звонить из ServiceA в ServiceB по http://<IP_of_ServiceB>:8080 вместо использования имени службы?

Answer 1

Одна часть инфраструктуры, которую вы можете найти полезной, - это реестр служб , который знает, на каких хостах работают какие службы. Как правило, они предоставляют службы DNS, поэтому вы можете ссылаться на службу по ее «имени хоста» и направлять ее на фактический хост (или хосты), на котором запущена служба. Идея заключается в том, что вы обращаетесь к сервисам Docker и не-Docker по (возможно, искусственному) имени хоста, а уровень инфраструктуры направляет его на правильные хосты. За исключением варианта Kubernetes, они не требуют специальной настройки сети, кроме указания на правильный DNS-сервер.

Три конкретных примера, которые я использовал ранее:

• В AWS (если вы уже используете / оплачиваете это), вы можете настроить балансировщик нагрузки , указывающий на каждый узел, с проверкой работоспособности; если узел обслуживает (например) порт 9123, то порт 80 балансировщика нагрузки будет маршрутизировать туда. Затем вы можете настроить DNS-имя , которое указывает на балансировщик нагрузки. Для каждой службы запустите ее на определенном известном порту на любом количестве нужных вам узлов и создайте балансировщик нагрузки и DNS-имя для каждого. (Вы также можете создавать записи DNS CNAME, которые являются псевдонимами для внешних хостов службы.) Это стандартная настройка для ECS , но она не привязана к этой службе специально; на самом деле, если вы можете предоставить свой собственный балансировщик нагрузки и сервер имен, вы можете использовать этот подход где угодно.

• Hashicorp's Consul предназначен (помимо прочего) в качестве реестра служб. В режиме, который я использовал в прошлом, вы устанавливали агент Консул на каждом узле, а на каждом узле устанавливали набор проверок работоспособности, который проверяет каждую известную службу. Настройте ваши контейнеры Docker так, чтобы они указывали на DNS-сервер Consul. Имена хостов, такие как servicename.service.consul, будут преобразованы в IP-адреса хостов, на которых запущена служба, а затем вы можете ссылаться на URL-адреса, например http://servicename.service.consul:9123/, с портом службы. (Я полагаю, что вы можете переопределить адрес службы в определении , чтобы указать его на внешнем сервере.)

• В Kubernetes имеется стандартный объект Service , который обеспечивает балансировку нагрузки и DNS. Вы можете настроить Службу так, чтобы она прослушивала какой-либо порт и направляла к другому порту на некотором наборе модулей (которые в свою очередь запускают контейнеры Docker). Вы бы использовали имена хостов, например servicename.default.svc.cluster.local, но большинство из них также попадают в путь поиска DNS по умолчанию, поэтому просто http://servicename/ часто является хорошим URL. (Вы можете настроить службу ExternalName, которая является просто записью DNS, указывающей вне кластера.)

Answer 2

Первый вопрос, да, просто убедитесь, что порты открыты и доступны с другого хоста.

Второй вопрос, вы все еще можете это сделать (запишите ip хоста B в env или около того). Или вы можете рассмотреть возможность использования Docker Swarm для развертывания вашего производственного стека. В сочетании с оверлейной сетью, которая позволяет вашим двум хостам действовать как один, вы можете продолжать звонить как http://ServiceB:3000/

version: '3'
services:
  serviceA:
    image: serviceA
    ports:
      - "8080:8080"
    networks: 
      - swarm-net

  serviceB:
    image: serviceB
    networks: 
      - swarm-net
    ports:
      - "3000:3000"

networks:
  swarm-net:
    driver: overlay