Docker Swarm: кластер для малих команд

Docker Swarm — вбудований інструмент оркестрації Docker. На відміну від Kubernetes, він значно простіший у налаштуванні та підходить для проєктів із 2-10 серверами.

Ініціалізація кластера

# Manager-нода
docker swarm init --advertise-addr 10.0.0.1

# Worker-нода
docker swarm join --token SWMTKN-1-xxxxx 10.0.0.1:2377

docker node ls

Deploy Stack

# docker-stack.yml
version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
    networks:
      - webnet

  app:
    image: myapp:latest
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
    networks:
      - webnet

networks:
  webnet:
    driver: overlay

docker stack deploy -c docker-stack.yml myapp
docker stack services myapp
docker service ps myapp_web

Secrets

echo "SuperSecretPass" | docker secret create db_password -
docker secret ls

Rolling Update без даунтайму

docker service update --image myapp:v2.0 --update-parallelism 1 --update-delay 15s myapp_app
docker service rollback myapp_app  # відкат

Масштабування

docker service scale myapp_web=5 myapp_app=4

Swarm vs K8s? Swarm — правильний вибір для 2–20 серверів і команд без DevOps. Kubernetes виправданий за 20+ нод.

Часті помилки під час розгортання

Більшість проблем із Docker Swarm зводиться до трьох причин: закриті порти між нодами, нестача ресурсів для реплік і плутанина з правами ноди (manager замість worker). Нижче — типові повідомлення про помилки, які бачить адміністратор у консолі під час першого розгортання, і що за ними насправді стоїть.

Worker не може приєднатися до кластера

Error response from daemon: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp 10.0.0.1:2377: i/o timeout"

Це означає, що між manager і worker не проходить трафік. Swarm використовує три порти: 2377/tcp (керування кластером), 7946/tcp і 7946/udp (обмін станом між нодами) та 4789/udp (overlay-мережа VXLAN). Відкрийте їх у firewall на обох нодах і повторіть docker swarm join.

Команда працює лише на manager-ноді

Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

Команди docker service, docker stack і docker node виконуються лише на manager-нодах. Якщо ви підключилися по SSH до worker і отримали цю помилку — це очікувано, зайдіть на manager-ноду.

Завдання постійно перезапускається

ID          NAME       IMAGE          NODE      DESIRED STATE   CURRENT STATE
abc123      web.1      myapp:latest   node-2    Running         Running 5 seconds ago
xyz789       \_ web.1   myapp:latest   node-2    Shutdown        Failed 2 minutes ago "task: non-zero exit (1)"

Рядок non-zero exit (1) означає, що процес усередині контейнера завершився з помилкою одразу після старту — це проблема застосунку, а не Swarm. Дивіться docker service logs: найчастіше причина в відсутній змінній середовища, недоступній базі даних під час старту або неправильному CMD в образі. Swarm перезапускатиме таке завдання нескінченно, доки причину не усунуть.

Docker Swarm проти альтернатив

Вибір оркестратора зазвичай впирається не в «що краще», а в розмір команди і горизонт росту проєкту. Нижче — порівняння за параметрами, які реально впливають на рішення.

Критерій	Docker Swarm	k3s (Kubernetes)	Nomad
Поріг входу	Низький — достатньо знання Docker Compose	Високий — власний набір понять і YAML	Середній
Мінімум RAM на ноду	512 MB	512 MB	256 MB
Self-healing задач	Є, вбудовано	Є, гнучкіше налаштування	Є
Екосистема готових чартів	Немає	Тисячі Helm-чартів	Обмежена

Коли Docker Swarm не підходить

Swarm чесно вирішує задачі малих і середніх команд, але має свою стелю — ось п'ять ознак того, що пора дивитися в бік Kubernetes.

Потрібні Kubernetes-специфічні ресурси — CRD, Operators, StatefulSet із просунутим керуванням томами.
Кластер має вирости за межі 20–30 нод — Swarm не проєктувався під такі масштаби, а екосистема моніторингу слабша.
Команда вже вміє працювати з Kubernetes і потрібна переносність маніфестів між хмарними провайдерами.
Потрібен вбудований service mesh із mTLS між сервісами «з коробки» — у Swarm це доведеться збирати вручну.
Потрібне автоматичне горизонтальне масштабування за метриками навантаження — у Swarm масштабування лише ручне, через docker service scale.

Перевірка кластера після розгортання

# Усі ноди мають бути Ready і Active
docker node ls

# Усі репліки сервісу у стані Running
docker service ps myapp_web --no-trunc

# HTTP-відповідь через будь-яку ноду — overlay-мережа сама балансує запити
curl -I http://localhost/

# Логи конкретного завдання під час збою
docker service logs myapp_web --tail 50

Якщо у стовпці CURRENT STATE значиться Failed або Rejected — сервіс не піднявся. Дивіться логи завдання і перевіряйте ліміти в deploy.resources.limits: часто причина в тому, що запитаної пам'яті не вистачає на жодній ноді. Готовий кластер варто одразу підключити до моніторингу через Uptime Kuma, щоб бачити падіння реплік, а резервні копії volume-ів налаштувати через rclone.