Blue-Green e Canary

Blue-Green e Canary

1) Attività e idee chiave

• Blue-Green: manteniamo due versioni parallele (Blue è attivo, Green è nuovo), spostiamo il traffico atomatico. Un rapido ritorno in tempo per restituire la Blue.
• Canary: includiamo la nuova versione in modo graduale (1% 5% 25% 50% 100%), il monitor delle metriche SLO e fermiamo/ritriamo in caso di degrado.

Il principio generale è quello di separare la «consegna del manufatto» da «attivazione del traffico» e automatizzare l'osservabilità + ritiri.

2) Quando scegliere

• Necessità di failover istantaneo (RTO rigidi), servizi di stato-less semplici;
• ci sono finestre di rilascio/congelamento rigorose e controlli comprensibili di smoke;
• È costoso mantenere una capacità doppia a lungo termine, ma è possibile.

• Cambiamenti complessi, è necessaria una validazione graduale sul traffico reale;
• c'è la telemetria matura (SLO, metriche di business), la possibilità di auto-stop;
• limitare in modo critico il raggio di impatto (flussi fintech/iGaming).

Combo-pattern: estrarre Green e spostarsi attraverso i gradini canary (Blue-Green come ossatura, Canary come metodo di trasferimento del traffico).

3) Architettura di instradamento del traffico

1. L4/L7-bilanciatore (ALB/NLB, Cloud Load Balanner) - target ponderati.

2. API gateway/WAF - route/weight per versioni, titoli, cookie, regioni.

3. Servizio Mesh (Istio/Linkerd/Consul) - distribuzione percentuale, iniezione fault, maniglie timeout/retrai/restrizioni.

4. Ingress/NGINX/Avvoy - peso upstream e routing per attributi.

5. Argo Rollouts/Flagger è un operatore controller, progressione automatica, integrazione con Prometheus/New Relic/Datadog.

4) Kubernets: modelli pratici

4. 1 Blue-Green (tramite Servizio selector)

Два Deployment: `app-blue` и `app-green`.
Un servizio «app-svc» con selettore per «versione».

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

Il cambio è un cambio atomico del selettore (o delle etichette) con un drain controllato.

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

Cambiare «weight» in scala; aggiungete retry, timeout, outlier-detector sul DestinationRule.

4. 3 Argo Rollouts (prova auto-canaria)

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

L'analisi mastro è associata alle metriche (vedere di seguito).

5) SLO-gate e auto-rientro

• Tecnico: «p95 _ latency», «5xx _ rate», «error _ budget _ burn», «CPU/Memory throttling».
• Prodotti: «CR (deposito)», «successo dei pagamenti», «screening frode», «ARPPU» (a finestre fredde).

• Se '5xx _ rat'nuova versione> 0. 5% per 10 min - pausa e rollback.
• Se p95 _ latency> il 20% della base è rollback.
• Se la promozione dei canari è in corso, ma il budget SLO viene bruciato> 2 %/ora - 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) Dati e compatibilità (la causa più frequente del dolore)

• Expand - Aggiungere nuove colonne/indici nullabili, supportare entrambi gli schemi.
• Migrate: doppia scrittura/lettura, back-fill.
• Contract - Rimuovi i vecchi campi/codice dopo l'uscita al 100% del traffico.
• Eventi/code: versionare payload (v1/v2), supportare idempotency.
• Cache/sessione: versionare le chiavi; garantire la compatibilità del formato.

7) Integrazione con CI/CD e GitOps

CI - Assemblaggio di un unico artefatto (build once), firma dell'immagine, SBOM, test.
CD: promozione dell'artefatto attraverso gli ambienti Blue-Green/Canary è gestito da manifesti.
: il controller mierge MR (Argo CD/Flux) applica peso/selettore.
Environments/Approvals: per le protesi - gate manuale + verifica delle soluzioni.

8) NGINX/Avvoy e cloud LB: esempi rapidi

8. 1 NGINX (peso upstream)

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 → il peso attraverso il IaC/CLI.
Aggancia CloudWatch-alert agli script auto rollback (cambio di peso 0/100).

9) Sicurezza e conformità

Zero trust tra le versioni: separa i segreti/le chiavi di crittografia rolling.
Policy-as-Code - Disattiva i display di immagini non firmate, 'no latest'.
Segreti e configi come artefatti di versioni; Il ripristino include il ripristino delle configurazioni.
Controllo: chi, quando ha alzato il peso/cambiato il selettore, con quale ticchetto.

10) Costo e capacità

Blue-Green richiede potenza doppia per il periodo di rilascio e pianifica la finestra.
Canary può durare più a lungo il costo della telemetria/osservazione, il contenuto parallelo di due versioni.
Ottimizzazione: autoscaling HPA/VPA, brevi finestre Blue-Green, release notturne per i servizi «pesanti».

11) Rimborsi (runbook)

1. Congelare la promozione (pausa).
2. Riduce il peso di Green a 0% (canary )/ripristina il selettore su Blue (blue-green).
3. Verifica: gli errori/latitanza sono tornati alle connessioni di base, drenare le connessioni.
4. Aprire l'incidente, raccogliere gli artefatti (fogli, piste, paragoni di metriche).
5. Fix/riprod in stage, scovare smoke, riavviare la progressione.

12) Anti-pattern

Intersezione del manufatto tra stage e prod (violazione «build once»).
«Sordo» canary senza SLO/metriche è una formalità, non una protezione.
Assenza di flag fich: il lancio deve includere il comportamento al 100%.
Health-checks/liveness non funzionanti: sottovuoto e falsa stabilità.
Compatibilità DB su asse: il contratto si rompe durante il cambio.
Tag di immagine mutabili/latest in vendita.

13) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Scegli una strategia per i servizi B/G, Canary o combinata.
Abilita la firma di immagini, health-checks, readì provini, «no latest».
Prepara i dashboard SLO (latency/error rate/metriche aziendali).

11-25 giorni

Automatizza pesi (Istio/Argo Rollouts/ALB-weights).
Personalizza analisi templates, alert e auto-rollback.
Modella manifesti (Helm/Kustomize), integra con GitOps.

26-45 giorni

Implementare la strategia expand-migrate-contract per il database.
Copre flow kill-switch critici con bandiere.
Fare «game day» per simulare il ritorno e l'incidente.

14) Metriche di maturità

% di release tramite Blue-Green/Canary (obiettivo> 90%).
Tempo medio di cambio/rimozione (obiettivo <3 min).
Percentuale di rilasci con auto-stop SLO (e senza incidenti).
Copertura di telemetria (traces/logs/metrics)> 95%.
Percentuale di migrazioni DB in modalità expand-migrate-contract> 90%.

15) Applicazioni: modelli di regole e pipline

OPA (disabilitazione delle immagini non firmate)

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 per canary (semplificato)

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

GitHub Action - promozione del peso (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) Conclusione

Blue-Green e Canary non sono strategie complementari, ma complementari. Costruiscili sopra i manufatti firmati, osservabilità SLO, gate automatici e controllo GitOps. Separare le consegne dall'inclusione, mantenere il rapido ritorno e la disciplina delle migrazioni e le release diventeranno prevedibili, sicure e veloci.