В чем разница между размещением отдельного обнаружения службы и его интеграцией в компьютер кластера в Docker Swarm

Question

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

Answer 1

Docker Swarm предназначен для создания кластера хостов, на которых выполняется Docker, и планирования контейнеров по всему кластеру.
Он не включает в себя обнаружение службы, которая предоставляется серверной службой, такой как etcd, консул или zookeeper.

• Первая проблема: регистрация и обнаружение услуг - это проблема инфраструктуры, а не проблема приложения.
• Вторая проблема: реализация регистрации и обнаружения сервисов, когда инфраструктура и реализация приложений взаимно независимы, является сложной задачей.

DockerCon проясняет это различие сегодня утром (16 ноября 2015 г.) с помощью "стека докеров":

^{(Графика от @laurelcomics)}

Сеть Docker решает эти проблемы, поддерживая интерфейс (DNS) с подключаемыми компонентами инфраструктуры, которые придерживаются общего интерфейса KV.

Вы можете увидеть файл consul.io, используемый в:

• " Простая маршрутизация и обнаружение сервисов с помощью Docker, Consul и nginx "
• " Сети наложения Docker: это было легко "
• " Докер DNS getaddrinfo ENOTFOUN D "

Это означает:

• Consul - это хранилище KV (Key/Value), которое можно подключить к Swarm для управления аспектом обнаружения услуг.
• Swarm - это уровень доступа, который обычно представляет собой уровень, который содержит шлюз или компонент маршрутизации, который позволяет другим реально достигать ваших услуг.

^{(Изображение из статьи " Легкая маршрутизация и поиск сервисов с помощью Docker, Consul и nginx ", написанной Ладиславом Газо)}

Цель состоит в том, чтобы изолировать объект инфраструктуры (служба обнаружения) в собственном контейнере отдельно от объекта разработки (Swarm).