Стратегии деплоя

Что такое деплой и его стратегии

Deployment (деплой, развёртывание) — процесс доставки новой версии приложения в рабочее окружение. Стратегия деплоя отвечает на вопрос, как именно старая версия сменяется новой: одномоментно, по частям или сначала для доли пользователей.

Вопрос не академический. Наивный вариант «остановить старое, запустить новое» означает простой и одномоментный удар по всем пользователям, если новая версия сломана. Стратегии существуют, чтобы разменивать риск на ресурсы и время.

Сравнение

Recreate

Погасить всё старое, поднять новое. Простой равен времени старта приложения.

Единственный вариант, когда версии физически несовместимы: например, миграция БД ломает старую схему, и две версии не могут работать одновременно. Для внутренних систем с ночным окном обслуживания — вполне законно. Для публичного сервиса — нет.

Rolling update

Реплики обновляются по одной (или небольшими группами): подняли новую, дождались готовности, погасили старую, перешли к следующей. Стратегия по умолчанию в Kubernetes и Docker Swarm.

spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0     # не терять мощность во время выкатки
      maxSurge: 2           # можно временно поднять на 2 пода больше

Критически важно: rolling работает только при корректном health check. Без readiness-пробы оркестратор считает под готовым сразу после старта процесса и направит на него трафик до того, как приложение реально готово отвечать, — выкатка «успешна», а пользователи получают ошибки.

Неизбежное свойство: в момент выкатки в production одновременно работают обе версии. Значит, API и схема данных должны быть обратно совместимы.

Blue-green

Держим два одинаковых окружения. Blue — текущее, принимает трафик. Green — новое, разворачивается и прогревается рядом. Когда green проверено, балансировщик переключает трафик целиком. Blue остаётся нетронутым как готовая площадка для отката.

upstream app {
    server 10.0.1.10:8000;   # blue
    # server 10.0.2.10:8000; # green — раскомментировать при переключении
}

• Плюс: откат — это переключение обратно, секунды. Новую версию можно полноценно проверить на production-конфигурации до подачи трафика.
• Минус: двойные ресурсы. Для парка GPU-инстансов вторая копия окружения — прямые деньги, поэтому blue-green там применяют редко.
• Подвох: состояние. База обычно одна на оба окружения, и переключение не откатывает уже применённые миграции.

Canary

Новая версия получает малую долю трафика (1–5%) — «канарейка в шахте». Смотрим на метрики: ошибки, задержку, бизнес-показатели. Всё хорошо — увеличиваем долю до 25%, 50%, 100%. Плохо — снимаем канарейку, пострадал минимум пользователей.

# Ingress nginx: 5% трафика на canary-версию
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"

Канареечный релиз — единственная стратегия, которая проверяет версию на реальном трафике с реальными данными до полной выкатки. Цена — обязательный мониторинг: без метрик и автоматических алертов canary превращается в «выкатили на 5% и забыли». Решение о продвижении принимают по числам, а не по ощущениям, и в зрелых установках его автоматизируют.

A/B-тестирование

Технически похоже на canary — трафик тоже делится, — но цель другая. Canary отвечает на вопрос «версия не сломана?» (техника), A/B — «какой вариант лучше по конверсии?» (продукт). Деление идёт не случайно, а по признаку пользователя, и длится неделями, а не минуты.

Что делает деплой безопасным независимо от стратегии

• Обратная совместимость. Все стратегии, кроме recreate, означают одновременную работу двух версий. Отсюда правило expand/contract для схемы БД: сначала добавить колонку и научиться жить с обеими, выкатить код, только потом удалять старое — отдельным релизом.
• Feature flags. Отделяют деплой от релиза: код уезжает в production выключенным и включается флагом без новой выкатки. Откат функции становится изменением настройки, а не деплоем.
• Health check. Readiness — «готов принимать трафик», liveness — «жив, не надо перезапускать». Оркестратор опирается на них при выкатке.
• Отработанный откат. Откат, который не пробовали, не работает. kubectl rollout undo deploy/api должен быть проверенной операцией, а не теорией.
• Неизменяемые теги образов. Откатиться на latest невозможно — см. Docker Registry.

Что выбрать

Начните с rolling — он бесплатен и покрывает большинство случаев. Blue-green берите, когда мгновенный откат важнее удвоения ресурсов (платёжные системы). Canary — когда трафик велик и есть мониторинг, способный поймать деградацию на 5% выборке. Recreate — только когда версии несовместимы в принципе.

Связанные термины

• CI/CD — процесс, финалом которого является деплой
• CI/CD pipeline — где живёт стадия deploy
• Kubernetes — реализует rolling и canary штатно
• health check — без него безопасной выкатки не бывает
• load balancer — переключает трафик между версиями
• Уведомления и алерты — по ним принимают решение о продвижении canary