Automatiser les tests de bascule du chaos engineering dans les pipelines CI/CD AWS

Un tutoriel technique détaillé, publié le 2 novembre 2026, démontre comment intégrer directement des tests de fiabilité automatisés dans les workflows d'intégration et de déploiement continus. Le guide, rédigé par Gbenga Ogbonyenitan pour DEV Community, accompagne les ingénieurs pas à pas dans l'utilisation d'AWS Fault Injection Service (FIS) pour arrêter intentionnellement des tâches de conteneurs et vérifier que le système se rétablit dans des délais acceptables.

Ce qui s'est passé

L'article propose une implémentation étape par étape d'un modèle de chaos engineering où un pipeline déploie un service, casse délibérément l'un de ses composants actifs, puis valide que l'infrastructure se répare elle-même. La configuration utilise Amazon ECS (Elastic Container Service) avec Fargate, un Application Load Balancer et AWS CodePipeline. L'innovation principale réside dans l'ajout d'une étape "FailoverTest" exécutée après le déploiement, garantissant que chaque version est accompagnée d'une preuve de résilience.

Le processus comprend deux phases principales : la construction de l'infrastructure sous-jacente du service et la configuration du mécanisme d'injection. Tout d'abord, l'ingénieur configure les groupes de sécurité, les groupes de cibles et le load balancer pour gérer le trafic. Ensuite, il configure FIS pour cibler des tâches ECS spécifiques. Le tutoriel souligne qu'il ne s'agit pas seulement de casser des choses, mais de mesurer le temps de récupération par rapport à un seuil prédéfini, tel que 300 secondes. Si le service ne revient pas à un état sain dans ce délai, le pipeline échoue, empêchant ainsi que des configurations potentiellement instables soient considérées comme réussies.

L'auteur note que bien que la démonstration utilise un simple serveur web nginx, le modèle est conçu pour des applications réelles. En automatisant ce test, les équipes passent de l'hypothèse selon laquelle leur conception haute disponibilité fonctionne à la preuve de son efficacité à chaque nouvelle version. Le guide inclut à la fois une approche manuelle basée sur la console pour l'apprentissage et une approche basée sur CloudFormation pour une infrastructure as code prête pour la production.

Détails clés

• Le pipeline se compose de trois étapes : Source, Deploy et FailoverTest, la dernière étape exécutant l'expérience de chaos.
• AWS Fault Injection Service est configuré pour arrêter exactement une tâche dans un service ECS à deux tâches, assurant une disponibilité partielle pendant le test.
• Un script personnalisé exécuté dans AWS CodeBuild vérifie les préconditions, démarre l'expérience FIS, attend sa complétion et valide les métriques de récupération.
• La validation de la récupération exige que le nombre de tâches ECS en cours d'exécution et le nombre de cibles saines du load balancer correspondent à l'état souhaité.
• L'expérience utilise une alarme CloudWatch comme condition d'arrêt pour surveiller les hôtes sains, bien que le contrôle de sécurité principal consiste à limiter la panne à une seule tâche.
• Des scripts de nettoyage sont fournis pour gérer les ressources non gérées par les stacks CloudFormation, telles que les groupes de journaux et les révisions de définitions de tâches.

Contexte

Le chaos engineering est la discipline consistant à expérimenter sur un système afin de renforcer la confiance dans sa capacité à résister aux conditions turbulentes en production. Traditionnellement, cela pouvait impliquer des journées de jeu manuelles ou des environnements de test séparés. Son intégration dans le CI/CD rapproche ces tests des modifications de code, permettant de détecter précocement les régressions dans la logique de résilience. AWS Fault Injection Service est un service managé qui aide à réaliser ces expériences en toute sécurité en définissant des périmètres, des actions et des conditions d'arrêt.

Dans ce contexte, la "bascule" fait référence au remplacement automatique d'une tâche de conteneur défaillante par le planificateur ECS. Lorsqu'une tâche s'arrête, le service détecte l'écart entre le nombre souhaité et le nombre en cours d'exécution, lance une nouvelle tâche et l'enregistre auprès du load balancer. Le test vérifie que cette boucle complète s'effectue sans intervention humaine et dans un délai respectant les objectifs de niveau de service.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés ou des plateformes internes, la fiabilité est souvent supposée plutôt que testée. Les documents de conception peuvent affirmer qu'un service est hautement disponible, mais la dérive de configuration, les erreurs de permissions ou les politiques réseau peuvent silencieusement rompre les mécanismes de bascule. En automatisant ce test, les ingénieurs transforment des affirmations abstraites de conception en contrôles concrets pass/fail. Cela réduit le risque de découvrir des échecs de récupération lors de pannes réelles, lorsque les enjeux sont les plus élevés.

De plus, cette approche met en lumière l'importance des objectifs de temps de récupération. Il ne suffit pas qu'un service revienne éventuellement ; il doit le faire assez rapidement pour répondre aux attentes des utilisateurs. Le pipeline impose un délai strict, obligeant les équipes à optimiser leurs intervalles de vérification de santé, les temps de démarrage des conteneurs et les retards de désinscription du load balancer. Cela transforme l'ingénierie de la fiabilité d'une activité post-mortem réactive en une exigence de développement proactive.

Cependant, la mise en œuvre nécessite une gestion rigoureuse des permissions. Le tutoriel détaille plusieurs pièges courants, tels que des autorisations IAM manquantes pour créer des rôles liés aux services ou des ARN de groupes de cibles incorrects. Ces détails soulignent que le chaos engineering introduit de nouvelles complexités opérationnelles qui doivent être gérées parallèlement aux tâches de déploiement standard.

Ce que vous pouvez faire

• Examinez vos pipelines CI/CD actuels pour identifier où les tests de résilience pourraient être ajoutés en tant qu'étape post-déploiement.
• Commencez par un environnement non productif pour tester l'intégration FIS, en veillant à comprendre les modes de défaillance avant de toucher au trafic réel.
• Définissez des objectifs clairs de temps de récupération pour vos services critiques et utilisez-les comme seuil de délai dans vos tests automatisés.
• Auditez vos rôles IAM pour garantir que vos agents de build disposent des permissions minimales nécessaires pour démarrer les expériences FIS et interroger l'état ECS.
• Implémentez des pré-vérifications dans vos scripts de test pour confirmer que le système est sain avant d'injecter des fautes, évitant ainsi les faux positifs dus à des problèmes existants.
• Documentez le comportement attendu de vos services lors de pannes partielles et utilisez ces tests pour valider continuellement ces attentes.