обнаружение службы в docker без использования consul
Я новичок в docker и microservices. Я начал разлагать свое веб-приложение на микросервисы, и в настоящее время я делаю ручную настройку.
после некоторого исследования я наткнулся на режим Docker swarm, который позволяет обнаруживать службы. Кроме того, я наткнулся на другие инструменты для обнаружения службы, такие как Эврика и консул.
моя главная цель-заменить IP-адреса в вызове curl именем службы и балансом нагрузки между несколькими экземплярами одного и того же услуга.
т. е. для ex. curl http://192.168.0.11:8080/ завивать http://my-service
Я должен держать язык моих услуг независимым.
пожалуйста, предложите, мне нужно использовать Consul с docker swarm для обнаружения службы или я могу сделать это без консула? В чем преимущества?
3 ответов
С новым "режимом Роя" вы можете использовать docker услуги для создания кластеризованных служб на нескольких узлах Роя. Затем можно получить доступ к тем же службам с балансировкой нагрузки, используя имя службы, а не имя узла в запросах.
Это относится только к узлам в сети Роя. Если ваши клиентские системы являются частью одного и того же Роя, то discovery должен работать из коробки без каких-либо внешних решений.
на с другой стороны, если вы хотите, чтобы иметь возможность обнаружить услуги из систем за пределами Роя, у вас есть несколько вариантов:
- за услуги без гражданства, вы можете использовать Docker-х маршрутизация сетки, что сделает порт службы доступным для всех узлов Роя. Таким образом, вы можете просто указать на любой узел в рое, и docker направит ваш запрос на узел, на котором запущена служба (независимо от того, имеет ли узел, на который вы попали, службу или нет).
- используйте фактический балансировщик нагрузки перед вашими службами swarm, если вам нужно контролировать маршрутизацию или иметь дело с различными состояниями. Это может быть либо другой сервис docker (т. е. haproxy, nginx), запущенный с помощью
--mode globalопция, чтобы убедиться, что он работает на всех узлах, или отдельный балансировщик нагрузки, как citrix netscaler. Вам нужно будет перенастроить контейнеры служб LB с помощью сценариев запуска или инструментов подготовки (или добавить их вручную). - использовать что-то вроде консула для обнаружения внешних служб. Возможно, в сочетании с регистратор для автоматического добавления служб. В этом случае вы просто настроить внешних клиентов, чтобы использовать сервер консул / кластер для разрешения DNS (или использовать API).
вы могли бы, конечно, просто переместить своих потребителей услуг в рой. Если вы отделяете клиентов от служб в разных физических VLAN (или VPCs и т. д.), Вам нужно будет запустите клиентские контейнеры в отдельных сетях наложения, чтобы убедиться, что вы эффективно не победите любую физическую сегрегацию сети уже на месте.
обнаружение службы (через dns) встроено в docker с версии 1.12. Когда вы создаете пользовательскую сеть (например, мост или наложение, если у вас несколько хостов), вы можете просто заставить контейнеры разговаривать друг с другом по имени, пока они являются частью одной сети. Вы также можете иметь псевдоним для каждого контейнера, который будет округлять список контейнеров, имеющих тот же псевдоним. Для простого примера см.:
пока вы используете режим моста для своей сети docker и создаете свои контейнеры внутри этой сети, обнаружение служб доступно вам из коробки.
вам нужно будет получить помощь от других инструментов, как только ваша инфраструктура начнет охватывать несколько серверов и микросервисов, распределенных на них.
Swarm-хороший инструмент для начала, однако я хотел бы придерживаться consul, если дело доходит до любого поставщика IaaS, такого как Amazon для моего производства нагрузки.