Какие плюсы и минусы Docker Swarm?

Плюсы и минусы Docker Swarm

Docker Swarm — это встроенный оркестратор контейнеров от Docker. Сравню его с Kubernetes и расскажу, когда его использовать на production.

Что такое Docker Swarm

Docker Swarm — это native кластеризация для Docker:

# Инициализируем Swarm
docker swarm init
# Результат: текущий ноде становится Manager

# Присоединяем рабочие ноды
docker swarm join-token worker
# На другой машине:
docker swarm join --token <token> <manager-ip>:2377

# Развёртываем сервис
docker service create --name web --replicas 3 nginx:latest

# Результат: 3 контейнера распределены по нодам автоматически

ПЛЮСЫ Docker Swarm

1. Простота использования и установки

# Kubernetes требует куча компонентов:
# - kubeadm init
# - CNI плагины
# - control-plane компоненты (etcd, scheduler, API server)
# - worker components (kubelet, kube-proxy)
# - 100+ строк конфига минимум

# Docker Swarm: просто `docker swarm init` и всё готово!
# Один команда vs час настройки

Минимальная инфраструктура:

# На MacBook с Docker Desktop
$ docker swarm init
Swarm initialized: current node is a manager

$ docker service create nginx
# Работает сразу

2. Интегрирован в Docker

# Вся экосистема Docker работает из коробки
$ docker ps         # видны локальные контейнеры
$ docker service ls # видны сервисы
$ docker node ls    # видны ноды
$ docker stack deploy # развёртывание через docker-compose.yml

# Нет необходимости учить:
# - kubectl синтаксис
# - YAML с 20 параметрами
# - Helm charts
# - etcd

3. Низкие требования к ресурсам

# Kubernetes master требует:
# - 2+ ядер CPU
# - 2GB+ RAM
# - Для production: 4 ядра, 8GB RAM

# Docker Swarm master требует:
# - Честно говоря, минимум 512MB RAM
# - Работает даже на Raspberry Pi!

# Для небольших команд / стартапов это очень важно

4. Встроенное шифрование сети

# Автоматическое шифрование между нодами
$ docker service create --network overlay nginx
# Сеть автоматически зашифрована

# Kubernetes требует дополнительной настройки (Calico, Weave)

5. Простой и работающий load balancing

# Ingress load balancing встроен
$ docker service create --publish 8080:80 nginx

# Автоматически:
# - Балансирует трафик
# - Работает на любой ноде
# - Есть health checks

# Kubernetes требует отдельного Ingress controller

6. Docker Stack — как docker-compose для production

# docker-compose.yml (развёртывается в продакшене!)
version: '3.8'

services:
  web:
    image: myapp:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
    ports:
      - "80:8080"
    environment:
      DB_HOST: db

  db:
    image: postgres:latest
    deploy:
      placement:
        constraints: [node.role == manager]
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

networks:
  default:
    driver: overlay

$ docker stack deploy -c docker-compose.yml myapp
# Всё развёрнуто одной командой!

МИНУСЫ Docker Swarm

1. Ограниченные возможности оркестрации

# Kubernetes позволяет:
kind: Deployment
spec:
  selector:
    matchLabels:
      app: web
      version: v1  # Сложный selector
  affinity:
    podAntiAffinity:  # Не разворачивай на одной ноде
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values: [web]
          topologyKey: kubernetes.io/hostname

# Docker Swarm:
docker service create \
  --constraint node.id==<node-id> \
  nginx  # Только базовые ограничения

2. Нет ecosystem

# Kubernetes ecosystem:
# - 1000+ Helm charts
# - Prometheus, Grafana, ELK интегрированы
# - GitOps инструменты (ArgoCD, Flux)
# - Service meshes (Istio, Linkerd)
# - Operators для управления сложными системами

# Docker Swarm ecosystem:
# - Сотня инструментов
# - Мало интеграций
# - Сложнее настроить мониторинг

3. Плохая поддержка stateful приложений

# Kubernetes:
apiVersion: v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  template:
    spec:
      containers:
      - name: mysql
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

# Docker Swarm:
docker service create \
  --mount type=volume,source=mysql-data,target=/var/lib/mysql \
  mysql
# Если ноде упадёт, данные потеряны!

4. Отсутствие auto-scaling

# Kubernetes:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

# Docker Swarm:
docker service create nginx  # Вручную масштабируй
docker service scale nginx=5  # Когда узнаешь про нагрузку

5. Нет Helm

# Kubernetes: Helm charts переиспользуемы
helm repo add stable https://charts.helm.sh/stable
helm install mysql stable/mysql --values values.yaml

# Docker Swarm: создавай свои стеки для каждого проекта
# Переиспользование минимально

6. Сложность с networking

# Kubernetes DNS работает идеально
# curl web  # Находит сервис
# curl web.default.svc.cluster.local  # Полный путь

# Docker Swarm DNS работает, но с потенциальными проблемами
# Особенно при добавлении/удалении нод

7. Версионирование образов в Swarm

# Kubernetes:
kubectl set image deployment/web web=myapp:v2
kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web --to-revision=1

# Docker Swarm:
docker service update --image myapp:v2 web
# Нет истории, нет простого rollback

8. Проблемы с лидерством (consensus)

# Docker Swarm использует Raft для consensus
# Проблема: при split-brain сценарии может быть потеря данных

# Если 3 manager ноды и сетка разделилась:
# - 2 ноды на одной стороне
# - 1 ноде на другой
# → 1 нода потеряет контроль (хорошо)

# Но отладка этого сложна

Сравнение: Docker Swarm vs Kubernetes

Когда использовать Docker Swarm

✅ ДА — Swarm подходит для:

1. Стартапы с 1-3 разработчиками
2. Микросервисы < 50 контейнеров
3. Simple stateless приложения
4. Прототипирование
5. Internal tools
6. Когда нужна простота
7. On-premises инфраструктура

❌ НЕТ — Используй Kubernetes для:

1. Production системы с 1М+ пользователей
2. Критичные требования к reliability
3. Сложная сетевая топология
4. Stateful приложения (БД, кэши)
5. Auto-scaling
6. GitOps workflows
7. Multi-cloud
8. Когда есть DevOps инженер в команде

Реальный пример: когда выбрать Swarm

Сценарий: B2B SaaS с 10 разработчиками, $100k/месяц revenue

Вариант 1: Docker Swarm
- 3 ноды (1 manager + 2 worker)
- Cost: $300/месяц (DigitalOcean $12 за ноду)
- Setup: 30 минут
- Scaling: вручную
- Reliability: 99.9% (хватает)

Вариант 2: Kubernetes
- Managed K8s: $70/месяц (минимум) + ноды $300
- Setup: 2 часа
- Scaling: автоматический
- Reliability: 99.99%
- Требует DevOps инженера

Для этого сценария Swarm лучше: простоты, дешевле, faster time to market

Итог

Docker Swarm = простота и скорость для мелких/средних проектов

Kubernetes = мощь и гибкость для больших enterprise систем

Вы не ошибетесь, выбрав Docker Swarm для первой версии. Когда понадобится больше возможностей — миграция на K8s возможна (есть несколько успешных примеров).