Blue-green или canary-деплой: сравнение стратегий релиза

Главное различие

Обе стратегии решают одну задачу — выпускать новую версию без простоя и с возможностью быстро откатиться. Разница в том, как переходит трафик.

• Blue-green. Есть два одинаковых окружения: «синее» (текущая версия) и «зелёное» (новая). Новую версию разворачивают в зелёное, проверяют и переключают весь трафик разом. Синее остаётся в резерве для отката.
• Canary. Новую версию получает небольшая часть трафика. Если метрики в норме, долю увеличивают шагами до 100%. Если нет — трафик возвращают на старую версию.

Сравнение по ключевым параметрам

Когда что выбирать

Blue-green подходит, если:

• нужен простой и предсказуемый релиз с мгновенным откатом;
• трафика немного и статистически значимый canary-анализ всё равно невозможен;
• бюджет позволяет держать вторую копию окружения на время релиза.

Canary подходит, если:

• пользователей много и ошибка на всех сразу обходится дорого;
• есть метрики с разбивкой по версиям: доля ошибок, латентность, бизнес-показатели;
• команда готова автоматизировать анализ и откат.

Эти стратегии совместимы: можно развернуть зелёное окружение и переводить на него трафик постепенно.

Общая сложность: база данных

Обе версии приложения какое-то время работают с одной базой. Поэтому миграции схемы должны быть обратно совместимыми: сначала добавляем новые колонки и таблицы, выкатываем код, который умеет работать с обеими схемами, и только потом удаляем старое. Иначе откат приложения не поможет — старая версия не сможет работать с новой схемой.

Реализация в Nginx

Blue-green — два upstream и переключение одного include с последующим nginx -s reload:

upstream blue  { server 10.0.0.10:8080; }
upstream green { server 10.0.0.20:8080; }

server {
    listen 80;
    location / {
        proxy_pass http://green;  # переключение: green <-> blue
    }
}

Canary — веса в одном upstream:

upstream app {
    server 10.0.0.10:8080 weight=9;  # стабильная версия
    server 10.0.0.20:8080 weight=1;  # canary
}

Чтобы один пользователь не прыгал между версиями, используют привязку по cookie или хешу (hash $cookie_user_id consistent;), но тогда распределение зависит от ключа, а не от весов.

Реализация в Kubernetes

• Blue-green. Два Deployment с метками version: blue и version: green. Service выбирает поды по селектору; переключение — смена version в селекторе Service.
• Простой canary. Два Deployment за одним Service; доля трафика примерно равна доле реплик. Грубо, но без дополнительных инструментов.
• Canary через Ingress. Ingress-контроллеры, например ingress-nginx, поддерживают canary-аннотации с весом или правилами по заголовку и cookie.
• Автоматизированный canary. Argo Rollouts, Flagger или service mesh управляют шагами, проверяют метрики и откатывают релиз автоматически.

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

• Несовместимые миграции базы, из-за которых откат невозможен.
• Canary без метрик по версиям — непонятно, что именно сломалось.
• Слишком короткие шаги canary: проблемы, проявляющиеся под нагрузкой или со временем, не успевают проявиться.
• Удаление синего окружения сразу после переключения, когда откат ещё может понадобиться.