Changer l’AMI qu’utilisent vos instances revient à changer les fondations de votre service pendant qu’il tourne. Mal fait, cela signifie des coupures ; bien fait, c’est presque invisible pour l’utilisateur. La bonne nouvelle : il existe des motifs éprouvés qui rendent cette migration sûre et réversible.
La base commune est de ne pas modifier des instances vivantes, mais de lancer de nouvelles instances avec la nouvelle AMI et de déplacer le trafic de façon contrôlée.
Avant de migrer : préparez le terrain
- Testez la nouvelle AMI dans un environnement de pré-production identique à la production.
- Health checks fiables : définissez des contrôles qui confirment qu’une nouvelle instance est réellement saine.
- Plan de rollback : ayez prêts la version précédente et la procédure pour y revenir.
- Observabilité : métriques et alertes pour détecter les régressions à l’instant.
Stratégies de migration sans interruption
| Stratégie | Fonctionnement | Idéale pour |
|---|---|---|
| Rolling update | Remplace les instances par lots, petit à petit | Services en Auto Scaling Group |
| Blue/Green | Vous montez un nouvel environnement et basculez le trafic d’un coup | Migrations avec rollback instantané |
| Canary | Vous envoyez un faible pourcentage de trafic à la nouvelle version | Valider en production à faible risque |
Trois motifs pour changer d’AMI sans interrompre le service.
Rolling update
Vous mettez à jour le Launch Template avec la nouvelle AMI et l’Auto Scaling Group remplace les instances par vagues : il en lance de nouvelles, attend qu’elles passent le health check et retire les anciennes. Simple et sans infrastructure supplémentaire, même si les deux versions cohabitent un moment.
Blue/Green
Vous montez un environnement parallèle (green) avec la nouvelle AMI pendant que l’actuel (blue) continue de servir. Une fois green validé, vous redirigez le trafic au niveau de l’équilibreur ou du DNS. Si quelque chose échoue, vous revenez à blue en quelques secondes. C’est le motif au rollback le plus rapide, au prix d’un doublement temporaire des ressources.
Canary
Vous envoyez une petite fraction du trafic vers des instances portant la nouvelle AMI et vous observez. Si les métriques tiennent, vous augmentez le pourcentage progressivement jusqu’à 100 %. Cela minimise le rayon d’impact d’un problème inattendu.
Après la migration
- Surveillez métriques et logs pendant une durée raisonnable avant de valider la migration.
- Marquez l’ancienne AMI comme obsolète pour qu’elle ne soit pas relancée par erreur.
- Documentez la version déployée et la raison du changement.
- Ne supprimez pas l’image précédente tout de suite : gardez-la au cas où un rollback serait nécessaire.
Questions fréquentes
Quelle stratégie est la meilleure pour zéro interruption ?
Blue/Green offre le rollback le plus rapide ; le rolling update est plus simple et plus économique ; le canary minimise le risque en validant en production. Le choix dépend de votre tolérance au risque et de votre budget d’infrastructure.
Dois-je doubler l’infrastructure pour migrer ?
Seulement avec blue/green, et de façon temporaire. Avec un rolling update ou un canary, vous réutilisez le même groupe et remplacez les instances au fil de l’eau, sans dupliquer tout l’environnement.
Comment garantir de pouvoir revenir en arrière ?
Conservez l’AMI précédente et son Launch Template, définissez des health checks fiables et testez la procédure de rollback avant de commencer la migration.
Chez imaxe.cloud, nous versionnons nos images pour que migrer d’une version à l’autre soit prévisible et réversible.
