Blue-Green et Canary déplay

Blue-Green et Canary deploy

1) Tâche et idées clés

• Blue-Green : nous tenons deux versions parallèles (Blue est actif, Green est nouveau), nous passons au trafic atomique. Un retour rapide → récupérer Blue instantanément.
• Canary : nous incluons la nouvelle version par étapes (1 % → 5 % → 25 % → 50 % → 100 %), nous surveillons les métriques SLO et nous arrêtons/reculons en cas de dégradation.

Principe général : séparer la « livraison de l'artefact » de la « mise en circulation » et automatiser l'observation + les retraits.

2) Quand quoi choisir

• besoin de commutation instantanée (RTO rigides), des services d'état simples ;
• il y a des fenêtres de sortie/gel strictes et des vérifications compréhensibles de smoke ;
• il est coûteux de conserver une capacité double à long terme - mais vous pouvez brièvement.

• les changements complexes, une validation progressive sur le trafic réel est nécessaire ;
• il y a la télémétrie mature (SLO, métriques d'affaires), la possibilité de l'auto-stop ;
• il est critique de limiter le rayon d'impact (flux fintech/iGaming).

Modèle combo : faire rouler le vert et passer à l'étape canaire (Bleu-Vert comme cadre, Canary comme méthode de transfert du trafic).

3) L'architecture de routage du trafic

1. L'équilibreur L4/L7 (ALB/NLB, Cloud Load Balancer) est un groupe de target pondéré.

2. API passerelle/WAF - route/weight par versions, en-têtes, cookies, régions.

3. Service Mesh (Istio/Linkerd/Consul) - distribution en pourcentage, fault-injection, stylos de temporisation/retraits/restrictions.

4. Ingress/NGINX/Envoy - poids upstream et routage par attributs.

5. Argo Rollouts/Flagger - opérateur-contrôleur, progression automatique, intégration avec Prometheus/New Relic/Datadog.

4) Kubernetes : modèles pratiques

4. 1 Bleu-Vert (via le sélecteur de service)

Два Deployment: `app-blue` и `app-green`.
Un service 'app-svc' avec un sélecteur pour la version souhaitée.

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

Commutation - Changement atomique du sélecteur (ou des étiquettes) avec drain contrôlé.

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

Changez 'weight' en marches ; ajoutez retry, timeout, outlier-detector sur DestinationRule.

4. 3 Argo Rollouts (course auto-canarienne)

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'analyse-modèle est liée aux métriques (voir ci-dessous).

5) SLO-gates et auto-retour

• Technique : 'p95 _ latency', '5xx _ rate', 'error _ budget _ burn', 'CPU/Memory throttling'.
• Produits : 'CR (dépôt)', 'succès de paiement', 'scoring froda', 'ARPPU' (sur les fenêtres froides).

• Si '5xx _ rate'nouvelle version> 0. 5 % pendant 10 min - pause et rollback.
• Si 'p95 _ latency' ↑> 20 % de la base est rollback.
• Si la promotion Canaries est en cours, mais le SLO du budget est brûlé> 2 %/heure - 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) Données et compatibilité (la cause la plus fréquente de douleur)

• Expand : ajoutez de nouvelles colonnes/index nullables, supportez les deux schémas.
• Migrate : double écriture/lecture, back-fill.
• Contrat : supprimer les anciens champs/code après la sortie sur 100 % du trafic.
• Evénement/files d'attente : versez payload (v1/v2), supportez idempotency.
• Cache/sessions : convertir les clés ; assurer la compatibilité du format.

7) Intégration avec CI/CD et GitOps

CI : assemblage d'un artefact unique (build once), signature d'image, SBOM, tests.
CD : promotion de l'artefact à travers l'environnement ; Blue-Green/Canary sont régis par des manifestes.
GitOps : merge MR → contrôleur (Argo CD/Flux) applique le poids/sélecteur.
Environments/Approvals : pour les steppes pro - gate + audit manuel des solutions.

8) NGINX/Envoy et cloud LB : exemples rapides

8. 1 NGINX (poids des aptrimes)

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-Vert : 10 → changer de poids via IaC/CLI.
Liez CloudWatch-alertie aux scripts auto rollback (changement de poids de 0/100).

9) Sécurité et conformité

Zero trust entre les versions : délimitez les secrets/clés de chiffrement.
Policy-as-Code : Interdiction du dépliage d'images non signées, « no latest ».
Secrets et confidences comme artefacts de versions ; le repli comprend le repli des fligs.
Audit : qui, quand il a augmenté le poids/changé le sélecteur, avec quel tiquet.

10) Coût et capacité

Blue-Green nécessite une double puissance pour la période de sortie → planifiez une fenêtre.
Canary peut durer plus longtemps → le coût de la télémétrie/observation, le contenu parallèle des deux versions.
Optimisation : autoscaling par HPA/VPA, fenêtres brèves Blue-Green, sorties nocturnes pour les services « lourds ».

11) Retours (runbook)

1. Geler la promotion (pause).
2. Réduire le poids Vert à 0 % (canary )/ramener le sélecteur à Bleu (blue-green).
3. Vérifier : erreurs/latence est retourné à la base, drainer les composés.
4. Ouvrir l'incident, collecter les artefacts (logs, pistes, comparaison des métriques).
5. Fix/reprise dans stage, chasser le smoke, redémarrer la progression.

12) Anti-modèles

L'artefact entre la scène et la prod (violation de « build once »).
Un canary « sourd » sans SLO/métrique est une formalité, pas une protection.
L'absence de drapeaux ficha : la sortie doit inclure un comportement à 100 % à la fois.
Health-checks/liveness non fonctionnels → pods « bouffés » et fausse stabilité.
Compatibilité OBD'par l'axe ": le contrat se brise lors de la commutation.
Balises d'image mutables/' latest 'dans la vente.

13) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Choisir une stratégie pour les services : B/G, Canary ou combiné.
Activer la signature des images, des tests de santé, des tests de lecture, « no latest ».
Préparer les dashboards SLO (taux de latence/erreur/métriques d'entreprise).

11-25 jours

Automatiser les poids (Istio/Argo Rollouts/ALB-weights).
Configurer analysis templates, alertes et auto-rollback.
Modèle de manifeste (Helm/Kustomize), intégration avec GitOps.

26-45 jours

Mettre en œuvre une stratégie expand-migratoire-contract pour les bases de données.
Couvrir le flow critique de kill-switch avec des drapeaux.
Passer « game day » : simuler un retour en arrière et un incident.

14) Métriques de maturité

% de sorties via Blue-Green/Canary (objectif> 90 %).
Temps moyen de commutation/retour (cible <3 min).
Proportion de sorties avec auto-stop sur SLO (et sans incident).
Couverture des services par télémétrie (traces/logs/metrics)> 95 %.
La part des migrations OBD dans le schéma expand-migrate-contract> 90 %.

15) Applications : Modèles de stratégies et de piplines

OPA (interdiction des images non signées)

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

Valeur d'aide pour canary (simplifiée)

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 - Promotion de poids (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) Conclusion

Blue-Green et Canary ne sont pas des stratégies mutuellement exclusives, mais complémentaires. Construisez-les au-dessus des artefacts signés, de l'observabilité SLO, des gats automatiques et du contrôle GitOps. Séparez la livraison de l'inclusion, gardez le retour rapide et la discipline des migrations - et les sorties deviendront prévisibles, sûres et rapides.