Déploiements in-place et blue/green

Automatiser les déploiements sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

La panne de 2 h du matin

• Déploiement d'un coup qui tourne mal
• Chaque serveur exécute la version cassée
• Les clients voient des erreurs pendant une heure
• Le retour arrière exige un nouveau déploiement complet

Pourquoi la stratégie de déploiement compte

• Une mauvaise release peut mettre un service hors ligne
• Tout d'un coup = le plus rapide, le plus risqué
• Déploiement progressif = plus lent, plus sûr
• La stratégie limite le périmètre d'impact en cas d'échec

Déploiements in-place

• Déployer sur les mêmes instances qui servent le trafic
• Par lots successifs : moitié-moitié, ou une par une
• Vérifier la santé de chaque lot avant de continuer
• Peu coûteux ; pas d'infra supplémentaire

Déploiements blue/green

• Blue = flotte de production actuelle
• Green = nouvelle flotte avec la nouvelle version
• Le load balancer bascule le trafic de blue vers green
• L'ancienne flotte reste dispo pour un rollback rapide

Lambda et ECS sont blue/green par conception

• Lambda : le trafic bascule via un alias de version
• ECS : le trafic bascule via un jeu de tâches de remplacement
• Pas de duplication de flotte façon EC2 requise
• Vous choisissez quand même une configuration de déploiement

Choisir in-place ou blue/green

• Budget serré, correctif à faible risque → in-place
• Besoin de zéro interruption ou rollback instantané → blue/green
• Serveur hérité unique → in-place seul possible
• Lambda ou ECS → le blue/green est natif

Rollback dans CodeDeploy

• Rollback = redéployer la révision précédente réussie
• Déclenchement auto en cas d'échec du déploiement
• Déclenchement auto sur alarme CloudWatch
• En blue/green : rebasculez le load balancer

Passons à la pratique !

Automatiser les déploiements sur AWS