Як виконати rolling update у Docker Swarm?

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

Rolling-update у Docker Swarm замінює running-task по batch за раз, чекаючи health між batch. Вбудований механізм Swarm реально хороший у цьому, з auto-rollback на failure як first-class фічею.

Теорія

TL;DR

docker service update з --image тригер. Swarm замінює task за політикою update_config.
Ключові параметри: parallelism (скільки за раз), delay (між batch), monitor (як довго стежити за кожним), failure-action (continue/pause/rollback).
Порядок: stop-first (дефолт, короткий gap per task) або start-first (zero-downtime, якщо застосунок підтримує паралельні старий/новий).
Rollback одна команда (docker service rollback) або автоматично на failure.
Healthcheck на сервісі це те, що робить «failure» виявленим. Без нього Swarm вважає started=healthy.

Update-flow

Сервіси: 6 реплік api:1.0
--update-parallelism=2 --update-delay=30s

t=0:    [v1.0 v1.0 v1.0 v1.0 v1.0 v1.0]   випуск update
t=0:    [STOP STOP v1.0 v1.0 v1.0 v1.0]   stop 2 (або start-first: додатковий v1.1 spawn)
t=5:    [v1.1 v1.1 v1.0 v1.0 v1.0 v1.0]   2 нових task healthy
t=35:   [v1.1 v1.1 STOP STOP v1.0 v1.0]   delay+30s, наступний batch
t=40:   [v1.1 v1.1 v1.1 v1.1 v1.0 v1.0]
t=70:   [v1.1 v1.1 v1.1 v1.1 v1.1 v1.1]   готово

Під час update трафік продовжує йти на ті репліки, що healthy.

Імперативна форма (CLI)

bash

docker service update \
    --image myorg/api:1.1 \
    --update-parallelism 1 \
    --update-delay 30s \
    --update-monitor 30s \
    --update-failure-action rollback \
    --update-max-failure-ratio 0.2 \
    --update-order start-first \
    api

Що робить кожен флаг:

--update-parallelism N — замінити N task за раз (дефолт 1).
--update-delay 30s — чекати між batch.
--update-monitor 30s — стежити за кожним batch на failure стільки.
--update-failure-action <continue|pause|rollback> — що робити на failure.
--update-max-failure-ratio 0.2 — щонайбільше 20% task можуть впасти перед тригером action.
--update-order <stop-first|start-first> — заміна через stop спочатку або start нового спочатку.

Декларативна форма (stack-файл)

yaml

version: '3.9'
services:
  api:
    image: myorg/api:1.0
    deploy:
      replicas: 6
      update_config:
        parallelism: 1
        delay: 30s
        order: start-first
        failure_action: rollback
        monitor: 30s
        max_failure_ratio: 0.2
      rollback_config:
        parallelism: 2
        delay: 5s
        failure_action: pause

bash

docker stack deploy -c stack.yaml mystack
# Редагуй image на 1.1, redeploy → тригерить rolling update з config вище.

Stack-файл це канонічне місце, version-controlled, reviewable.

Health-driven gating

Swarm вирішує «чи цей batch healthy?» через:

Container стартонув успішно (без exit під час monitor-періоду).
Якщо healthcheck визначено, container healthy.
Не більше ніж max_failure_ratio failures у batch.

Без healthcheck Swarm знає лише «процес стартонув». Застосунок, що стартує, але одразу misbehaving, ще рахується як «healthy» для Swarm. Healthcheck критичні для безпечного rolling-update.

Rollback

bash

# Ручний rollback у будь-який час
docker service rollback api
# Повертає до попереднього image-tag

Або через failure_action: rollback Swarm rollback'ить автоматично, коли failure-ratio перевищено. У комбінації з monitor отримуєш «якщо 1 з 5 у новому batch unhealthy після 30 секунд, roll back усього сервісу» семантику.

`start-first` vs `stop-first`

yaml

order: stop-first    # дефолт — невеликий gap per task
order: start-first   # підняти новий поряд зі старим, тоді drain старий

start-first шлях до справжнього zero-downtime, але потребує застосунку, що толерує короткий overlap (дві версії крутяться разом). Для stateless web/API нормально. Для workers зі строгою singleton-семантикою може потребувати code-зміни.

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

Update без healthcheck

yaml

services:
  api:
    image: myorg/api
    # БЕЗ healthcheck → Swarm не може виявити погані версії

Без healthcheck зламаний новий image rolls out на усі репліки до того, як failure стане видимим. Додай healthcheck:, щоб Swarm gate'нути прогрес на реальний app-readiness.

Поставити parallelism надто високим

yaml

update_config:
  parallelism: 5    # усі 6 реплік одразу

Під час короткого replacement-вікна у тебе дуже мало healthy task. Сплеск load = накопичення. Нижчий parallelism = безпечніше.

Забути rollback_config

Rollback використовує свій окремий блок конфігурації. Якщо ставиш лише update_config, rollback бере дефолти (часто повільніший, ніж хочеш). Визнач rollback_config явно.

Image-tag все ще latest для --rollback

bash

docker service rollback api
No previous image to roll back to: same tag

Якщо обидва нові і старі були tagged latest, Swarm не може їх розрізнити. Завжди tag версією (або commit SHA), щоб rollback працював.

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

Прод-деплої на Swarm-кластерах — кожен новий image тригерить service update; Swarm обробляє parallelism + monitoring.
Staged canary — спочатку deploy 1 з 10 з parallelism=1 і довгим monitor; якщо стабілізується, підніми parallelism для решти.
Hotfix-rollout — service update --image hotfix:1.0 з високим parallelism (швидше) і агресивним monitoring (ловити failures швидко).
DB-міграції — ніколи через rolling-update напряму. Спочатку запусти one-off migrator-сервіс, тоді update app-репліки.

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

Q: Що відбувається з in-flight запитами під час task-replacement?

A: Task, scheduled for replacement, отримують SIGTERM і налаштований grace-період (stop_grace_period). Застосунки мають drain in-flight запити перед виходом. У комбінації з routing mesh трафік steer'иться від stopping-task перед SIGTERM.

Q: Чи можу update'нути кілька сервісів разом?

A: Edit stack-файл з новими image для кожного, тоді docker stack deploy -c stack.yaml mystack. Кожен сервіс update'ься незалежно за своїм config; cross-service ordering не отримаєш.

Q: Як Swarm rolling-update відрізняється від K8s rolling-update?

A: Концептуально ідентично. K8s deployment: maxSurge, maxUnavailable ≈ Swarm parallelism і order. K8s readiness-probes ≈ Swarm healthcheck. Та сама модель, інший синтаксис.

Q: Яка різниця між update_config і rollback_config?

A: update_config контролює forward-update (1.0 → 1.1). rollback_config контролює reverse-update (1.1 → 1.0). Часто хочеш повільніший, безпечніший rollback, ніж forward-update.

Q: (Senior) Як спроектувати rolling-update параметри для сервісу, що бере 90 секунд на прогрів?

A: start_period у healthcheck = 120с (дай warmup час перед рахунком failures). update-monitor = 180с (чекай досить довго, щоб побачити реальні failures emerge). parallelism = 1 (повільний rollout, 90с warmup × репліки = загальний update-час). failure_action = rollback. Патерн: monitor-period > start-period > observation, потрібний для стабільності. Швидші rollout ховають warmup-related failures; цей консервативний config їх ловить.

Приклади

Production-якості rollout

yaml

version: '3.9'
services:
  api:
    image: myorg/api:1.0
    deploy:
      replicas: 6
      update_config:
        parallelism: 2
        delay: 30s
        order: start-first
        failure_action: rollback
        monitor: 60s
        max_failure_ratio: 0.2
      rollback_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: any
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 30s

Deploy з новим image:

bash

sed -i 's/myorg\/api:1.0/myorg\/api:1.1/' stack.yaml
docker stack deploy -c stack.yaml mystack
docker service ps mystack_api
# Дивись, як task замінюються 2 за раз, з 30с gap, monitored 60с кожен.

Manual rollout з імперативними флагами

bash

docker service update \
    --image myorg/api:1.1 \
    --update-parallelism 1 \
    --update-delay 60s \
    --update-monitor 120s \
    --update-failure-action rollback \
    --update-max-failure-ratio 0.0 \
    --update-order start-first \
    api
# Строго: будь-який failure тригерить rollback.

Корисно для one-off tightly-controlled rollout.

Watching rollout

bash

$ watch -n 2 'docker service ps mystack_api --format "table {{.Name}}\t{{.Image}}\t{{.CurrentState}}"'
# Live-view, які task якої версії, у якому стані.

Чудово для верифікації, що rollout прогресує як очікувано.

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

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

Premium

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

Коментарі

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