Deployment strategies: blue/green - canary - rolling

1. Choisir une stratégie #

Risque, coût et vitesse de retour arrière.

Comparaison #

2. Mise en œuvre #

Services pondérés et bascule.

Canary avec le provider fichier #

http:
  services:
    app:
      weighted:
        services:
          - name: app-v1@docker
            weight: 90
          - name: app-v2@docker
            weight: 10
        sticky:
          cookie: { name: version }      # un utilisateur reste sur la même version
  routers:
    app:
      rule: Host(`app.exemple.fr`)
      service: app

Canary dans Kubernetes (TraefikService) #

apiVersion: traefik.io/v1alpha1
kind: TraefikService
metadata: { name: app-canary, namespace: app }
spec:
  weighted:
    services:
      - { name: app-v1, port: 80, weight: 90 }
      - { name: app-v2, port: 80, weight: 10 }

Blue/green et mirroring #

Pour le blue/green, on change le service ciblé par le routeur (app-blue → app-green) ; avec le provider fichier, la bascule est prise en compte à chaud. Le mirroring copie une part du trafic vers une version de test :

http:
  services:
    app-miroir:
      mirroring:
        service: app-v1@docker
        mirrors:
          - { name: app-v2@docker, percent: 20 }

3. Bonnes pratiques #

Déployer sans crainte.

Règles #

• Définir à l'avance les critères de réussite (taux d'erreurs, latence p95) et les surveiller par service.
• Rendre les migrations de base de données compatibles avec les deux versions (expand / contract).
• Automatiser la progression et le retour arrière plutôt que modifier les poids à la main : c'est le rôle de Flagger (article suivant).
• Health checks sur les services pour que Traefik retire automatiquement une instance défaillante.