swarm

Docker Swarm

TL;DR: Docker Swarm превращает группу хостов Docker в единый виртуальный движок с оркестрацией, service discovery и балансировкой нагрузки из коробки.

Архитектура

Роли узлов (Node Roles)

В кластере есть два типа нод:

Managers (Управляющие) — мозг кластера:

• Orchestration: Распределение задач (контейнеров) по нодам.
• Cluster State: Хранение конфигурации кластера и секретов.
• Dispatching: Отправка команд воркерам.

Менеджеры используют алгоритм Raft Consensus для синхронизации данных. Среди менеджеров всегда есть один Leader, который принимает записи. Остальные — Followers.

Workers (Рабочие) — мускулы кластера:

• Получать задачи (Tasks) от менеджеров.
• Запускать контейнеры.
• Сообщать статус обратно (Running, Failed).

По умолчанию менеджеры также являются воркерами (могут запускать контейнеры), но в продакшене их часто изолируют (Drain mode).

Кворум и отказоустойчивость

Для работы кластера требуется кворум — согласие большинства менеджеров. Формула: (N / 2) + 1.

Всего менеджеров	Кворум	Допустимые падения
1	1	0
3	2	1
5	3	2
7	4	3

Почему нечётное число? Добавление 4-го менеджера не увеличивает отказоустойчивость (всё ещё можно потерять только 1), но увеличивает нагрузку на сеть при репликации данных.

Жизненный цикл сервиса

1. Вы отправляете команду docker service create.
2. API передаёт запрос Лидеру.
3. Orchestrator создаёт объект Service.
4. Scheduler разбивает сервис на Tasks (задачи/реплики).
5. Allocator выдаёт IP-адреса задачам.
6. Dispatcher назначает задачи конкретным нодам.
7. Воркер получает задачу и запускает контейнер.

Сетевая модель

Overlay Network

Виртуальная сеть (L2 over L3), построенная поверх физической сети хостов.

• Использует технологию VXLAN.
• Может быть зашифрована (IPSec) опцией --opt encrypted.
• Контейнеры видят друг друга по внутренним IP, независимо от того, на каком хосте они запущены.

Service Discovery и DNS

В Swarm встроен свой DNS-сервер (127.0.0.11).

Когда контейнер frontend обращается к backend:

1. DNS-запрос backend → Swarm возвращает Virtual IP (VIP) сервиса.
2. Ядро Linux (через IPVS) перехватывает пакеты на VIP и балансирует между реальными IP контейнеров.

Это VIP-based load balancing.

Ingress Routing Mesh

Позволяет опубликовать порт на весь кластер.

• Порт 80 открывается на всех нодах кластера.
• Запрос на Node-1:80 перенаправляется на нужный контейнер, даже если он на Node-3.
• Это обеспечивает отказоустойчивость: балансировщик нагрузки можно направить на любые ноды.

Режимы запуска сервисов

Replicated (по умолчанию)

Вы говорите «Хочу 3 копии», и Swarm сам решает, где их разместить.

• Команда: --replicas 3
• Сценарии: Веб-серверы, API, Worker-процессы.
• Поведение: Если нода падает, Swarm перезапускает недостающие копии на живых нодах.

Global

Режим «Один на каждой ноде». Ровно одна копия на каждом узле кластера.

• Команда: --mode global
• Сценарии: Агенты мониторинга (Node Exporter, cAdvisor), сборщики логов (Fluentd, Filebeat), сетевые прокси.
• Поведение: При добавлении новой ноды глобальный сервис автоматически запускается на ней.

Связанные материалы

• Практика: deploy-stack — развёртывание стеков
• Рецепт: 06-swarm-cluster — создание кластера на Vagrant
• Справка: swarm-cheatsheet — команды Swarm CLI

Подводные камни

Заблуждение	Реальность
«Swarm устарел — нужен только K8s»	Swarm проще, встроен в Docker, идеален для малых команд (до ~50 нод)
«3 менеджера = отказоустойчивость»	При потере 2 из 3 менеджеров — кворум потерян, кластер read-only
«Overlay сеть медленная»	VXLAN overhead ~5%. Bottleneck обычно в приложении, не в сети
«Swarm балансирует равномерно»	Ingress Routing Mesh — round-robin. Для sticky sessions нужен внешний LB