Що таке Docker Swarm?

docs.questions.sections.docker~5 хв читання

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-фани.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Коментарі

Ще немає коментарів