Я занимаюсь развертыванием системы Docker Swarm с высокой доступностью в нескольких центрах обработки данных, но у меня есть небольшой вопрос высокого уровня о различиях конфигурации.
Скажем, у меня есть единственная служба докеров под названием worker, и база данных SQL HA master-master между центрами обработки данных dc-a и dc-b. В данный момент, worker будет использовать ту же конфигурацию, независимо от того, запущена ли она на dc-a или dc-b.
Есть ли способ отличить конфигурацию внутреннего рабочего или образ докера, так что если worker развернут в dc-a, он работает config-a, и если развернут в dc-b, он работает config-b?
Конечная цель - всегда нацеливаться на базу данных, которая является локальной для текущего центра обработки данных. Я знаю, что можно использовать разные DNS-записи центра обработки данных для управления подключениями к базе данных на локальном компьютере, но было бы более гибко, если бы мы могли использовать полностью отдельную конфигурацию / образ в зависимости от того, где развернут рабочий.
Возможно ли это с помощью docker swarm?
Самое близкое, что вы можете сделать, - это использовать шаблон в определении службы, но это не позволяет вам использовать метки узлов или механизмов. Что вы можете получить из этого {{.Node.Hostname}} который соответствует имени хоста. Эта строка может использоваться в определении переменной среды или при монтировании тома.
Вам либо потребуется, чтобы ваша точка входа проанализировала это значение, чтобы знать, куда указывать на основе этой переменной имени хоста, либо каталог имен хостов в монтировании тома для загрузки данных, специфичных для этого имени хоста. Переменная среды становится проще и гибче по мере того, как вы добавляете больше хостов, но предполагается, что ваше имя хоста включает что-то, что может указывать на то, в каком центре обработки данных вы работаете.
Дополнительные сведения об использовании шаблонов с определением службы см. В документации по созданию службы: https://docs.docker.com/engine/reference/commandline/service_create/#create-services-using-templates
Если бы это был я, я бы, вероятно, выбрал более простую конфигурацию двух отдельных сервисов с похожими конфигурациями, различающимися, возможно, одной переменной среды. Затем используйте ограничение метки узла, чтобы запускать каждую службу только на узлах в одном или другом центре обработки данных. Вы можете использовать якоря / псевдонимы yaml для копирования между службами, например:
version: '3.4'
services:
app-east: &app-service
image: app-image:${app_tag:-latest}
deploy:
replicas: 2
placement:
constraints:
- 'node.labels.region==east'
environment:
DB: 'db-east'
other_var: 'common value'
app-west:
<<: *app-service
deploy:
placement:
constraints:
- 'node.labels.region==west'
environment:
DB: 'db-west'
Я, честно говоря, никогда не использовал якоря и псевдонимы yaml, расположенные на многих уровнях и изменяющие только одну запись массива, поэтому вы можете обнаружить, что вам нужно быть немного более детализированным с их использованием. Тем не менее, конечным результатом вышеизложенного должно быть 4 контейнера, 2 на востоке и еще 2 на западе, с разницей в одну переменную среды БД.