Docker Swarm 1.0: нативная кластеризация без сторонних костылей

Docker Inc. объявили что Swarm 1.0 теперь часть Docker Engine - не отдельная утилита, не экспериментальный плагин, а встроенный механизм кластеризации. Инициализируешь swarm-режим, добавляешь ноды, и docker run начинает работать на кластере почти так же как на одной машине. Это был повод наконец попробовать.

У нас уже был стенд из трёх виртуалок под другие эксперименты. Поставили Docker 1.8, прочитали документацию, выделили несколько часов. Ниже - что получилось, что не получилось и куда это всё ведёт.

Как устроен Swarm

Swarm работает поверх стандартного Docker API. Архитектура простая: один узел становится менеджером (он принимает команды и распределяет задачи), остальные - воркерами. Менеджер может быть несколько для отказоустойчивости, но для нашего теста хватило одного.

Запустить кластер из трёх нод - это буквально:

# получить токен (discovery)
docker run swarm create
# → возвращает токен вида abc123...

# на менеджере
docker run -d -p 2376:2375 swarm manage token://abc123...

# на каждом воркере
docker run -d swarm join --addr=192.168.1.11:2375 token://abc123...

docker -H tcp://localhost:2376 info показывает все три машины и их статус. Это работает. Никаких etcd вручную, никакого flannel, никакой многостраничной документации по настройке кластерного хранилища состояния.

Для сравнения: когда мы разворачивали тестовый Kubernetes на тех же трёх нодах в июле - ушёл день только на то чтобы поднять API-сервер, controller-manager и разобраться с сетью. Swarm поднялся за двадцать минут включая чтение документации.

Деплой: что понравилось

Взяли простое приложение - Django с PostgreSQL и Redis. В Compose-файле уже было описано всё необходимое. С переходом на Swarm особо ничего не менялось: указали через переменные окружения constraints и количество нужных реплик.

# две реплики веб-сервиса на кластере
DOCKER_HOST=tcp://localhost:2376 \
  docker run -d --name web1 \
  -e constraint:node!=db-node \
  registry.internal/myapp:1.2

DOCKER_HOST=tcp://localhost:2376 \
  docker run -d --name web2 \
  -e constraint:node!=db-node \
  registry.internal/myapp:1.2

Swarm сам решил на какие ноды разложить контейнеры. Балансировщик трафика снаружи (nginx) пришлось настраивать отдельно - встроенного ingress у Swarm 1.0 нет. Проверили - работает, контейнеры живут на разных нодах.

Обновление образа: остановить старый контейнер, поднять новый с тегом 1.3. Rolling update не автоматический - делается руками поочерёдно. Для двух реплик терпимо, для десяти - уже скрипт.

Это хорошо. Для многих проектов этого достаточно.

Планировщик: где всё становится скромнее

Вот здесь начинаются вопросы.

Размещение контейнеров. Swarm раскладывает реплики по нодам примитивно: spread (по умолчанию) - просто равномерно по числу контейнеров. Нет учёта реального потребления CPU и памяти в динамике, нет affinity-правил уровня Kubernetes (pod affinity/anti-affinity), нет гибкой политики по типам нод. Можно добавить labels и constraints, но это ручная работа и значительно беднее чем то что умеет Kubernetes Scheduler.

StatefulService - боль. PostgreSQL в нашем тесте жил на конкретной ноде с примонтированным томом. Если нода упадёт - Swarm честно скажет что сервис недоступен, но данные там и остались. Kubernetes решает это через PersistentVolumeClaim и StorageClass; у Swarm этого механизма нет. Для stateless-сервисов всё отлично, для stateful - нужно придумывать самим.

Нет namespaces. На одном кластере нельзя нормально изолировать проект А от проекта Б. Все стеки живут вместе, видят общие сети если захотят. У Kubernetes есть namespaces с RBAC - это принципиальная разница для multi-tenant инфраструктуры.

Мониторинг. docker service ps myapp_web показывает статус задач, но это не мониторинг. Нет встроенного UI, нет метрик планировщика, нет событийного журнала в удобном виде. Для серьёзной эксплуатации нужно добавлять снаружи - Zabbix, который мы уже настраивали под Docker, тут помогает частично.

Для кого это реально подходит

Честный вывод по итогам теста: Swarm хорош там где нужна кластеризация без кардинальной смены парадигмы. Если команда уже работает с Docker и Compose - порог входа минимальный, переход занимает часы, а не недели.

Для наших managed-проектов небольшого масштаба - где два-три stateless-сервиса, не нужна multi-tenancy, и команда небольшая - Swarm выглядит разумным выбором. Он работает, он прост, он не требует выделенного инженера только для обслуживания самого кластера.

Для чего-то сложнее - сложная маршрутизация, stateful-сервисы с нетривиальными требованиями к хранилищу, несколько продуктовых команд на одном кластере - Swarm уже тесноват. Мы с июля приглядываемся к Kubernetes именно для таких случаев, и этот эксперимент со Swarm только укрепил ощущение что К8s решает принципиально другой уровень задачи.

Пока резюме такое: Swarm 1.0 - это хорошо работающий минимализм. Для простых случаев не нужно ничего сложнее. Для сложных - знаешь заранее что придётся смотреть в другую сторону.