При чтении документации для Docker Swarm 1.12 есть раздел, в котором описывается, как настроить HAProxy для балансировки нагрузки на узлы роя.
https://docs.docker.com/engine/swarm/ingress/#/configure-an-external-load-balancer
Если я понимаю Docker Swarm> 1.12, нет необходимости настраивать балансировщик нагрузки таким образом, потому что Swarm имеет внутренний балансировщик нагрузки и DNS.
Разве не было бы правильным подходом установить обратный прокси-сервер для имени службы (псевдоним DNS) и позволить балансировщику нагрузки Swarm выполнять эту работу?
Например, в nginx вы можете:
location /somepath/ {
proxy_read_timeout 900;
proxy_pass http://service-name/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Я предполагаю, что служба развертывается в наложении частной сети, а служба, которая должна быть доступна извне, развертывается в частной сети и в прокси-сети, где также развернута служба nginx или haproxy.
docker service create
--name recurrence-service \
--replicas 3 \
--network my-service \
--network proxy \
mycompany/my-web-server
Swarm Mode включает в себя внутренний DNS и сетку маршрутизации для обеспечения обнаружения службы и пересылки запросов между узлами на тот, на котором запущена служба. Это означает, что все узлы будут прослушивать опубликованный порт (когда вы используете "входящий" режим по умолчанию), и этот запрос будет перенаправлен внутри между узлами роя.
Однако при внешнем доступе к службе балансировщику нагрузки все же рекомендуется отправлять запросы на один из множества узлов. Это для HA, так как любой узел может быть недоступен, а остальные перейдут к нему. Если вы отправляете все запросы только на один узел, и этот узел выходит из строя, вы не сможете получить доступ к своей службе, даже если другие узлы все еще доступны и обслуживают запросы.
В качестве альтернативы вы можете использовать циклический DNS, настроенный для разрешения на несколько хостов докеров. Однако это не так идеально по нескольким причинам:
Я думаю, что ваш подход звучит хорошо, и я не думаю, что есть какие-либо требования для внешнего LB. Мы ставим ELB перед нашим, но это больше для того, чтобы он оставался стандартным для других сервисов и чтобы у нас было центральное место, где мы делаем SSL.