Як реалізувати масштабування сервісів у Docker Compose?

docs.questions.sections.docker~4 хв читання

Масштабування сервісів у Docker Compose крутить кілька container одного сервісу на одному host. Реально корисно для паралельної роботи (workers, batch-processing), але обмежено порівняно з multi-host оркестраторами.

Теорія

TL;DR

docker compose up --scale <service>=N крутить N container того сервісу.
deploy.replicas у compose.yaml (Compose v2+) це декларативний еквівалент.
Усі репліки крутяться на тому самому host, у Compose немає scheduling між машинами.
Репліки ділять project-мережу; DNS для service-імені резолвиться на усі репліки (round-robin).
Не можна опублікувати фіксований host-порт з кількох реплік — port-конфлікт. Бери expose: (тільки внутрішньо) і reverse proxy перед ними.
Для multi-host бери Swarm (docker stack deploy), Kubernetes або подібне.

Швидкий приклад

yaml

# compose.yaml
services:
  worker:
    image: myworker
    deploy:
      replicas: 3
  api:
    image: myapi
    expose:
      - "3000"   # тільки внутрішньо, без фіксованого host-порту
    deploy:
      replicas: 5
  web:
    image: nginx
    ports:
      - "80:80"
    # nginx-config балансує на api:3000 (Docker DNS round-robin'ить)

bash

docker compose up -d
# 3 worker-репліки + 5 api-реплік + 1 web reverse proxy.
docker compose ps
#   myapp-worker-1, myapp-worker-2, myapp-worker-3
#   myapp-api-1 ... myapp-api-5
#   myapp-web-1

Три сервіси, один стек, масштабовано по-різному.

Імперативне масштабування у runtime

bash

# Збільшити до 10 api-реплік без рестарту інших сервісів
docker compose up -d --scale api=10

# Зменшити назад
docker compose up -d --scale api=3

# Кілька сервісів одночасно
docker compose up -d --scale api=5 --scale worker=10

Флаг --scale override'ить deploy.replicas для цього прогону. Compose зупиняє або стартує container, щоб збігалося з запитаною кількістю.

Як DNS резолвить кілька реплік

Embedded DNS Docker повертає УСІ IP для service-імені. Багато клієнтів (HTTP-бібліотеки, стандартні бібліотеки мов) round-robin'ять між повернутими A-записами:

bash

$ docker compose exec web nslookup api
Name: api
Address 1: 172.18.0.5
Address 2: 172.18.0.6
Address 3: 172.18.0.7
# Три репліки; клієнти round-robin між ними.

Чи реально твій клієнт розподіляє load, залежить від його DNS-resolution-поведінки. Більшість сучасних HTTP-клієнтів так.

Чому фіксовані порти ламаються з репліками

yaml

services:
  api:
    image: myapi
    ports:
      - "3000:3000"     # ← проблема при scale
    deploy:
      replicas: 3

bash

$ docker compose up -d
ERROR: only one of api can be running at port 3000

Два container не можуть bind на той самий host-порт. Рішення:

Випадкові host-порти (ports: ["3000"] без : mapping), Docker обирає вільні порти.
expose: only, тільки внутрішній доступ; reverse proxy обробляє external.
Range mapping, ports: ["3000-3009:3000"] алокує діапазон.

Прод-відповідь майже завжди #2: reverse proxy перед, репліки внутрішні.

Reverse-proxy патерн

yaml

services:
  api:
    image: myapi
    expose: ["3000"]
    deploy: { replicas: 5 }
  web:
    image: nginx:1.27-alpine
    ports: ["80:80"]
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on: [api]

# nginx.conf
upstream api_backend {
    server api:3000;     # Docker DNS резолвить на усі IP реплік
}
server {
    listen 80;
    location / {
        proxy_pass http://api_backend;
    }
}

Lookup upstream api:3000 б'є у Docker DNS, отримує кілька IP, nginx load-balance'ить. Репліки можуть scale up/down вільно.

Масштабування з Traefik (auto-discovery)

yaml

services:
  api:
    image: myapi
    expose: ["3000"]
    deploy: { replicas: 5 }
    labels:
      - "traefik.http.routers.api.rule=Host(`api.local`)"
      - "traefik.http.services.api.loadbalancer.server.port=3000"
  traefik:
    image: traefik:v3
    ports: ["80:80", "8080:8080"]
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

Traefik стежить за Docker-event'ами і авто-оновлює свої routes, коли репліки приходять/йдуть. Чистіше, ніж nginx для динамічного scale.

Що Compose-масштабування НЕ робить

Health-aware load balancing. Docker DNS повертає IP усіх реплік, healthy чи ні.
Multi-host scheduling. Усі репліки на одній машині. CPU/пам'ять цього host це стеля.
Auto-scaling. Жодних min: 3, max: 20, target_cpu: 70%. Кількість ставиш руками.
Rolling-updates з контрольованим parallelism. docker compose up перестворює container паралельно.

Для будь-чого з цього потрібен Swarm або Kubernetes.

Типові помилки

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

Згадано вище. Фікс: expose: + reverse proxy.

Масштабування stateful-сервісів

yaml

services:
  db:
    image: postgres:16
    deploy: { replicas: 3 }    # ← ПОГАНО

Три postgres-container на одному host = три незалежні бази, що намагаються використати той самий volume = корупція. Stateful-сервіси не масштабуються так; replication і HA це інші concerns.

Масштабування worker-сервісів без queue-ідемпотентності

Якщо workers обробляють повідомлення з черги, кілька workers паралельно це win. Але workers мають бути ідемпотентними (повідомлення, оброблене двічі, не має шкідливого ефекту). Інакше scale = баги.

Забути, що --scale per-run

bash

docker compose up -d --scale api=5
# api на 5 реплік

docker compose up -d           # наступний прогін, без --scale
# api назад до deploy.replicas (дефолт 1, якщо не задано)

--scale не персистить. Для постійної кількості постав deploy.replicas у YAML.

Реальне застосування

Worker pool (image-processing, background-job): scale worker до N, черга годує task'ами, ідемпотентна обробка.
Stateless API за proxy: api-репліки + nginx/Traefik для load balancing. Легке horizontal-scale на одному host.
CI test-parallelism: scale runner-сервіс до CPU-ядер для паралельного test-виконання.
Міграції на Swarm/K8s: Compose deploy.replicas це той самий ключ, що Swarm використовує, тож синтаксис переноситься, коли graduate'нешся.

Питання для поглиблення

Q: Яка різниця між docker compose up --scale і docker service scale (Swarm)?

A: compose --scale single-host. Swarm service scale розподіляє між cluster-node. Та сама ідея, інший scope.

Q: Як репліки ділять стан?

A: За замовчуванням ніяк. Кожна репліка має свій writable-шар. Для shared-стану направ усі репліки на той самий external-сервіс (DB, Redis) або бери named volume.

Q: Чи Compose scale production-ready?

A: Для single-host навантажень з відповідним front-end (reverse proxy) так. Для HA ні, один host-fail зносить усі репліки. Multi-host означає Swarm або K8s.

Q: Чи можна scale до нуля?

A: Так: docker compose up -d --scale api=0. Зупиняє усі api-container. Корисно для тимчасового вимкнення сервісу.

Q: (Senior) Як спроектувати single-host Compose-стек для навантаження, що зрідка burst'ить до 10x норми?

A: Три опції. (1) Pre-scale до peak (втрата під час норми). (2) Ручний scale-up на відомі burst-часи через cron-trigger'ний docker compose up --scale. (3) Перехід на Swarm або K8s з HPA. Для single-host опція 2 (cron-driven) реалістична відповідь; для справжньої елестичності маєш покинути Compose.

Приклади

Worker-pool з auto load balancing через Traefik

yaml

services:
  api:
    image: myorg/api:1.0
    expose: ["3000"]
    deploy:
      replicas: 4
    labels:
      - "traefik.http.routers.api.rule=Host(`api.local`)"
      - "traefik.http.services.api.loadbalancer.server.port=3000"
      - "traefik.http.services.api.loadbalancer.healthcheck.path=/health"

  traefik:
    image: traefik:v3
    command:
      - --api.insecure=true
      - --providers.docker
      - --entrypoints.web.address=:80
    ports:
      - "80:80"
      - "8080:8080"   # Traefik-дашборд
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

bash

$ docker compose up -d
$ curl -H 'Host: api.local' http://localhost/
# Round-robin між 4 api-репліками; Traefik чекає /health

$ docker compose up -d --scale api=8
# Traefik автоматично підхоплює нові репліки

Background-workers, що читають з черги

yaml

services:
  redis:
    image: redis:7
  worker:
    image: myorg/worker:1.0
    deploy:
      replicas: 5
    environment:
      REDIS_URL: redis://redis:6379
    depends_on: [redis]

П'ять worker-container з'єднуються з тією самою Redis-чергою. Кожен тягне job незалежно. Лінійний speedup при додаванні workers, до пропускної здатності черги.

Scaling у runtime

bash

# Звичайне навантаження
$ docker compose up -d
# 1 api за замовчуванням

# Black Friday
$ docker compose up -d --scale api=20
# 20 api-реплік крутяться

# Після пікового періоду
$ docker compose up -d --scale api=3
# Назад до 3

Без рестарту непов'язаних сервісів. Compose коригує лише те, що змінилося.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Коментарі

Ще немає коментарів