Docker Swarm

Docker Swarm — это встроенный в среду выполнения Docker инструмент для управления кластером контейнеров, реализующий архитектуру оркестрации. Swarm позволяет объединить несколько физических или виртуальных хостов (узлов) с установленным Docker Engine в единую логическую группу, называемую роем (swarm), и управлять развёртыванием, масштабированием и сетевым взаимодействием контейнеров на этом кластере. Режим Swarm был представлен в Docker версии 1.12 (июль 2016 года) и является частью экосистемы Docker, не требуя установки дополнительных сторонних инструментов для базовой оркестрации.

Архитектура и компоненты

Режим Swarm реализует модель управления на основе ролей узлов. Каждый узел в кластере может выполнять одну из двух основных ролей: менеджер (manager) или рабочий (worker).

Узлы-менеджеры (Manager Nodes)

Узлы-менеджеры отвечают за поддержание состояния кластера, принятие решений по планированию задач и обработку запросов от клиента (Docker CLI или API). Они используют распределённый алгоритм консенсуса Raft для согласования состояния кластера между собой. Для обеспечения отказоустойчивости рекомендуется использовать нечётное количество менеджеров (например, 3 или 5). В случае выхода из строя одного из менеджеров, оставшиеся продолжают работу, сохраняя целостность данных. Менеджеры также могут выполнять рабочие задачи, если это не запрещено конфигурацией.

Узлы-рабочие (Worker Nodes)

Рабочие узлы выполняют контейнеры, которые составляют приложение. Они не участвуют в управлении кластером и не принимают решений о планировании. Рабочие узлы получают инструкции от менеджеров и отчитываются о состоянии выполняемых задач. Это позволяет масштабировать вычислительные мощности кластера, добавляя новые рабочие узлы без увеличения нагрузки на механизм консенсуса.

Службы (Services)

Основной единицей развёртывания в Swarm является служба (service). Служба описывает образ контейнера, количество реплик (копий), сетевые настройки, переменные окружения, политики обновления и перезапуска. Swarm гарантирует, что заданное количество реплик службы будет поддерживаться на доступных узлах. Различают два типа служб:

• Реплицированные (replicated) — Swarm запускает указанное количество идентичных контейнеров (реплик) и распределяет их по узлам.
• Глобальные (global) — Swarm запускает ровно один контейнер на каждом доступном узле кластера. Этот тип используется для задач, которые должны выполняться на каждом хосте (например, сборщики логов, агенты мониторинга).

Задачи (Tasks)

Каждая реплика службы представляет собой задачу (task). Задача — это атомарная единица работы, которая соответствует одному контейнеру. Swarm планирует задачи на узлах в соответствии с загрузкой кластера и правилами размещения (constraints). Если контейнер завершает работу с ошибкой, менеджер создаёт новую задачу, чтобы восстановить желаемое количество реплик.

Сеть и балансировка нагрузки

Swarm предоставляет наложенную сеть (overlay network), которая позволяет контейнерам на разных узлах общаться друг с другом, используя виртуальные IP-адреса. Для обеспечения доступа к службам извне используется встроенный балансировщик нагрузки (Ingress load balancing). Каждая служба, опубликовавшая порт, получает этот порт на всех узлах кластера. Запрос, поступающий на любой узел, автоматически перенаправляется на один из контейнеров службы.

Создание и управление кластером

Процесс создания кластера Swarm состоит из двух основных шагов: инициализация первого менеджера и присоединение остальных узлов.

Инициализация

На одном из хостов выполняется команда docker swarm init. В результате создаётся новый кластер, а текущий хост становится первым менеджером. Команда генерирует уникальный токен для присоединения других узлов. По умолчанию для управления кластером используется порт 2377 (TCP), а для наложенной сети — порты 4789 (UDP) и 7946 (TCP/UDP).

Присоединение узлов

Для добавления нового узла в кластер на нём выполняется команда docker swarm join с указанием адреса менеджера и соответствующего токена. Токены бывают двух типов: для присоединения в роли менеджера и для присоединения в роли рабочего. После присоединения узел становится частью кластера и может выполнять задачи.

Развёртывание служб

Для запуска приложения используется команда docker service create. Например: `` docker service create --name web --replicas 3 -p 80:80 nginx:latest ` Эта команда создаёт службу web с тремя репликами на основе образа nginx и публикует порт 80 на всех узлах кластера. Для просмотра состояния служб используется docker service ls, для детальной информации — docker service ps <service_name>`.

Особенности и ограничения

Docker Swarm ориентирован на простоту использования и интеграцию с существующим инструментарием Docker. Он не требует установки отдельного координатора или хранилища состояний (как, например, etcd или ZooKeeper), что снижает порог входа. Однако по сравнению с более сложными системами оркестрации, такими как Kubernetes, Swarm имеет ряд ограничений:

• Ограниченные возможности автомасштабирования — встроенного механизма горизонтального автомасштабирования на основе метрик (CPU, память) в Swarm нет; его можно реализовать только с помощью внешних инструментов.
• Меньшая гибкость конфигурации — Swarm не поддерживает сложные механизмы, такие как пользовательские контроллеры, операторы или расширенные политики сетевой безопасности (Network Policies).
• Ограниченная поддержка хранилищ — управление постоянными томами (persistent volumes) в Swarm менее гибко, чем в Kubernetes, особенно в сценариях с динамическим выделением хранилища.
• Размер кластера — хотя Swarm может управлять кластерами из сотен узлов, на практике его производительность снижается при очень больших размерах (тысячи узлов) по сравнению с Kubernetes.

Применение

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

• разработки и тестирования микросервисных приложений;
• развёртывания небольших и средних производственных сред;
• создания кластеров для непрерывной интеграции и доставки (CI/CD);
• образовательных целей и демонстрации принципов оркестрации.

В российских компаниях Docker Swarm применяется в тех случаях, когда команда уже имеет опыт работы с Docker и не хочет усложнять инфраструктуру внедрением Kubernetes. Однако с ростом популярности Kubernetes и появлением его упрощённых дистрибутивов (например, K3s, MicroK8s) доля Swarm в новых проектах постепенно снижается.

Безопасность

Swarm поддерживает шифрование трафика между узлами по протоколу TLS. При инициализации кластера автоматически создаются сертификаты для аутентификации и шифрования. Каждый узел получает уникальный идентификатор и сертификат, подписанный корневым сертификатом кластера. Все коммуникации между менеджерами и рабочими узлами, а также трафик наложенных сетей, шифруются по умолчанию. Для доступа к управляющему API используется взаимная аутентификация (mTLS).

Сравнение с другими системами

Основным конкурентом Docker Swarm является Kubernetes. В отличие от Kubernetes, который предоставляет огромное количество возможностей и требует значительных усилий для настройки, Swarm предлагает минималистичный подход. Для простых приложений, где не требуется сложное управление состоянием, сетями и хранилищами, Swarm может быть более эффективным решением. Другой альтернативой является Apache Mesos, однако он менее распространён и сложнее в администрировании.

Источники

• Официальная документация Docker: «Swarm mode overview» (docs.docker.com/engine/swarm)
• Документация Docker: «How nodes work» (docs.docker.com/engine/swarm/how-swarm-mode-works/nodes)
• Книга: «Docker in Action» (Jeff Nickoloff, Stephen Kuenzli)
• Статья: «Docker Swarm vs Kubernetes: Which One Should You Choose?» (различные технические блоги, 2017–2023)
• Материалы конференций: DockerCon 2016 — анонс Swarm mode