Отказоустойчивость на Docker Swarm: настройка кластера, реплик и restart policies

Почему Docker Swarm для отказоустойчивости: преимущества и ограничения

Docker Swarm - встроенный режим оркестрации контейнеров, доступный в Docker Engine без установки дополнительных компонентов. Он решает задачу отказоустойчивости через три ключевых механизма: автоматическое распределение реплик по узлам, восстановление упавших контейнеров по restart policies и бесшовное обновление сервисов через rolling updates. В отличие от Kubernetes, Swarm не требует развёртывания etcd, настройки API-сервера или изучения десятков абстракций. Кластер поднимается одной командой.

Главное преимущество Swarm - низкий порог входа при сохранении надёжности для компактных и средних инфраструктур. Вы получаете отказоустойчивый управляющий слой на Raft-консенсусе, встроенную балансировку нагрузки через mesh-маршрутизацию и автоматическое перераспределение задач при отказе узла. Ограничения тоже есть: отсутствует встроенное автомасштабирование, сообщество и экосистема инструментов уступают Kubernetes, а мониторинг требует подключения внешних систем. Для проектов, где важна простота эксплуатации и предсказуемость поведения, Swarm остаётся рабочим выбором в 2026 году. Подробное сравнение оркестраторов и базовые операции описаны в практическом руководстве по Docker Swarm.

Цель этой статьи - дать готовые рецепты для типовых сценариев: от планирования кластера до симуляции отказов и проверки восстановления. Все команды проверены на Ubuntu Server 22.04 LTS и Docker Engine 26+.

Планирование отказоустойчивого кластера

Правильное проектирование до ввода первой команды экономит часы отладки. Три аспекта критичны: сеть, количество manager-узлов и синхронизация времени.

Требования к узлам и сети

Для работы Swarm необходимы открытые порты между всеми узлами кластера:

2377 TCP - управляющий трафик, команды docker swarm join и docker service create.
7946 TCP/UDP - обнаружение узлов и gossip-протокол для распространения состояния кластера.
4789 UDP - трафик overlay-сети между контейнерами на разных узлах.

Используйте статические IP-адреса или DNS-имена, которые разрешаются на всех узлах. Динамические адреса от DHCP приводят к рассинхронизации членов кластера после перезагрузки. Синхронизация времени через NTP обязательна: расхождение часов более чем на 50 миллисекунд вызывает ошибки в Raft-логе и может привести к потере кворума. Настройте chrony или systemd-timesyncd на каждом узле до инициализации кластера.

Рекомендую выделить отдельный сетевой интерфейс для трафика Swarm, особенно если узлы одновременно обслуживают клиентские запросы. Это изолирует управляющий и overlay-трафик от пользовательской нагрузки и исключает деградацию кластера при пиковых нагрузках на приложение.

Выбор количества manager-узлов

Manager-узлы хранят состояние кластера в Raft-логе и принимают решения о планировании задач. Raft требует нечётного количества участников для выбора лидера и достижения консенсуса. Допустимое количество одновременных отказов вычисляется по формуле (N-1)/2, где N - число manager-узлов.

Manager-узлов	Допустимо отказов	Рекомендация
1	0	Только для разработки
3	1	Минимум для production
5	2	Крупные кластеры
7	3	Максимум, не рекомендуется

Для большинства production-сред оптимальны три manager-узла. Это даёт запас в один отказ без потери управляемости. Пять узлов увеличивают накладные расходы на репликацию Raft-лога и оправданы при географически распределённых кластерах. Семь и более manager-узлов Docker официально не рекомендует: время достижения консенсуса растёт, а отказоустойчивость не улучшается пропорционально.

Worker-узлы выполняют только задачи сервисов и не участвуют в управлении. Их количество ограничено только ресурсами. Manager-узлы по умолчанию тоже выполняют задачи. Для критичных сред переведите manager-узлы в режим drain, чтобы они занимались только управлением.

Инициализация кластера и добавление узлов

Настройка первого manager-узла

На первом узле выполните инициализацию с явным указанием IP-адреса, который будет использоваться для коммуникации между узлами:

docker swarm init --advertise-addr 192.168.1.10

Флаг --advertise-addr критичен при наличии нескольких сетевых интерфейсов. Без него Docker может выбрать неправильный интерфейс, и другие узлы не смогут подключиться. После выполнения команда выводит два токена: для добавления worker-узлов и manager-узлов. Сохраните их в защищённом месте. При утере токена worker-узла его можно получить повторно:

docker swarm join-token worker

Для manager-токена команда аналогична: docker swarm join-token manager. Ротация токенов выполняется через docker swarm join-token --rotate, если токен скомпрометирован.

Добавление дополнительных manager-узлов

На втором и третьем узлах выполните команду присоединения с manager-токеном:

docker swarm join --token SWMTKN-1-... 192.168.1.10:2377

Добавляйте manager-узлы последовательно, проверяя состояние после каждого. Команда docker node ls на любом manager-узле показывает список всех членов кластера. Все manager-узлы должны иметь статус Reachable. Статус Leader будет только у одного - текущего лидера Raft.

Для перевода manager-узла в режим только управления выполните:

docker node update --availability drain manager-1

Все запущенные на этом узле задачи будут перепланированы на другие доступные узлы. Режим drain также используется при обслуживании: перед обновлением Docker Engine или перезагрузкой узла.

Развертывание отказоустойчивых сервисов с репликами

Сервис в Swarm - это описание желаемого состояния: какой образ использовать, сколько реплик запустить, на каких портах принимать трафик. Swarm постоянно сверяет фактическое состояние с желаемым и устраняет расхождения.

Управление размещением реплик (placement constraints)

По умолчанию Swarm распределяет реплики равномерно по всем доступным узлам. Этого достаточно для базовой отказоустойчивости. Для более тонкого контроля используйте ограничения размещения:

docker service create \
  --name api \
  --replicas 3 \
  --constraint node.role==worker \
  --publish 8080:80 \
  nginx:alpine

Ограничение node.role==worker гарантирует, что реплики запускаются только на worker-узлах. Это освобождает manager-узлы от пользовательской нагрузки. Другие полезные ограничения: node.labels.ssd==true для сервисов, чувствительных к скорости диска, или node.labels.region==us-east для географического разделения.

Метки на узлы добавляются командой:

docker node update --label-add ssd=true worker-1

Балансировка нагрузки между репликами

Swarm использует встроенную mesh-маршрутизацию. Когда вы публикуете порт сервиса через --publish, каждый узел кластера начинает слушать этот порт. Запрос, пришедший на любой узел, перенаправляется на одну из доступных реплик. Балансировка работает на уровне L4 (TCP/UDP) по алгоритму round-robin.

Это означает, что отказ узла, на котором физически запущена реплика, не прерывает обслуживание: запросы автоматически уходят на оставшиеся реплики через другие узлы. Время восстановления - несколько секунд, пока Swarm обнаружит отказ и перепланирует потерянные реплики.

Ограничение mesh-маршрутизации - отсутствие sticky sessions и балансировки на уровне HTTP (L7). Для приложений, которым нужна привязка сессии к конкретной реплике, разместите перед Swarm внешний балансировщик: Nginx или HAProxy. Настройка сетевого взаимодействия контейнеров детально разобрана в руководстве по сетевым драйверам Docker.

Масштабирование сервиса выполняется одной командой:

docker service scale web=5

Проверка распределения реплик:

docker service ps web

Настройка restart policies для автоматического восстановления

Restart policies в Swarm-сервисах отличаются от политик в docker run. В сервисах политика применяется всегда - контейнер перезапускается либо на том же узле, либо на другом, если исходный узел недоступен.

Политика any (всегда) и её поведение

Политика по умолчанию - any. Контейнер перезапускается при любом коде завершения, включая успешный (код 0). Это подходит для долгоживущих сервисов: веб-серверов, API, воркеров очередей. Но есть риск маскировки проблем: контейнер с ошибкой в коде будет бесконечно перезапускаться, а вы не получите явного сигнала о деградации.

Отслеживайте частые перезапуски через docker service ps <service>. Колонка ERROR покажет сообщения о сбоях. Настройте алертинг на аномальное количество перезапусков через внешнюю систему мониторинга.

Политика on-failure с ограничением попыток

Для задач, которые должны завершаться успешно, используйте on-failure с ограничением попыток:

docker service create \
  --name batch-job \
  --restart-condition on-failure \
  --restart-max-attempts 3 \
  --restart-window 60s \
  my-batch-image

Параметр --restart-max-attempts 3 ограничивает количество перезапусков. --restart-window 60s задаёт окно, в течение которого считаются попытки. Если после трёх неудачных попыток за 60 секунд контейнер снова падает, Swarm оставляет его в состоянии failed. Это предотвращает бесконечный цикл перезапусков и позволяет диагностировать проблему по логам.

Политика none отключает автоматический перезапуск. Используйте её для отладки или для контейнеров, которые выполняют однократную задачу и должны завершиться.

Бесшовное обновление сервисов (rolling updates)

Rolling update заменяет реплики сервиса на новую версию последовательно, группами. Пока одна группа обновляется, остальные продолжают обслуживать запросы. Нулевое время простоя достигается правильной настройкой параметров обновления.

Настройка параметров обновления для минимизации рисков

Для критичных production-сервисов рекомендуется консервативная стратегия:

docker service update \
  --update-parallelism 1 \
  --update-delay 10s \
  --update-order start-first \
  --image nginx:1.27 \
  web

--update-parallelism 1 означает, что одновременно обновляется только одна реплика. --update-delay 10s даёт новой реплике время на инициализацию и прогрев перед заменой следующей. --update-order start-first сначала запускает новую реплику и только после её готовности останавливает старую - это сохраняет общую ёмкость сервиса во время обновления.

Healthcheck в образе или сервисе критичен для rolling updates. Swarm проверяет готовность новой реплики перед продолжением обновления. Без healthcheck контейнер считается готовым сразу после запуска, что может привести к ошибкам, если приложение стартует дольше нескольких секунд.

Автоматический откат при неудачном обновлении

Настройте автоматический откат для защиты от неудачных деплоев:

docker service create \
  --name web \
  --replicas 3 \
  --update-failure-action rollback \
  --update-max-failure-ratio 0.3 \
  --update-monitor 30s \
  nginx:1.27

--update-failure-action rollback приказывает Swarm автоматически вернуться к предыдущей версии при сбое обновления. Сбой определяется по двум условиям: ошибка запуска контейнера или провал healthcheck в течение --update-monitor (здесь 30 секунд). --update-max-failure-ratio 0.3 допускает сбой не более 30% реплик - если порог превышен, запускается откат.

Ручной откат выполняется командой:

docker service rollback web

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

Отказоустойчивость данных: volumes и внешние хранилища

Локальные Docker-тома привязаны к узлу, на котором созданы. При миграции контейнера на другой узел данные остаются на старом. Для stateful-сервисов это неприемлемо. Решение - общее сетевое хранилище, доступное со всех узлов кластера.

Настройка NFS-тома для Docker Swarm

NFS - простой и надёжный способ обеспечить общий доступ к данным. Настройте NFS-сервер, экспортируйте директорию, затем создайте Docker-том с драйвером local и опциями NFS:

docker volume create \
  --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.1.100,rw,nfsvers=4 \
  --opt device=:/exported/path \
  nfs-shared

Монтирование тома в сервис:

docker service create \
  --name db \
  --mount type=volume,source=nfs-shared,target=/var/lib/data \
  postgres:16

Все реплики сервиса получат доступ к одним и тем же данным через NFS. Учитывайте, что NFS добавляет сетевую задержку и не подходит для приложений с интенсивной записью. Для высоконагруженных баз данных рассмотрите распределённые драйверы томов или облачные блочные хранилища. Детальный разбор подходов к хранению данных в кластерах - в статье про управление постоянными данными в Docker Swarm и Kubernetes.

Проверка отказоустойчивости: симуляция сбоев

Настроенный кластер необходимо протестировать на реальных отказах. Только симуляция сбоев подтверждает, что механизмы восстановления работают как ожидается.

Тестирование отказа worker-узла

Остановите Docker на одном из worker-узлов:

systemctl stop docker

На manager-узле наблюдайте за состоянием сервиса:

watch docker service ps web

В течение 10-15 секунд реплики, работавшие на отказавшем узле, получат статус Shutdown, и Swarm запустит новые реплики на оставшихся доступных узлах. Сервис продолжит отвечать на запросы - mesh-маршрутизация направит трафик на живые реплики.

Тестирование отказа manager-узла

Остановите Docker на одном manager-узле из трёх. На оставшихся manager-узлах выполните:

docker node ls

Отказавший узел будет показан со статусом Down. Оставшиеся два manager-узла продолжат обслуживать кластер: принимать команды, планировать задачи, отвечать на API-запросы. Кворум сохраняется, так как большинство (2 из 3) узлов доступны.

При остановке второго manager-узла кластер потеряет кворум и перестанет принимать изменения. Существующие сервисы продолжат работать, но вы не сможете создать новый сервис или масштабировать существующий, пока кворум не восстановится. Это штатное поведение Raft-консенсуса, защищающее от split-brain.

Мониторинг и обслуживание кластера

Повседневный контроль кластера опирается на три команды:

docker node ls - состояние узлов, их доступность и роль.
docker service ls - список сервисов с количеством реплик.
docker service ps <service> - детальный статус каждой реплики сервиса.

Для production-сред подключите внешний мониторинг. Связка Prometheus + Grafana с экспортёром cAdvisor даёт метрики по каждому контейнеру: потребление CPU, памяти, сетевой трафик. Настройте алерты на падение реплик ниже заданного порога, аномальное количество перезапусков и потерю узлов. Готовые конфигурации для интеграции мониторинга описаны в руководстве по автомасштабированию Docker Swarm.

Обновление Docker Engine на узлах кластера выполняйте поочерёдно. Переведите узел в drain, дождитесь перепланирования задач, обновите Docker, верните узел в active. Повторите для каждого узла. Такой подход исключает простой сервисов и сохраняет кворум manager-узлов.

Ротацию логов настраивайте через параметры демона Docker в /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Это предотвращает заполнение диска логами контейнеров. Для централизованного сбора логов рассмотрите связку Loki + Grafana, которая нативно интегрируется с Docker и не требует агентов на каждом контейнере.