Архитектура Swarm и границы применения

После модуля вы сможете разложить Docker Swarm на control plane и data plane, объяснить путь от service specification до task и container, определить failure domains лаборатории и обоснованно выбрать Swarm или другой способ запуска контейнеров.

• manager хранит и согласует состояние через Raft
• worker исполняет назначенные tasks
• service задаёт desired state, task является одноразовой единицей работы
• routing mesh и overlay относятся к data plane
• три VM на одном Windows-хосте не дают отказоустойчивость к потере физического хоста

Swarm mode встроен в Docker Engine. Manager принимает API-запрос, проверяет спецификацию и через Raft фиксирует изменение replicated state. Scheduler выбирает узел, dispatcher выдаёт назначение agent этого узла, а локальный Engine создаёт container для task.

Control plane включает managers, Raft log, scheduler, dispatcher и membership. Data plane переносит пользовательский трафик и данные между tasks через overlay networks, service discovery и ingress routing mesh. Исправный data plane не гарантирует доступность операций управления, если потерян manager quorum.

• node — экземпляр Docker Engine в Swarm
• service — декларация образа, replicas, сети, ресурсов и update policy
• task — неизменяемое назначение service конкретному node
• container — локальная реализация task
• stack — группа services, networks, configs и secrets

Service не является контейнером. Его specification описывает желаемое состояние. Orchestrator сравнивает desired state с observed state и создаёт новые tasks при scale, update или отказе. Завершившийся task не перезапускается как тот же объект: Swarm создаёт replacement task с новым ID.

Эта модель требует диагностики на двух уровнях. Сначала проверяют service и историю tasks на manager, затем container, logs и ресурсы на выбранном node. Поиск только через docker ps на одном узле скрывает состояние кластера.

Managers образуют Raft-группу и подтверждают изменения большинством. В кластере из трёх managers quorum равен двум: потеря одного сохраняет управление, потеря двух блокирует изменения control plane. Уже запущенные tasks могут продолжить работу, но reconciliation и административные операции не гарантируются.

Наша лаборатория проверяет отказ VM, Engine и task. Все VM зависят от одного Windows-хоста, одного питания и одной физической сети, поэтому результат нельзя переносить на отказ всего failure domain.

• Swarm подходит, когда нужна встроенная оркестрация Docker с небольшим числом концепций и команд
• Compose подходит одному Engine и не даёт cluster scheduler или manager quorum
• Kubernetes предоставляет более широкую экосистему API и controllers, но требует большей операционной сложности
• критичные stateful workloads требуют отдельно спроектированных replication, backup и fencing
• выбор подтверждают требования к RTO, RPO, масштабу, команде, интеграциям и жизненному циклу платформы

• Выполняйте cluster-команды с manager через alias swarm-manager-1
• Перед изменением фиксируйте node ls, service ls и ожидаемый результат
• Не печатайте join tokens, unlock key или secret material
• Различайте доступность приложения и доступность control plane
• Используйте уникальный префикс swarm-m01 и удаляйте только ресурсы модуля
• Не останавливайте две manager VM одновременно

С рабочей devops-vm соберите membership и локальное представление каждого Engine. Затем создайте три replicas и докажите, что routing mesh принимает запрос на каждом внутреннем адресе независимо от фактического размещения task.

ssh swarm-manager-1 docker info
ssh swarm-manager-1 docker node ls
ssh swarm-manager-1 docker node inspect self --pretty
ssh swarm-manager-2 docker node inspect self --pretty
ssh swarm-manager-3 docker node inspect self --pretty

ssh swarm-manager-1 docker service create --name swarm-m01-web --replicas 3 --publish published=18081,target=80 nginx:1.29-alpine
ssh swarm-manager-1 docker service ps swarm-m01-web
ssh swarm-hyperv-host curl.exe --fail --silent --show-error http://10.77.0.11:18081/
ssh swarm-hyperv-host curl.exe --fail --silent --show-error http://10.77.0.12:18081/
ssh swarm-hyperv-host curl.exe --fail --silent --show-error http://10.77.0.13:18081/
ssh swarm-manager-1 docker service inspect swarm-m01-web --pretty

Ожидаемый результат: три nodes имеют Status Ready, один manager отмечен Leader, остальные Reachable; service достигает 3/3 replicas, а все три HTTP-запроса завершаются успешно.

Если запрос не проходит, не пересоздавайте service сразу. Сначала разделите проблемы quorum, scheduling, task runtime и ingress. Команды ниже сохраняют порядок от cluster state к деталям.

ssh swarm-manager-1 docker node ls
ssh swarm-manager-1 docker service ls
ssh swarm-manager-1 docker service ps swarm-m01-web --no-trunc
ssh swarm-manager-1 docker service inspect swarm-m01-web
ssh swarm-manager-1 docker events --since 10m --until 0s

• node Down или Unreachable указывает на membership или network path
• task Pending требует проверки constraints и reservations
• task Rejected обычно содержит ошибку image, mount, port или runtime
• Running task с ошибкой HTTP требует проверки health, logs, service network и published port
• события дополняют состояние, но не заменяют inspect

• Какие операции прекращаются без manager quorum?
• Почему task нельзя считать перезапущенным контейнером?
• Чем control plane отличается от data plane?
• Почему три VM на одном хосте не являются тремя физическими failure domains?
• Где искать причину Rejected task?
• Когда Compose разумнее Swarm?
• Какие требования могут потребовать Kubernetes?

Модуль освоен, если вы по выводу node/service/task определяете слой проблемы, объясняете reconciliation без привязки к одному контейнеру и формулируете пределы лабораторной отказоустойчивости.

Удалите только тестовый service и убедитесь, что он исчез. Ingress и системные сети Swarm сохраняются.

ssh swarm-manager-1 docker service rm swarm-m01-web
ssh swarm-manager-1 docker service ls
ssh swarm-manager-1 docker network ls