Qu'est-ce que le déploiement canari?

Le déploiement canari est une stratégie de lancement de nouvelles fonctionnalités, où la mise à jour est déployée progressivement à une petite partie des utilisateurs, puis, en l’absence de problèmes, étendue à l’ensemble de l’audience.

Étapes principales :

1. Déploiement du groupe canari : La nouvelle version de l’application est déployée sur un petit sous-ensemble de serveurs ou d’utilisateurs.
2. Surveillance : Une surveillance attentive des métriques (erreurs, performance, comportement utilisateur) est effectuée pour le groupe canari.
3. Extension ou rollback :
   • Si la surveillance indique un succès, le déploiement est progressivement étendu à un groupe plus large d’utilisateurs.
   • En cas de problème, le déploiement est reverté pour le groupe canari, protégeant la majorité des utilisateurs.

Avantages :

• Minimisation des risques : Les problèmes affectent un petit sous-ensemble d’utilisateurs.
• Rollback rapide : Facile de revenir à la version précédente.
• Test en conditions réelles : Évaluation du comportement de la nouvelle fonctionnalité sous charge réelle.

Inconvénients :

• Complexité de l’infrastructure : Nécessite le support de plusieurs versions de l’application en même temps.
• Gestion du trafic : Nécessite des mécanismes pour router le trafic vers différentes versions.
• Analyse des données : Nécessite une collecte et une analyse efficaces des métriques.

Exemple d’implémentation dans Kubernetes :

// Déploiement pour v1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 10 // Nombre principal
  selector:
    matchLabels:
      app: my-app
      version: v1
  template:
    metadata:
      labels:
        app: my-app
        version: v1
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v1

---

// Déploiement pour canari v2
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2-canary
spec:
  replicas: 1 // Groupe canari
  selector:
    matchLabels:
      app: my-app
      version: v2
  template:
    metadata:
      labels:
        app: my-app
        version: v2
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v2

---

// Service pour router le trafic (en utilisant des sélecteurs)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Pour gérer la répartition du trafic entre v1 et v2, on utilise des contrôleurs Ingress (par exemple, Nginx Ingress, Istio) avec la capacité de répartir le trafic de manière pondérée.