Ты собрал крутой бот, сайт или сервис — и нужно выкатить обновление в прод. А вдруг сломается? Пользователи уйдут, метрики упадут, настроение испортится.
Blue-Green Deployment решает эту проблему. Это стратегия, при которой у тебя всегда есть две полностью идентичные продакшен-среды:
- Blue — сейчас живая, принимает всех пользователей.
- Green — standby, туда ты выкатываешь новую версию.
Тестируешь Green в реальных условиях → всё ок → мгновенно переключаешь трафик → Blue становится standby (готов к следующему деплою или откату). Ноль даунтайма, откат за секунды, полная безопасность.
Как именно это работает
- Blue — активная среда (v1). Пользователи ходят на неё через Load Balancer / Nginx / Kubernetes Service / Cloud LB.
- Ты собираешь новую версию (v2) → деплоишь только в Green.
- Запускаешь smoke-тесты, health-checks, интеграционные тесты прямо на Green (через приватный URL или отдельный ingress).
- Всё зелёное? Переключаешь роутер/балансировщик на Green.
- Теперь Green = live (v2), Blue = standby.
- При следующей выкатке роли меняются.
Переключение трафика происходит за 1–5 секунд:
- Nginx: nginx -s reload после смены proxy_pass.
- Kubernetes: kubectl apply обновлённого Service (меняешь selector).
- AWS ALB / Cloud: обновление target group.
- Traefik / Caddy: динамические labels.
Откат — просто верни трафик обратно на Blue.
Преимущества
- Zero-downtime даже при сложных миграциях.
- Мгновенный rollback (даже если 1% пользователей увидели баг — сразу назад).
- Тестирование в 100% продакшен-окружении (с реальными БД, кэшем, секретами).
- Легко интегрируется в CI/CD — деплой становится частью пайплайна.
- Идеально для вайбкодеров: ИИ пишет код → ты одним промптом получаешь весь blue-green стек.
Настройка конфигурации «через деплой»
Это ключевой момент запроса. Ты не лезешь руками на сервер.
- Terraform / Pulumi — описываешь две среды в коде.
- Helm + values.yaml — deploy_version: blue или green.
- GitHub Actions / GitLab CI — каждый git push → build → deploy в inactive среду → тесты → switch.
Простейшая реализация на VPS (Docker + Nginx) — для старта
Идеально для одиночного сервера или небольшого проекта.
docker-compose.yml (с profiles):
services:
app-blue:
image: myapp:${TAG:-latest}
build: .
profiles: ["blue"]
restart: unless-stopped
labels:
- "traefik.enable=true" # или используй nginx
app-green:
image: myapp:${TAG:-latest}
build: .
profiles: ["green"]
restart: unless-stopped
Nginx.conf (динамический):
upstream backend {
server app-blue:3000; # меняем на app-green при switch
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
deploy.sh
#!/bin/bash
ACTIVE=$(cat /var/run/active-slot.txt 2>/dev/null || echo "blue")
NEW_SLOT=$( [ "$ACTIVE" = "blue" ] && echo "green" || echo "blue")
docker compose --profile $NEW_SLOT up -d --build
sleep 10 # health check
curl -f http://localhost/health || exit 1
echo "$NEW_SLOT" > /var/run/active-slot.txt
sed -i "s/app-$ACTIVE/app-$NEW_SLOT/" /etc/nginx/nginx.conf
nginx -s reload
docker compose --profile $ACTIVE stop
echo "✅ Переключили на $NEW_SLOT!"
Запуск: ./deploy.sh — и всё.
Полноценный Kubernetes
Два Deployment + один Service, который переключается.
blue-deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
color: blue
template:
metadata:
labels:
app: myapp
color: blue
spec:
containers:
- name: app
image: myapp:v1
readinessProbe:
httpGet:
path: /health
port: 3000
Аналогично green-deployment.yaml (color: green, image: v2).
service.yaml (переключается):
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
color: blue # ← меняешь на green и apply
ports:
- port: 80
targetPort: 3000
Ingress (опционально) всегда смотрит на myapp-service.
Переключение:
kubectl apply -f green-deployment.yaml
# ждём ready
kubectl patch service myapp-service -p '{"spec":{"selector":{"color":"green"}}}'
# Blue можно удалить или оставить как standby
Terraform + Kubernetes (полная IaC-настройка)
resource "kubernetes_deployment" "blue" { ... color = "blue" ... }
resource "kubernetes_deployment" "green" { ... color = "green" ... }
resource "kubernetes_service" "app" {
spec {
selector = {
color = var.active_color # "blue" или "green" — меняешь в variables.tf
}
}
}
terraform apply -var="active_color=green"
Обработка базы данных (самое важное)
Не пытайся копировать БД каждый раз — используй shared database + expand/contract:
- Добавляешь новые колонки/таблицы (v2 умеет работать со старой схемой).
- Переключаешь приложение на v2.
- Запускаешь миграцию данных.
- Удаляешь старые колонки (v1 уже не используется).
Инструменты: Flyway, Liquibase, Alembic, Prisma Migrate с --create-only.
Если совсем критично — делай blue-green и для RDS (AWS имеет встроенный).
CI/CD: настройка «через деплой» (GitHub Actions)
name: Blue-Green Deploy
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build & Push
run: docker build -t myapp:${{ github.sha }} && docker push ...
- name: Deploy to inactive
run: ssh user@server "./deploy-to-inactive.sh ${{ github.sha }}"
- name: Tests
run: curl -f https://staging.myapp.com/health
- name: Switch
run: ssh user@server "./switch.sh"
Готовые промпты для ИИ (копируй и вставляй в Grok/Claude/GPT)
Промпт 1: Полный стек для VPS (Docker + Nginx)
" Создай полный ready-to-use набор файлов для blue-green deployment моего FastAPI (Python) приложения на Ubuntu VPS.
- docker-compose.yml с profiles blue/green
- nginx.conf с динамическим upstream
- deploy.sh с health checks, logging, rollback
- GitHub Actions workflow
- инструкция по первому запуску и ежедневному использованию.
Сделай максимально надёжно, с zero-downtime и комментариями на русском."
Промпт 2: Kubernetes + Helm
"Напиши Helm chart для blue-green deployment Node.js приложения в Kubernetes. Два Deployment (blue/green), Service с selector, Ingress. Добавь values.yaml с deploy_version. Покажи как переключать в CI/CD. Добавь Argo Rollouts вариант для автоматизации."
Промпт 3: Terraform + AWS ECS
"Создай Terraform код для blue-green deployment на AWS ECS Fargate с CodeDeploy. Два task definition, ALB listener rules, lifecycle hooks для smoke tests. Всё declarative."
Промпт 4: Обработка БД + миграции
"Для моего Prisma + PostgreSQL проекта объясни и дай код expand/contract миграций под blue-green. Покажи порядок: сначала миграция schema, потом switch app, потом cleanup."
Промпт 5: Анализ твоего проекта
"Предложи оптимальную blue-green реализацию (VPS/K8s/Cloud) с минимальными затратами и максимальной надёжностью. Дай готовые файлы."
Сравнение с другими стратегиями
- Rolling Update — постепенная замена подов (дешевле, но откат сложнее).
- Canary — 1% → 10% → 100% трафика (отлично для A/B, но сложнее).
- Blue-Green — самый простой и надёжный для большинства проектов.