Rolling updates і rollback

Після модуля ви зможете проєктувати rolling update, обрати start-first/stop-first, налаштувати failure threshold і довести автоматичний rollback під HTTP-навантаженням.

• читати UpdateStatus і task history
• задавати parallelism, delay і monitor
• розрізняти pause, continue і rollback
• вимірювати клієнтський результат

Зміна TaskTemplate створює tasks за UpdateConfig. parallelism обмежує одночасну заміну, delay розділяє batches, monitor задає вікно, max failure ratio — допустиму частку відмов.

Convergence команди та доступність застосунку — різні метрики.

stop-first звільняє ресурси перед replacement, але зменшує capacity. start-first спочатку запускає новий task; він потребує headroom і сумісності версій.

Start-first не гарантує zero downtime без healthcheck і readiness.

pause зберігає стан, continue продовжує update, rollback повертає попередню service spec. RollbackConfig має окремі order та monitor.

Rollback не скасовує database migrations, side effects і несумісні дані.

• Використовуйте immutable image
• Фіксуйте spec і 3/3
• Запускайте load generator поза service
• Рахуйте HTTP 000 окремо
• Вносьте одну несправність
• Перевіряйте UpdateStatus і spec

Створіть три replicas на port 18082. Політика замінює по одному task, використовує start-first і rollback за першої failure.

ssh swarm-manager-3 docker service create --detach=true --name swarm-m16-web --replicas 3 --publish published=18082,target=80,mode=ingress --update-parallelism 1 --update-delay 2s --update-monitor 5s --update-failure-action rollback --update-max-failure-ratio 0 --update-order start-first --rollback-parallelism 1 --rollback-monitor 5s --rollback-order stop-first nginx:1.29-alpine
ssh swarm-manager-3 docker service inspect swarm-m16-web --pretty
ssh swarm-manager-3 docker service ps swarm-m16-web

curl --fail --silent http://10.77.0.11:18082/ >/dev/null
curl --fail --silent http://10.77.0.12:18082/ >/dev/null
curl --fail --silent http://10.77.0.13:18082/ >/dev/null

Запустіть цикл в окремому терміналі. Він записує кінцевий код кожної спроби без прихованого retry.

rm -f /tmp/swarm-m16-statuses
for n in $(seq 1 120); do
  curl --max-time 2 --silent --output /dev/null --write-out '%{http_code}\n' http://10.77.0.11:18082/ >> /tmp/swarm-m16-statuses
  sleep 0.2
done

Замініть command на exit 42. Перший новий task впаде, update перейде в rollback, початкові nginx tasks відновляться.

ssh swarm-manager-3 docker service update --detach=false --args 'sh -c "exit 42"' swarm-m16-web
ssh swarm-manager-3 docker service inspect swarm-m16-web --pretty
ssh swarm-manager-3 docker service ps swarm-m16-web --no-trunc
sort /tmp/swarm-m16-statuses | uniq -c

Перевірений результат: rollback_completed і 120 HTTP 200.

Пов’яжіть UpdateStatus.Message із Failed task, exit code і клієнтською часовою шкалою.

ssh swarm-manager-3 docker service inspect swarm-m16-web --format '{{json .UpdateStatus}}'
ssh swarm-manager-3 docker service ps swarm-m16-web --no-trunc
ssh swarm-manager-3 docker service logs --raw swarm-m16-web
curl --max-time 5 --fail --show-error http://10.77.0.11:18082/

• updating — процес триває
• paused — потрібне рішення
• rollback_started — повернення триває
• rollback_completed — spec повернено, дані перевіряють окремо

• Що обмежує parallelism?
• Навіщо monitor?
• Як start-first впливає на capacity?
• Чим rollback spec відрізняється від даних?
• Чому 3/3 недостатньо?
• Які запити не покриті?

Модуль засвоєно, якщо ви викликаєте failure, отримуєте rollback_completed і зіставляєте 120 результатів з task history.

ssh swarm-manager-3 docker service rm swarm-m16-web
rm -f /tmp/swarm-m16-statuses
ssh swarm-manager-3 docker service ls
ssh swarm-manager-3 docker node ls