Blue-Green і Canary деплою

Blue-Green і Canary деплою

1) Завдання та ключові ідеї

• Blue-Green: тримаємо дві паралельні версії (Blue - активна, Green - нова), перемикаємо трафік атомарно. Швидкий відкат → миттєво повернути Blue.
• Canary: включаємо нову версію поетапно (1% → 5% → 25% → 50% → 100%), моніторимо SLO-метрики і зупиняємо/відкочуємо при деградації.

Загальний принцип: відокремити «доставку артефакту» від «включення трафіку» і автоматизувати спостережуваність + відкати.

2) Коли що вибирати

• потрібно миттєве перемикання (жорсткі RTO), прості state-less сервіси;
• є строгі вікна релізу/заморозки і зрозумілі перевірки smoke;
• дорого тримати тривалу подвійну ємність - але короткочасно можна.

• складні зміни, потрібна поетапна валідація на реальному трафіку;
• є зріла телеметрія (SLO, бізнес-метрики), можливість авто-стопа;
• критично обмежити радіус ураження (фінтех/iGaming-потоки).

Комбо-патерн: викочувати Green і перемикатися на нього через canary-ступені (Blue-Green як каркас, Canary як метод перенесення трафіку).

3) Архітектура маршрутизації трафіку

1. L4/L7-балансувальник (ALB/NLB, Cloud Load Balancer) - зважені target groups.

2. API-шлюз/WAF - route/weight за версіями, заголовками, cookie, регіонами.

3. Service Mesh (Istio/Linkerd/Consul) - процентний розподіл, fault-ін'єкція, ручки таймаутів/ретраїв/обмеження.

4. Ingress/NGINX/Envoy - upstream-ваги і маршрутизація по атрибутах.

5. Argo Rollouts/Flagger - оператор-контролер, автоматична прогресія, інтеграція з Prometheus/New Relic/Datadog.

4) Kubernetes: практичні шаблони

4. 1 Blue-Green (через Service selector)

Два Deployment: `app-blue` и `app-green`.
Один Service'app-svc'з селектором на потрібний'version'.

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: app-green, labels: { app: app, version: green } }
spec:
replicas: 4 selector: { matchLabels: { app: app, version: green } }
template:
metadata: { labels: { app: app, version: green } }
spec:
containers:
- name: app image: ghcr. io/org/app:1. 8. 0 apiVersion: v1 kind: Service metadata: { name: app-svc }
spec:
selector: {app: app, version: blue} # ← switch to green - change ports: [{port: 80, targetPort: 8080}]

Перемикання - атомарна зміна селектора (або міток) з контрольованим drain.

4. 2 Canary (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: app }
spec:
hosts: ["app. example. com"]
http:
- route:
- destination: { host: app. blue. svc. cluster. local, subset: v1 }
weight: 90
- destination: { host: app. green. svc. cluster. local, subset: v2 }
weight: 10

Міняйте'weight'по сходах; додайте retry, timeout, outlier-detector на DestinationRule.

4. 3 Argo Rollouts (авто-канарний прогін)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: app }
spec:
replicas: 6 strategy:
canary:
canaryService: app-canary stableService: app-stable steps:
- setWeight: 5
- pause: {duration: 300} # 5 min observation
- analysis:
templates:
- templateName: slo-guard
- setWeight: 25
- pause: { duration: 600 }
- analysis:
templates: [{ templateName: slo-guard }]
- setWeight: 50
- pause: {}
trafficRouting:
istio:
virtualService:
name: app routes: ["http-route"]

Аналіз-шаблон пов'язаний з метриками (див. нижче).

5) SLO-гейти і авто-відкат

• Технічні: `p95_latency`, `5xx_rate`, `error_budget_burn`, `CPU/Memory throttling`.
• Продуктові: 'CR (депозит)','успіх виплат','скоринг-фрода','ARPPU'( на холодних вікнах).

• Якщо'5xx _ rate'нової версії> 0. 5% протягом 10 хв - pause і rollback.
• Якщо'p95 _ latency'↑> 20% від базової - rollback.
• Якщо промоушен канарок йде, але SLO бюджету спалюється> 2 %/год - hold.

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: slo-guard }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

6) Дані і сумісність (найчастіша причина болю)

• Expand: додати нові nullable-колонки/індекси, підтримати обидві схеми.
• Migrate: подвійний запис/читання, бек-філ.
• Contract: видалити старі поля/код після виходу на 100% трафіку.
• Подієві/черги: версіонуйте payload (v1/v2), підтримуйте idempotency.
• Кеш/сесії: версіонуйте ключі; забезпечте сумісність формату.

7) Інтеграція з CI/CD і GitOps

CI: збірка єдиного артефакту (build once), підпис образу, SBOM, тести.
CD: промоушен артефакту через оточення; Blue-Green/Canary управляються маніфестами.
GitOps: мерж MR → контролер (Argo CD/Flux) застосовує ваги/селектора.
Environments/Approvals: для прод-степів - ручний gate + аудит рішень.

8) NGINX/Envoy і хмарні LB: Швидкі приклади

8. 1 NGINX (ваги апстрімів)

nginx upstream app_upstream {
server app-blue:8080 weight=90;
server app-green:8080 weight=10;
}
server {
location / { proxy_pass http://app_upstream; }
}

8. 2 AWS ALB (Weighted Target Groups)

TG-Blue: 90, TG-Green: 10 → змінюйте ваги через IaC/CLI.
Прив'яжіть CloudWatch-алерти до авто-скриптів rollback (зміна ваги на 0/100).

9) Безпека та відповідність

Zero trust між версіями: розмежуйте секрети/ролінг-ключі шифрування.
Policy-as-Code: заборона деплою непідписаних образів, «no latest».
Секрети і конфіги як артефакти версій; відкат включає відкат конфігів.
Аудит: хто, коли підняв вагу/перемкнув селектор, з яким тікетом.

10) Вартість і ємність

Blue-Green вимагає подвійної потужності на період релізу → плануйте вікно.
Canary може тягнутися довше → вартість телеметрії/спостереження, паралельний зміст двох версій.
Оптимізація: autoscaling по HPA/VPA, короткі вікна Blue-Green, нічні релізи для «важких» сервісів.

11) Відкати (runbook)

1. Заморозити просування (pause).
2. Знизити вагу Green до 0% (canary )/повернути селектор на Blue (blue-green).
3. Перевірити: помилки/латентність повернулися до базових, дренувати з'єднання.
4. Відкрити інцидент, зібрати артефакти (логи, траси, порівняння метрик).
5. Фікс/репрод в stage, прогнати smoke, перезапустити прогресію.

12) Анти-патерни

Перезбірка артефакту між stage і prod (порушення «build once»).
«Глухий» canary без SLO/метрик - формальність, а не захист.
Відсутність фіча-прапорів: реліз змушений включати поведінку відразу на 100%.
Непрацюючі health-checks/liveness → «залиплі» поди і помилкова стабільність.
Сумісність БД «на авось»: контракт ламається при перемиканні.
Мутабельні теги образів/' latest'в проді.

13) Чек-лист впровадження (0-45 днів)

0-10 днів

Вибрати стратегію для сервісів: B/G, Canary або комбіновано.
Включити підписання образів, health-checks, readiness-проби,'no latest'.
Підготувати дашборди SLO (latency/error rate/бізнес-метрики).

11-25 днів

Автоматизувати ваги (Istio/Argo Rollouts/ALB-weights).
Налаштувати analysis templates, алерти і авто-rollback.
Шаблонізувати маніфести (Helm/Kustomize), інтегрувати з GitOps.

26-45 днів

Впровадити стратегію expand-migrate-contract для БД.
Покрити критичні флоу kill-switch прапорами.
Провести «game day»: симулювати відкат і інцидент.

14) Метрики зрілості

% релізів через Blue-Green/Canary (мета> 90%).
Середній час перемикання/відкату (мета <3 хв).
Частка релізів з авто-стопом по SLO (і без інцидентів).
Покриття сервісів телеметрією (traces/logs/metrics)> 95%.
Частка міграцій БД за схемою expand-migrate-contract> 90%.

15) Додатки: шаблони політик і пайплайнів

OPA (заборона непідписаних образів)

rego package admission. image

deny[msg] {
input. request. kind. kind == "Deployment"
some c img:= input. request. object. spec. template. spec. containers[c].image not startswith(img, "ghcr. io/org/")
msg:= sprintf("Image not from trusted registry: %v", [img])
}

Helm-values для canary (спрощено)

yaml canary:
enabled: true steps:
- weight: 5 pause: 300
- weight: 25 pause: 600
- weight: 50 pause: 900 sloGuards:
max5xxPct: 0. 5 maxP95IncreasePct: 20

GitHub Actions - промоушен ваги (псевдо)

yaml
- name: Promote canary to 25%
run: kubectl patch virtualservice app \
--type=json \
-p='[{"op":"replace","path":"/spec/http/0/route/1/weight","value":25}]'

16) Висновок

Blue-Green і Canary - не взаємовиключні, а комплементарні стратегії. Будуйте їх поверх підписаних артефактів, спостережуваності по SLO, автоматичних гейтів і GitOps-управління. Відокремлюйте доставку від включення, тримайте швидкий відкат і дисципліну міграцій - і релізи стануть передбачуваними, безпечними і швидкими.