Blue-Green deployment — паттерн нулевого простоя при деплое. Существуют два идентичных окружения: синее (текущий продакшен) и зелёное (новая версия). После тестирования зелёного окружения балансировщик нагрузки переключает трафик с синего на зелёное за секунды.
Как работает
Инфраструктура: балансировщик нагрузки (nginx, AWS ALB, Kubernetes Service) с возможностью мгновенного переключения weighted routing. «Синее» окружение принимает 100% трафика. Параллельно разворачивается «зелёное» с новой версией приложения.
После успешного развёртывания зелёного: smoke-тесты, переключение балансировщика — 100% трафика идёт в зелёное. Синее остаётся в резерве. При обнаружении ошибки — обратное переключение за 10-30 секунд. Синее окружение держится 24-48 часов, затем становится следующим зелёным.
В Kubernetes: два Deployment с разными labels → Service переключается через изменение selector. Либо через Ingress с weight аннотациями.
История
Blue-Green deployment описан Мартином Фаулером (Martin Fowler) и Джезом Хамблом (Jez Humble) в книге «Continuous Delivery» (2010). Netflix использует вариант Blue-Green через Spinnaker с 2012 года. AWS поддерживает стратегию нативно в CodeDeploy с 2014 года.
Варианты стратегий деплоя
- Blue-Green: мгновенное переключение, максимальная изоляция, удвоенные ресурсы.
- Canary: постепенный перевод трафика (1% → 10% → 50% → 100%).
- Rolling Update: замена подов/инстансов по одному.
- Recreate: остановка всех, запуск новых — есть период недоступности.
Связь с хостингом
Blue-Green деплой требует двойных ресурсов: два одинаковых набора VPS или два Deployment в Kubernetes. На Kubernetes реализуется за ~30 строк YAML. На голых серверах — через nginx upstream с разными server-блоками и изменением весов. Инструменты: Spinnaker, Argo Rollouts, AWS CodeDeploy, GitLab Environments.
Ключевые отличия от похожих терминов
Canary Release — более осторожная стратегия: сначала небольшой процент пользователей получает новую версию. Blue-Green — бинарное переключение. Continuous Deployment использует Blue-Green или Canary как механизм безопасного деплоя. A/B-тестирование — похоже, но цель — измерение конверсии, не безопасный деплой.
Принцип Blue-Green Deployment
Два идентичных окружения: blue (текущий production) и green (новая версия). Деплой в green при работающем blue. Тестирование green. Переключение трафика (Nginx, load balancer, DNS) мгновенно. При проблемах — откат за секунды.
Реализация на VPS
Директории: /var/www/blue и /var/www/green. Симлинк /var/www/current → /var/www/blue. Деплой: скопировать в green, проверить, переключить симлинк → green, reload Nginx. Через Docker: два набора контейнеров, Nginx upstream переключает порты.
Blue-Green в Kubernetes
Два Deployment: app-blue и app-green. Service selector: version: blue. Переключение: изменить selector на version: green. ArgoCD и Argo Rollouts автоматизируют Blue-Green с анализом метрик. Canary-деплой: постепенный сдвиг процента трафика.
Blue-Green для баз данных
Самое сложное в Blue-Green: схема БД. Подход Forward-compatible migrations: новая версия приложения работает со старой и новой схемой. Expand-Contract: сначала добавить новую колонку, затем мигрировать данные, затем удалить старую. Flyway/Liquibase управляют миграциями с versioning.