Docker Swarm на VPS: простая оркестрация

Kubernetes мощный, но тяжёлый. Docker Swarm даёт кластер, масштабирование и обновления без простоя — на встроенных средствах Docker, за десять минут настройки.

Swarm против Kubernetes

Swarm — родной режим кластеризации Docker. Он объединяет несколько VPS в единый пул, распределяет контейнеры между ними, следит за их живучестью и умеет катить обновления по одной реплике. При этом синтаксис — тот же знакомый compose, а порог входа в разы ниже, чем у Kubernetes.

Для небольшого и среднего проекта, которому нужна отказоустойчивость на 2-4 серверах, Swarm — рациональный выбор. Несколько VPS MAATRIX в разных локациях (UK, US и RU) дают географическое разнесение узлов.

Ключевые понятия Swarm: manager хранит состояние кластера и принимает решения, worker просто выполняет задачи, service — описание того, что должно работать, а task — конкретный запущенный контейнер этого сервиса. Manager-ноды используют алгоритм консенсуса Raft, поэтому их держат нечётное число: 1, 3 или 5. Три manager переживают падение одного, пять — двух.

Инициализация кластера

На первом сервере (будущий manager) инициализируем Swarm, указав его внешний IP:

docker swarm init --advertise-addr 203.0.113.10

Команда выведет токен и готовую строку для подключения воркеров. На остальных VPS выполняем её:

docker swarm join --token SWMTKN-1-xxxx 203.0.113.10:2377

Проверяем состав кластера с manager-ноды:

docker node ls

Для кластера нужно открыть между узлами порты 2377 (управление), 7946 (обмен состоянием) и 4789 (overlay-сеть).

Деплой сервиса и масштабирование

Запускаем сервис с тремя репликами — Swarm сам разложит их по нодам:

docker service create --name web --replicas 3 -p 80:80 nginx:alpine
docker service ls
docker service ps web

Масштабирование на лету — одна команда:

docker service scale web=6

Если нода отвалится, Swarm перезапустит её реплики на живых узлах. Это и есть отказоустойчивость из коробки.

Важная фишка — встроенный балансировщик (routing mesh). Порт 80 сервиса доступен на любой ноде кластера, даже если конкретная реплика запущена на другой. Запрос попадает на любой узел и автоматически перенаправляется к живому контейнеру. Это снимает необходимость во внешнем балансировщике для простых случаев: достаточно направить DNS на любой из узлов.

Ограничить размещение можно метками и constraints — например, гонять базу только на нодах с быстрым диском:

docker service create --name db \
  --constraint 'node.labels.disk==nvme' \
  --replicas 1 postgres:16-alpine

Стеки через docker stack deploy

Тот же compose-файл (с секцией deploy) разворачивается в кластер одной командой. Пример с rolling-обновлением:

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    deploy:
      replicas: 4
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

docker stack deploy -c stack.yml myapp
docker stack services myapp

При docker service update --image nginx:1.27 myapp_web Swarm обновит реплики по одной с паузой в 10 секунд — пользователи не заметят простоя.

Секреты и частые ошибки

Пароли храните в Swarm secrets, а не в переменных окружения — они шифруются и монтируются в контейнер как файл:

echo "s3cret" | docker secret create db_pass -
docker service update --secret-add db_pass web

• Закрытые порты между нодами — самая частая проблема: узлы не видят друг друга. Откройте 2377/7946/4789 в фаерволе только для IP кластера
• Один manager — при его падении кластер теряет управление. Для продакшена держите 3 manager-ноды
• Локальные тома — они привязаны к ноде; для общих данных нужен внешний том или NFS

Стабильная сеть между узлами тут критична, поэтому NVMe и быстрый канал на VPS MAATRIX помогают Swarm быстро синхронизировать состояние.

Когда проект перерастает Swarm — нужны автоскейлинг по нагрузке, сложные политики сети, операторы — есть смысл смотреть в сторону Kubernetes. Но до этого момента Swarm закрывает реальные потребности небольшой команды без армии DevOps-инженеров и без месяца на изучение манифестов. Начать можно с двух-трёх недорогих VPS и вырасти по мере роста трафика.

Частые вопросы