Архітектура 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
• events доповнюють стан, але не замінюють 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