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 - нұсқалары, тақырыптары, cookie, өңірлері бойынша route/weight.

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`.
Қажет 'version' селекторы бар бір 'app-svc' Service.

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' дегенді өзгертіңіз; DestinationRule бағдарламасына retry, timeout, outlier-detector қосыңыз.

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. 10 минут ішінде 5% - 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 ұзағырақ созылуы мүмкін → телеметрия/бақылау құны, екі нұсқаның параллель мазмұны.
Оңтайландыру: HPA/VPA бойынша autoscaling, Blue-Green қысқа терезелері, «ауыр» сервистер үшін түнгі релиздер.

11) Қайтарулар (runbook)

1. Жылжуды тоқтату (pause).
2. Green салмағын 0% (canary) дейін азайту/селекторды Blue (blue-green) дегенге қайтару.
3. Тексеру: қателер/жасырындылық қосылымдарды дренаждау үшін базалық қатеге оралды.
4. Инцидентті ашу, артефактілерді жинау (логтар, трассалар, метриктерді салыстыру).
5. stage-дегі фикс/репрод, smoke-ді айдап, прогресті қайта іске қосу.

12) Қарсы үлгілер

Артефактіні stage және prod арасында қайта іріктеу («build once» бұзылуы).
SLO/метриксіз «саңырау» canary - қорғаныш емес, формалдық.
Фич-жалаушалардың жоқтығы: шығарылым мінез-құлықты бірден 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])
}

canary үшін Helm-values (оңайлатылған)

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-басқарудың үстінен салыңыз. Жеткізуді қосудан бөліңіз, тез кері қайтаруды және көші-қон тәртібін ұстаңыз - релиздер болжамды, қауіпсіз және жылдам болады.