Blue/Green deployment — IT-словарь

TL;DR

Blue/Green deployment — стратегия развёртывания с двумя идентичными средами (blue и green), где трафик в каждый момент времени идёт только в одну из них. Позволяет выпускать новые версии с мгновенным откатом и минимальным downtime.

Краткое определение

Blue/Green deployment — подход к развёртыванию, при котором существуют две идентичные среды: в одной работает текущая версия (blue), другая используется для развёртывания новой версии (green). После проверки трафик переключается на green, а blue остаётся резервом для быстрого отката.

Оригинал и перевод

Язык: английский
Оригинал: Blue/Green deployment
Буквальный перевод: сине-зелёное развёртывание
Русские аналоги: сине-зелёный деплой, развёртывание в двух средах

Синонимы и варианты написания

Blue-green
A/B deployment (не путать с A/B тестированием)
Zero-downtime deployment (частично)
Red/Black deployment (в AWS Terminology)

Как работает Blue/Green

                    ┌─────────────────┐
                    │  Load Balancer  │
                    │   (Nginx/ALB)   │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                │                ▼
    ┌───────────────┐        │        ┌───────────────┐
    │   BLUE        │        │        │    GREEN      │
    │   (v1.0)      │        │        │    (v1.1)     │
    │   ● Active    │        │        │    ○ Standby  │
    │               │        │        │               │
    │   Запущена    │        │        │   Развёрнута  │
    │   старая      │        │        │   новая       │
    │   версия      │        │        │   версия      │
    └───────────────┘        │        └───────────────┘
            │                │                │
            └────────────────┼────────────────┘
                             │
                    ┌────────▼────────┐
                    │   База данных   │
                    │   (общая для    │
                    │   обеих сред)   │
                    └─────────────────┘

Этапы Blue/Green деплоя

Шаг 1: Есть работающая среда (BLUE)

Traffic → BLUE (v1.0) ✅
          GREEN (пусто)

Шаг 2: Развёртываем новую версию на GREEN

Traffic → BLUE (v1.0) ✅
          GREEN (v1.1) 🔄 деплой

Шаг 3: Тестируем GREEN

Traffic → BLUE (v1.0) ✅
          GREEN (v1.1) ✅ тесты OK

Шаг 4: Переключаем трафик на GREEN

Traffic → BLUE (v1.0) ○ standby
          GREEN (v1.1) ✅ active

Шаг 5: Откат (если нужно)

Traffic → BLUE (v1.0) ✅ rollback!
          GREEN (v1.1) ❌ проблемы

Где используется

High-availability сервисы — банки, платежи, SaaS
CI/CD пайплайны — автоматические деплои
Web-приложения — интернет-магазины, порталы
API-сервисы — микросервисы, REST/GraphQL API
Mobile backend — обновление без простоя

Когда это важно

Blue/Green критичен при следующих требованиях:

Zero downtime — нельзя останавливать сервис даже на минуту
Быстрый откат — возможность вернуться за секунды
Частые релизы — несколько деплоев в день
Высокая доступность — SLA 99.9%+
Минимизация рисков — тестирование на реальной среде перед переключением

Преимущества и недостатки

✅ Преимущества

Мгновенный откат — переключение балансировщика за секунды
Zero downtime — пользователи не замечают деплой
Тестирование перед переключением — можно проверить green до продакшена
Простота понимания — легче, чем canary release
Подходит для БД — при обратной совместимости миграций

❌ Недостатки

Дороже — нужны 2 полных среды (x2 стоимость инфраструктуры)
Сложнее с БД — нужна обратная совместимость миграций
Простой ресурсов — blue простаивает после переключения
Не для всех изменений — не подходит для изменений в БД без обратной совместимости

Пример реализации на Nginx

Конфигурация upstream

# /etc/nginx/conf.d/upstream.conf

# Переключаемый upstream
upstream backend {
    # Изначально весь трафик на blue
    server blue:8080 weight=100;
    server green:8080 weight=0 backup;
}

server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Скрипт переключения (bash)

#!/bin/bash
# switch-to-green.sh

BLUE="blue:8080"
GREEN="green:8080"

echo "Testing GREEN environment..."
# Проверка здоровья green
curl -f http://$GREEN/health || exit 1

echo "Switching traffic to GREEN..."
# Обновляем upstream (через nginx include или API)
cat > /etc/nginx/upstream-weight.conf <<EOF
upstream backend {
    server $BLUE weight=0 backup;
    server $GREEN weight=100;
}
EOF

# Перезагружаем nginx без простоя
nginx -s reload

echo "Traffic switched to GREEN ✅"
echo "BLUE теперь standby для отката"

Docker Compose пример

version: '3.8'

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - blue
      - green

  blue:
    image: myapp:1.0
    environment:
      - VERSION=1.0
    deploy:
      replicas: 3

  green:
    image: myapp:1.1
    environment:
      - VERSION=1.1
    deploy:
      replicas: 3

Blue/Green vs Canary Release

Параметр	Blue/Green	Canary
Среды	2 полных среды	1 среда, часть трафика
Переключение	Мгновенное (100%)	Постепенное (1% → 100%)
Откат	Мгновенный	Постепенный
Риск	Выше (все пользователи сразу)	Ниже (тест на части)
Стоимость	Выше (2x инфраструктура)	Ниже (доп. контейнеры)
Сложность	Проще	Сложнее (роутинг трафика)

Типичные ошибки

❌ Нет обратной совместимости БД — нельзя откатиться
❌ Общие сессии между средами — пользователи разлогиниваются
❌ Нет проверки green перед переключением — переключают непротестированное
❌ Blue удаляется сразу — некуда откатываться
❌ Миграции БД выполняются после деплоя — должны быть до переключения

Аналоги и связанные термины

Canary release — постепенное развёртывание на части трафика
Rollback — откат к предыдущей версии
Feature flag — включение функциональности через конфиг
Traffic switching — переключение трафика между средами
Zero-downtime deployment — деплой без простоя (общий термин)

Смотри также (статьи на сайте)

CI/CD GitHub Actions: workflow, secrets, tests, deploy — автоматизация деплоя
Docker для фронтенд и бэкенд разработчиков — контейнеризация

Смотри также (сниппеты)

Systemd: автоперезапуск сервиса — отказоустойчивость
Nginx: upstream health check — проверка здоровья бэкенда

Смотри также (термины)

Feature flag — переключатель функциональности
Canary release — постепенный релиз
Health check — проверка доступности

Мини-FAQ

Можно ли откатиться мгновенно?

Ответ: Да, это главное преимущество Blue/Green. Если не было необратимых миграций БД — переключение балансировщика занимает секунды.

Нужны ли две базы данных?

Ответ: Обычно нет. Обе среды работают с одной БД. Поэтому миграции должны быть обратно совместимыми:

✅ Добавление нового поля (не удалять старое сразу)
✅ Изменение типа данных с поддержкой обоих форматов
❌ Удаление поля, которое использует blue

Как долго держать blue после переключения?

Ответ: Минимум до следующего деплоя (чтобы было куда откатиться). Некоторые держат 1-2 недели, затем удаляют blue для экономии.

Blue/Green подходит для монолитов?

Ответ: Да, даже больше чем для микросервисов. Для микросервисов часто используют Canary release из-за сложности управления множеством сред.