Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що таке Docker Swarm?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Docker Swarm** це вбудований у Docker container-оркестратор. Перетворює кілька Docker-host на один кластер: оголошуєш сервіси через `docker service create`, Swarm планує task (container) на node, обробляє рестарти, rolling update і load balancing. ```bash docker swarm init # підняти кластер docker network create -d overlay appnet docker service create --name api --replicas 5 --network appnet myapp docker service ls # сервіси і replica-count ``` **Головне:** Swarm значно простіший за Kubernetes (вбудовано у Docker, єдиний CLI, легко вчити), але переважно покинутий для нових прод-проектів на користь K8s. Бери для малих кластерів, навчання або де K8s overkill.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**Docker Swarm** це нативний, вбудований у Docker cluster-оркестратор. З коробки кожна Docker-інсталяція може стати manager або worker-node у Swarm-кластері, без окремого install, без окремого CLI. Ціна простоти це менша екосистема і повільніший розвиток порівняно з Kubernetes. ## Теорія ### TL;DR - **Swarm** = кластер Docker-host, що працює як один. Вбудовано в Docker engine з 1.12 (2016). - **Архітектура:** менеджери (raft-консенсус, control plane) + workers (крутять container). - **Сервіси:** `docker service create` оголошує бажаний стан (image, replicas, порти, мережа); Swarm планує task (running container), щоб задовольнити. - **Вбудовані фічі:** service discovery (через DNS overlay-мережі), routing mesh (будь-який node може приймати трафік для будь-якого сервісу), rolling update, restart-policy, encrypted overlay-мережі, secret. - **Чесна оцінка у 2026:** Swarm працює і реально простіший за K8s, але нові прод-проекти майже завжди обирають Kubernetes. Бери Swarm для малих кластерів, on-prem або де K8s реально overkill. ### Архітектура ``` +-----------+ +-----------+ +-----------+ | manager 1 | <-> | manager 2 | <-> | manager 3 | (raft) +-----------+ +-----------+ +-----------+ ^ ^ ^ | | | | gossip / control plane | | | +-----------+ +-----------+ +-----------+ | worker A | | worker B | | worker C | | (tasks) | | (tasks) | | (tasks) | +-----------+ +-----------+ +-----------+ ``` - **Менеджери** утворюють raft-кворум. Непарна кількість рекомендована (3, 5, 7) для fault-tolerance. Втратили більшість → кластер не може приймати нові операції. - **Workers** крутять task. Не приймають scheduling-рішення; лише виконують, що менеджери кажуть. - Node може бути одночасно manager і worker (`--availability=active`). Малі кластери часто мають 3 менеджери, що також workers. ### Ключові концепти #### Service Декларативний опис навантаження. Як Kubernetes Deployment. ```bash docker service create \ --name api \ --replicas 5 \ --publish 80:80 \ --network appnet \ --update-parallelism 2 \ --update-delay 10s \ --restart-condition on-failure \ --restart-max-attempts 5 \ myorg/api:1.2.0 ``` #### Task Запущений екземпляр сервісу. Якщо `--replicas 5`, сервіс має 5 task. Кожен task це один container на одному node. Якщо task помирає, Swarm породжує новий. #### Node Машина у кластері. Або manager, або worker (або обидва). Кожен node має labels, які можна таргетувати placement-constraints (`--constraint node.labels.tier==edge`). #### Stack Група сервісів, задеплоєних разом через Compose-файл. `docker stack deploy -c compose.yaml mystack`. ### Налаштування Swarm-кластеру ```bash # На node-1 (буде менеджером) node-1$ docker swarm init --advertise-addr 192.168.1.10 Swarm initialized: current node (xxx) is now a manager. To add a worker, run: docker swarm join --token SWMTKN-... 192.168.1.10:2377 # На node-2 (worker) node-2$ docker swarm join --token SWMTKN-... 192.168.1.10:2377 # Назад на manager node-1$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS xxx node-1 Ready Active Leader yyy node-2 Ready Active ``` Дві команди, і у тебе робочий кластер. Порівняй з `kubeadm init` Kubernetes + CNI install + storage class setup + RBAC tuning. ### Routing mesh і service discovery Коли публікуєш service-порт: ```bash docker service create --name api --publish 80:80 --replicas 3 myapp ``` Swarm створює `ingress`-overlay-мережу, у якій беруть участь усі node. **Будь-який node може приймати трафік на порт 80**, навіть якщо там немає репліки, routing mesh форвардить до здорового task. Сервіси на тій самій overlay-мережі резолвлять одне одного по імені: ```bash # Всередині будь-якого task на appnet $ nslookup api Name: api Address: 10.0.0.5 # віртуальний IP, IPVS-балансовано між реплік ``` Service-ім'я резолвиться у віртуальний IP; kernel IPVS load-balance між здоровими репліками. ### Update і scaling ```bash # Scale docker service scale api=10 # Rolling update docker service update --image myorg/api:1.3.0 api # Поважає --update-parallelism, --update-delay, --update-failure-action # Rollback docker service rollback api ``` Rolling-update first-class: міняй один parallelism-slice за раз, чекай, верифікуй health, продовжуй або автоматично rollback. ### Stacks через Compose ```yaml # stack.yaml services: api: image: myorg/api:1.2.0 deploy: replicas: 3 update_config: parallelism: 1 delay: 10s order: start-first restart_policy: condition: on-failure placement: constraints: [node.role == worker] networks: [appnet] web: image: nginx:1.27-alpine ports: ["80:80"] networks: [appnet] networks: appnet: driver: overlay ``` ```bash docker stack deploy -c stack.yaml mystack docker stack services mystack docker stack ps mystack docker stack rm mystack ``` Stack-формат Swarm переважно сумісний з Compose (з `deploy:` ключами, що поважаються лише у Swarm). ### Чесне порівняння з Kubernetes (2026) | | Swarm | Kubernetes | |---|---|---| | Setup | `docker swarm init` | `kubeadm init` + CNI + storage + ingress | | Learning curve | вихідні | місяці | | Формат manifest | Compose-flavored YAML | k8s YAML (розгорнуто) | | Екосистема | мала, переважно Docker Inc | велика (CNCF, vendor, community) | | Multi-tenant | слабке | сильне (namespace, RBAC, quotas) | | Maintained | так, але feature-frozen | активно розвивається | | Брати сьогодні для | малих кластерів, edge, простоти | майже усього іншого | **Реальність 2026:** більшість прод-команд обирають Kubernetes. Swarm живий, але не дефолт. Cloud-провайдери припинили підкреслювати managed Swarm; managed K8s (EKS, GKE, AKS) усюди. ### Типові помилки **Сприймати Swarm як Compose** Більшість Compose-фіч працюють, але Swarm-специфічні ключі (`deploy.placement`, `deploy.update_config`, `deploy.replicas`) поважаються лише у Swarm. `docker compose up` їх ігнорує. **Запуск з одним менеджером** Один менеджер не має fault-tolerance. Втратив його → кластер unrecoverable. Завжди мінімум 3 менеджери для проду. **Забути, що bind mount не span'ить node** Task, scheduled на node-2, не може читати bind mount з filesystem node-1. Бери volume з networked-driver (NFS, EBS) для stateful-навантажень або пінься task на конкретні node. **Routing mesh ховає source IP** Ingress-mesh DNAT'ить incoming-трафік. Твій застосунок бачить IP Swarm-node, не клієнта. Бери `--publish mode=host`, якщо треба реальні client-IP (жертвує any-node-receiving mesh). ### Реальне застосування - **Малі on-prem кластери:** 5-20 node. Простота Swarm перемагає K8s setup-pain. - **Edge / IoT:** легка оркестрація для малих fleet. - **Low-resource середовища:** Swarm має менший overhead, ніж повний K8s. - **Внутрішні tools, side-проекти:** коли тобі не потрібна глибина K8s. ### Питання для поглиблення **Q:** Чи варто вчити Swarm у 2026? **A:** Як єдиний оркестратор, ні, кар'єрно Kubernetes це домінантний скіл. Як сходинку або для специфічного малого use case, так. Концепти (сервіси, task, декларативний стан, rolling-update) все одно переносяться у K8s. **Q:** Чи можуть Swarm і Kubernetes крутитися на тих самих node? **A:** Технічно так (різні порти, різні namespace), але крихко і maintenance-навантаження. Обери один оркестратор на кластер. **Q:** Яка різниця між Service і Task? **A:** Service це *декларація* («хочу 5 реплік myapp:1.0»). Task це *running-екземпляри*, що задовольняють декларацію. Swarm reconcile'їть: якщо desired state каже 5, а лише 4 крутяться, породжує ще одного. **Q:** Як Swarm обробляє storage? **A:** Локальні volume на node (працюють для stateless або single-node-pinned сервісів), або volume-driver (NFS, REX-Ray, AWS EBS-плагіни) для портативного storage. Реальний прод-storage на Swarm зазвичай external (managed DB, object storage), не локальні volume. **Q:** (Senior) Чому Swarm програв ground Kubernetes, хоч і простіший? **A:** Network effects + екосистема. K8s має Helm, Operators, Istio, Prometheus, Argo, Crossplane, тисячі vendor-інтеграцій. Swarm має базу, добре реалізовану, і зупиняється там. Для складних multi-tenant прод K8s-екосистема розв'язує проблеми, на які Swarm не має відповіді. Swarm перемагає на простоті *якщо* простота це те, що тобі треба; K8s перемагає скрізь інше через mass-adoption. ## Приклади ### Bootstrap 3-node Swarm ```bash # Manager + 2 workers node-1$ docker swarm init --advertise-addr 192.168.1.10 # (зверни увагу на join-токен з output) node-2$ docker swarm join --token SWMTKN-... 192.168.1.10:2377 node-3$ docker swarm join --token SWMTKN-... 192.168.1.10:2377 node-1$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS xxx node-1 Ready Active Leader yyy node-2 Ready Active zzz node-3 Ready Active ``` ### Деплой сервісу через кластер ```bash node-1$ docker network create -d overlay appnet node-1$ docker service create \ --name api \ --replicas 6 \ --network appnet \ --publish 80:80 \ --update-parallelism 2 \ --update-delay 10s \ --restart-condition on-failure \ myorg/api:1.0 node-1$ docker service ps api # 6 task розподілено між node-1, node-2, node-3 # Усі доступні на порту 80 будь-якого node через routing mesh ``` ### Stack з Compose-style файлу ```bash node-1$ docker stack deploy -c stack.yaml mystack Creating network mystack_appnet Creating service mystack_api Creating service mystack_web node-1$ docker stack services mystack ID NAME REPLICAS IMAGE ... mystack_api 3/3 myorg/api:1.2.0 ... mystack_web 1/1 nginx:1.27-alpine ``` Один файл, одна команда, multi-host деплой. Простота, яку люблять Swarm-фани.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.