45. Continuous Deployment strategie (blue-green, canary, rolling)

Úvod a kontext

Mít pipeline, která automaticky sestaví a otestuje novou verzi
aplikace, je jen půlka práce — druhá půlka je bezpečně ji dostat do
produkce, aniž by uživatelé zaznamenali výpadek nebo aniž by chybná
verze způsobila velkou škodu, než si jí někdo všimne. Existuje několik
zavedených nasazovacích strategií, každá s jiným kompromisem mezi
rychlostí, náklady na infrastrukturu a rizikem.

Teorie

Rolling update (postupná aktualizace)

Nejběžnější, výchozí strategie v Kubernetes Deploymentech (viz dřívější
lekce o Deploymentech): staré instance se postupně nahrazují novými, po
malých dávkách, s health checks kontrolujícími, že nová instance je
skutečně zdravá dřív, než se ukončí další stará.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # kolik replik smí být dočasně nedostupných
      maxSurge: 1          # kolik replik navíc smí dočasně přibýt

Výhody: nevyžaduje extra infrastrukturu navíc (jen dočasně o pár
replik víc), plynulé nasazení bez výpadku. Nevýhody: po dobu
nasazení běží současně stará i nová verze vedle sebe — pokud nejsou
vzájemně kompatibilní (např. nekompatibilní schéma databáze), může to
způsobit problémy. Rollback vyžaduje stejný postupný proces obráceně,
takže není okamžitý.

Blue-green deployment

Existují dvě kompletní, identické produkční prostředí — blue
(aktuálně aktivní, přijímá veškerý provoz) a green (nová verze,
zatím bez provozu). Nová verze se nasadí a otestuje kompletně na green,
a teprve když je ověřeno, že funguje, se provoz přepne (typicky změnou
routování na load balanceru nebo Service) z blue na green najednou.

Před přepnutím:      Load Balancer → [BLUE  v1.4]  (aktivní)
                                      [GREEN v1.5]  (připraveno, bez provozu)

Po přepnutí:         Load Balancer → [GREEN v1.5]  (aktivní)
                                      [BLUE  v1.4]  (ponecháno pro rychlý rollback)

Výhody: přepnutí je okamžité, rollback je stejně okamžitý (přepnutí
zpět na blue). Nová verze je plně otestovaná v produkčním prostředí
ještě před tím, než dostane reálný provoz. Nevýhody: vyžaduje
dvojnásobek infrastruktury (obě prostředí musí běžet současně, alespoň
dočasně) — nákladnější, a databázové migrace musí být kompatibilní s
oběma verzemi současně.

Canary release

Nová verze se nasadí vedle staré, ale zpočátku dostává jen malý podíl
reálného provozu (např. 5 %) — zbytek jde dál na starou, ověřenou
verzi. Pokud metriky (chybovost, latence) u nové verze vypadají zdravě,
podíl provozu se postupně zvyšuje (5 % → 25 % → 50 % → 100 %); pokud se
objeví problém, provoz se okamžitě vrátí zpět na starou verzi a jen
malý zlomek uživatelů byl zasažen.

# koncept v Kubernetes bez servisní mesh — dvě sady Podů se stejným
# selektorem Service, s různým poměrem počtu replik
# (v praxi se pro jemnější řízení procent používá Service Mesh
#  jako Istio, nebo nástroje jako Argo Rollouts/Flagger)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-stable
spec:
  replicas: 9      # 90 % provozu (poměr replik ≈ poměr provozu)
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web, track: stable }
    spec:
      containers: [{ name: web, image: myapp:1.4.0 }]
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-canary
spec:
  replicas: 1      # 10 % provozu
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web, track: canary }
    spec:
      containers: [{ name: web, image: myapp:1.5.0 }]

Obě sady Podů sdílejí stejnou app: web label, takže je jedna Service
routuje dohromady — poměr replik zhruba odpovídá poměru provozu.
Výhody: minimalizuje dopad chyby na malý podíl uživatelů,
umožňuje ověřit novou verzi na reálném provozu s reálnými daty.
Nevýhody: složitější na řízení přesných procent a na sledování
metrik odděleně po verzích — v produkčním nasazení se proto často
používá specializovaný nástroj (service mesh nebo Argo Rollouts).

Srovnání a volba strategie

Strategie	Rychlost rollbacku	Extra infrastruktura	Riziko dopadu chyby
Rolling	pomalejší (postupný)	minimální	střední (najednou víc uživatelů)
Blue-green	okamžitý	dvojnásobná (dočasně)	nízké (testováno před přepnutím)
Canary	okamžitý (přepnutí provozu zpět)	mírně vyšší	nejnižší (jen malý podíl uživatelů)

Volba závisí na kritičnosti aplikace, dostupném rozpočtu na
infrastrukturu a vyspělosti monitoringu — canary vyžaduje dobré metriky
v reálném čase, aby bylo možné rychle poznat, že nová verze je
problematická.

Praktický příklad

Ukázka rolling update v praxi s Kubernetes a sledováním průběhu:

# nastavení nové verze image v existujícím Deploymentu
kubectl set image deployment/web web=myapp:1.5.0

# sledování průběhu rolling update
kubectl rollout status deployment/web
# Waiting for deployment "web" rollout to finish: 2 out of 5 new
# replicas have been updated...
# deployment "web" successfully rolled out

# pokud se ukáže problém, okamžitý návrat k předchozí verzi
kubectl rollout undo deployment/web

# historie nasazení pro audit
kubectl rollout history deployment/web

Shrnutí

Rolling update postupně nahrazuje staré instance novými bez extra
infrastruktury, ale rollback je pomalejší a obě verze běží krátce
současně. Blue-green udržuje dvě kompletní prostředí a přepíná provoz
najednou, s okamžitým rollbackem, za cenu dvojnásobné infrastruktury.
Canary release pouští novou verzi jen na malý podíl provozu a postupně
ho zvyšuje podle naměřených metrik, čímž minimalizuje dopad případné
chyby na nejmenší možný počet uživatelů. Volba strategie je kompromis
mezi rychlostí rollbacku, náklady a rizikem.

Kontrolní otázky

1. Proč je rollback u blue-green deploymentu rychlejší než u rolling
   update?
2. Jaké riziko nese to, že u rolling update běží krátce vedle sebe
   stará i nová verze aplikace?
3. Jak canary release minimalizuje dopad chyby v nové verzi ve
   srovnání s rolling update, který nasadí novou verzi na všechny
   uživatele postupně, ale bez řízeného procenta provozu?
4. Mini cvičení: pro Deployment s 10 replikami navrhněte konkrétní
   canary plán (jaké procento provozu/kolik replik v jednotlivých
   krocích) od 5 % do 100 %, včetně toho, co byste sledovali mezi
   jednotlivými kroky, než přejdete na další.