От Compose к оркестрации

Где заканчиваются возможности одного хоста с Compose и зачем существует оркестрация контейнеров.

Оркестрация контейнеров — управление контейнерами на множестве машин как единым целым: планирование, масштабирование, самовосстановление и обновления без простоя.

Docker Compose — отличный инструмент, но у него есть жёсткая граница: он управляет контейнерами на одном хосте. Пока проект помещается на одну машину, этого хватает с запасом. Но в какой-то момент одного сервера становится мало — и тогда нужен инструмент, который раскидывает контейнеры по кластеру машин. Этот урок — мостик: где проходит граница Compose, что предлагает Docker Swarm и зачем вообще придумали Kubernetes. Без погружения в сам k8s — только чтобы вы понимали, куда ведёт дорога.

Зачем это на практике

Понимать границу Compose важно, чтобы не упереться в неё внезапно в проде. Если вы заранее знаете, что одного хоста хватит — Compose проще и дешевле, и городить кластер не нужно. Если же закладываете рост, отказоустойчивость и нагрузку — лучше заранее видеть, какой инструмент оркестрации вас ждёт и почему.

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

Compose и один сервер упираются в несколько потолков:

• Единая точка отказа. Упал хост — упало всё. Нет другой машины, куда переехать.
• Потолок ресурсов. CPU и память ограничены одной машиной; вертикальное масштабирование («сервер побольше») быстро дорожает и тоже имеет предел.
• Нет самовосстановления между машинами. Compose перезапустит упавший контейнер на том же хосте (restart: always), но если хост недоступен — переносить контейнер некуда.
• Деплой с простоем. docker compose up с новым образом обычно пересоздаёт контейнер — есть момент, когда сервис недоступен.
• Ручное горизонтальное масштабирование. Распределять нагрузку между несколькими серверами Compose сам не умеет.

Compose в небольшом проде — это нормально

Важно не впадать в другую крайность: для маленького проекта Compose в проде — совершенно рабочий выбор. Один VPS, несколько сервисов, разумные ожидания по доступности — и не нужно ничего тяжелее.

services:
  web:
    image: ghcr.io/acme/api:1.4.2
    restart: always
    ports:
      - "80:8000"
    depends_on:
      - db
  db:
    image: postgres:16
    restart: always
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data:

Ключевые приёмы «прод-Compose»: restart: always для автоперезапуска, иммутабельный тег образа (а не latest), именованные тома для данных, ограничения ресурсов и healthcheck. Этого достаточно для пет-проекта, внутреннего сервиса или раннего стартапа. Усложнять стоит, только когда появляется реальная потребность в нескольких машинах.

Docker Swarm — оркестрация «по-докеровски»

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

# Инициализировать кластер (на первой ноде — менеджере)
docker swarm init

# Добавить рабочую ноду (команду печатает swarm init)
docker swarm join --token SWMTKN-... 10.0.0.1:2377

# Развернуть сервис в 3 реплики по кластеру
docker service create --name api --replicas 3 -p 80:8000 ghcr.io/acme/api:1.4.2

# Отмасштабировать на лету
docker service scale api=5

Swarm даёт то, чего нет у Compose: несколько нод, реплики сервиса, базовое самовосстановление (упала нода — реплики поднимаются на других) и rolling-обновления без полного простоя. Это разумный шаг для команд, которым нужна отказоустойчивость, но не нужна вся сложность Kubernetes. Минус — экосистема и активность развития заметно скромнее, чем у k8s.

Зачем нужен Kubernetes

Kubernetes (k8s) — индустриальный стандарт оркестрации для серьёзных нагрузок. Он решает те же задачи, что и Swarm, но гораздо глубже и гибче, ценой высокой сложности. Идею k8s удобно ухватить через сравнение, не уходя в детали.

Что принципиально добавляет Kubernetes: декларативность (вы описываете желаемое состояние — «хочу 3 реплики этого образа», а контроллер сам приводит кластер к нему и удерживает), автоматическое масштабирование по метрикам, продвинутые стратегии обновлений и откатов, богатую модель сети и хранилища, огромную экосистему. Платить за это приходится сложностью: понятия Pod, Deployment, Service, Ingress, манифесты, операторы — отдельный большой мир.

Хорошая новость: Dockerfile и образ остаются теми же. И Swarm, и Kubernetes запускают ровно те образы, что вы собрали и положили в реестр в прошлых уроках. Меняется не образ, а способ им управлять. Поэтому переход на оркестрацию — это не «переписать всё заново», а «научиться новому слою управления поверх знакомых контейнеров».

Как это работает под капотом

В основе любой оркестрации лежит цикл сверки (reconciliation loop). Вы задаёте желаемое состояние — например, «3 реплики сервиса api». Управляющий компонент (менеджер Swarm или control plane Kubernetes) постоянно сравнивает желаемое с фактическим и устраняет разницу: реплик меньше трёх — запускает новые, нода умерла — переносит её контейнеры на живые, образ обновился — выкатывает по одному, удерживая сервис доступным. Планировщик (scheduler) решает, на какую ноду поставить контейнер, исходя из свободных ресурсов и ограничений. Сеть кластера даёт каждому сервису стабильное имя и распределяет трафик по репликам. Именно эта непрерывная автоматическая сверка и отличает оркестратор от Compose, где состояние меняется только вашими ручными командами.

Частые ошибки

• Kubernetes «на всякий случай». Для пет-проекта k8s — это огромный оверхед. Не нужен рост — оставайтесь на Compose.
• Деплой через latest в Compose-проде. Те же проблемы воспроизводимости, что и везде. Иммутабельный тег.
• Игнорировать единую точку отказа. Если для бизнеса критична доступность, один хост с Compose — риск. Тогда нужна оркестрация.
• Думать, что переход = переписать образы. Образ и Dockerfile не меняются; добавляется слой оркестрации поверх.
• Прыгать сразу в k8s, минуя осмысление. Для умеренной отказоустойчивости Swarm проще и быстрее даёт результат.

Итоги

• Compose ограничен одним хостом: единая точка отказа, потолок ресурсов, деплой с простоем.
• Для небольшого проекта Compose в проде — нормально: restart: always, иммутабельные теги, тома, healthcheck.
• Docker Swarm — лёгкая встроенная оркестрация: кластер, реплики, базовое самовосстановление, rolling-обновления.
• Kubernetes — индустриальный стандарт: декларативность, автомасштабирование, развитые обновления — ценой сложности.
• Образ и Dockerfile при переходе не меняются; добавляется слой управления, в основе которого — цикл сверки желаемого и фактического состояния.