Docker Swarm: кластер из нескольких VPS без Kubernetes

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

Частые ошибки при развёртывании

Большинство проблем с 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 vs альтернативы

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

Когда 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.