Niebiesko-zielone i kanaryjskie wdrożenie

Niebiesko-zielone i kanaryjskie wdrożenie

1) Wyzwanie i kluczowe pomysły

• Niebiesko-zielony: zachować dwie równoległe wersje (niebieski - aktywny, zielony - nowy), przełączać ruch atomowo. Szybki zwrot → natychmiast powrót niebieski.
• Kanarka: włącz nową wersję w etapach (1% → 5% → 25% → 50% → 100%), monitoruj mierniki SLO i zatrzymaj/zwiń z powrotem podczas degradacji.

Ogólna zasada polega na oddzieleniu „dostawy artefaktu” od „włączenia ruchu” i zautomatyzowaniu obserwowalności + wałków.

2) Kiedy wybrać

• potrzebują natychmiastowego przełączania (hard RTO), prostych usług bezpaństwowych;
• istnieją ścisłe okna uwalniania/zamrażania oraz wyraźne kontrole dymu;
• jest drogie, aby utrzymać długą podwójną pojemność - ale jest to możliwe przez krótki czas.

• wymagane są złożone zmiany, stopniowe zatwierdzanie rzeczywistego ruchu;
• istnieje dojrzała telemetria (SLO, metryki biznesowe), funkcja automatycznego zatrzymywania;
• krytycznie ograniczyć promień uszkodzeń (strumienie fintech/iGaming).

Wzór Combo: rozwałkować Zielony i przełączyć się do niego przez kanaryjskie etapy (Niebiesko-Zielony jako rama, Kanaryjski jako metoda przewożenia ruchu).

3) Architektura tras ruchu

1. L4/L7 balancer (ALB/NLB, Cloud Load Balancer) - ważone grupy docelowe.

2. Brama API/WAF - trasa/waga według wersji, nagłówków, plików cookie, regionów.

3. Siatka serwisowa (Istio/Linkerd/Consul) - rozkład procentowy, wtrysk usterki, timeout/retray/uchwyty ograniczające.

4. Ingress/NGINX/Envoy - wagi górne i trasa atrybutów.

5. Argo Rollouts/Flagger - kontroler operatora, automatyczny postęp, integracja z Prometheus/New Relic/Datadog.

4) Kubernetes: praktyczne szablony

4. 1 Niebiesko-zielony (za pośrednictwem selektora serwisowego)

Два Rozmieszczenie: 'app-blue', 'app-green'.
Jedna usługa 'app-svc' z selektorem dla żądanej' wersji '.

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}]

Przełączanie - atomowa zmiana selektora (lub etykiet) z kontrolowanym drenażem.

4. 2 Kanaryjskie (Istio Virti Service)

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

Zmień „wagę” krok po kroku; dodać retry, timeout, outlier-detector do reguły.

4. 3 Argo Rollouts (Auto Canary Run)

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"]

Analiza szablonu jest związana z metrykami (patrz poniżej).

5) Bramy SLO i automatyczne rolki

• Techniczne: 'p95 _ latency', '5xx _ rate', 'error _ budget _ burn',' CPU/Memory throttling '.
• Produkty spożywcze: „CR (depozyt)”, „sukces płatności”, „oszustwo punktowe”, „ARPPU” (na zimnych oknach).

• Jeśli '5xx _ rate' nowej wersji jest> 0. 5% na 10 min - pauza i zwrot.
• Jeśli 'p95 _ latency', na plecach jest> 20% podstawy - wałek.
• Jeśli promocja kanaryjska idzie, ale budżet SLO spala się> 2 %/godzinę - wstrzymaj.

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) Dane i zgodność (najczęstsza przyczyna bólu)

• Rozwiń: dodaj nowe nieważne kolumny/indeksy, wesprzyj oba schematy.
• Migracja: Podwójne pisanie/czytanie, wypełnianie pleców.
• Umowa: usunąć stare pola/kod po wyjściu 100% ruchu.
• Zdarzenie/kolejki: ładowność wersji (v1/v2), wsparcie idempotencji.
• Pamięć podręczna/sesje: klucze wersji; Zapewnić kompatybilność formatu.

7) Integracja z CI/CD i GitOps

CI: zbudować raz, sygnaturę obrazu, SBOM, testy.
CD: promocja artefaktu poprzez środowisko; Niebiesko-Zielony/Kanaryjski rządzą manifestami.
GitOps: MR → kontroler (Argo CD/Flux) stosuje wagi/selektory.
Środowiska/Zatwierdzenia: dla etapów produkcji - brama manualna + decyzje audytowe.

8) NGINX/Wysłannik i LBs w chmurze: Szybkie przykłady

8. 1 NGINX (wagi górne)

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 (ważone grupy docelowe)

TG-Blue: 90, TG-Green: 10 → zmiana ciężarów poprzez IaC/CLI.
Link CloudWatch alerty do auto skrypty rollback (zmiana wagi do 0/100).

9) Bezpieczeństwo i zgodność

Zero zaufania między wersjami: odróżnić sekrety szyfrowania/klucze rollingowe.
Policy-as-Code: disallow unsigned image deploy, 'no latest'.
Sekrety i konfiguracje jako artefakty wersji; Rollback zawiera wałek konfiguracji.
Audyt: kto, kiedy podniósł wagę/włączył selektor, z jakim biletem.

10) Koszt i zdolność produkcyjna

Niebiesko-zielony wymaga podwójnej mocy na okres wydania → zaplanować okno.
Canary może trwać dłużej → koszt telemetrii/nadzoru, równoległa zawartość dwóch wersji.
Optymalizacja: autoskalowanie przez HPA/VPA, krótkie okna Blue-Green, nocne wydania dla „ciężkich” usług.

11) Książki startowe

1. Wstrzymaj awans.
2. Zmniejszyć zieloną wagę do 0% (kanarka )/selektor powrotu do niebieskiego (niebiesko-zielony).
3. Sprawdź: błędy/opóźnienia powróciły do podstawowych połączeń spustowych.
4. Otwórz incydent, zbierz artefakty (dzienniki, tory, porównanie metryk).
5. Naprawić/upomnieć do etapu, prowadzić dym, ponownie rozpocząć progresję.

12) Anty-wzory

Odbudowa artefaktu pomiędzy sceną a prod (naruszenie „zbudować raz”).
„Głuchy” kanarek bez SLO/metryki to formalność, a nie obrona.
Brak flag funkcji: wydanie jest zmuszone do włączenia zachowania w 100% naraz.
Niekontrolowane kontrole zdrowia/los → „lepkie” dna i fałszywa stabilność.
Kompatybilność bazy danych „losowo”: umowa przerywa się podczas przełączania.
Mutable image tags/' latest 'w prod.

13) Lista kontrolna wdrażania (0-45 dni)

0-10 dni

Wybierz strategię dla usług: B/G, Canary lub w połączeniu.
Włącz podpisywanie obrazu, kontrole zdrowia, próbki gotowości, 'brak najnowszych'.
Przygotuj deski rozdzielcze SLO (prędkość opóźnienia/błędu/wskaźniki biznesowe).

11-25 dni

Wagi automatyczne (wagi Istio/Argo Rollouts/ALB).
Konfiguruj szablony analiz, alerty i auto-rollback.
Manifesty szablonów (Helm/Kustomize), zintegrować z GitOps.

26-45 dni

Wdrożenie strategii rozszerzania umowy o migrację dla bazy danych.
Pokryć krytyczne flagi przełącznika.
Spędzić „dzień gry”: symulować rollback i incydent.

14) Wskaźniki zapadalności

% wydań za pośrednictwem Blue-Green/Canary (cel> 90%).
Średni czas przełączania/wstecznego (cel <3 min).
Udział zwolnień z automatycznym zatrzymaniem SLO (i bez incydentów).
Pokrycie usług za pomocą telemetrii (śladowe/kłody/mierniki)> 95%.
Udział migracji DB zgodnie z programem umów o rozszerzenie i migrację wynosi> 90%.

15) Załączniki: Szablony zasad i rurociągów

OPA (wyłączyć niezapisane obrazy)

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])
}

Wartości helmowe dla kanarka (uproszczone)

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

Działania GitHub - promocja wagi (pseudo)

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) Wniosek

Niebiesko-zielone i kanaryjskie nie wykluczają się wzajemnie, lecz uzupełniają strategie. Zbuduj je na szczycie podpisanych artefaktów, obserwowalności SLO, automatycznych bram i kontroli GitOps. Oddziel dostawę od włączenia, zachowaj szybki zwrot i dyscyplinę migracji - a wydania stają się przewidywalne, bezpieczne i szybkie.