Automatiser le Déploiement Continu avec GitHub Actions et Terraform
Introduction
Automatiser le déploiement continu de l'infrastructure, c'est passer de "j'espère que ça va marcher" à "je sais exactement ce qui va se passer". GitHub Actions et Terraform forment le binôme que j'utilise sur la plupart de mes projets AWS, et les résultats sont constants : moins d'erreurs, plus de traçabilité, des déploiements fiables.
Le déploiement continu d'infra : pourquoi c'est différent
Déployer du code applicatif et déployer de l'infrastructure, ce n'est pas la même chose. Un bug applicatif se rollback en redéployant l'ancienne image. Un terraform destroy accidentel détruit des données. Chez F2R2, cette distinction a guidé toute l'architecture des pipelines. Le terraform plan en PR montre exactement les changements prévus. Le reviewer peut détecter un destroy non voulu avant qu'il n'arrive. Le terraform apply en production nécessite une approbation manuelle via les GitHub Environments. Cette rigueur a évité plusieurs incidents potentiels sur le projet.
GitHub Actions pour Terraform : mon workflow type
Mon workflow Terraform standard comporte 3 étapes. Step 1 : terraform fmt -check pour vérifier le formatage (rejeté si non conforme). Step 2 : terraform init + terraform validate + terraform plan avec le résultat posté en commentaire PR. Step 3 (après merge) : terraform apply -auto-approve sur les environnements non-production, avec approbation manuelle pour la production. Chez TEKYN, ce workflow gérait l'Organisation AWS complète : comptes, VPC, ECS Fargate, CloudFront, RDS. Chaque modification d'infra passait par ce processus sans exception. Le state était stocké dans S3 avec verrouillage DynamoDB et chiffrement KMS.
Terraform multi-compte : le cas F2R2
Le projet F2R2 illustre parfaitement l'automatisation à grande échelle. L'architecture AWS Multi-Compte comprenait un compte management, des comptes workload (dev, staging, prod), et un compte sécurité. Les 25 modules Terraform couvraient tout : VPC, EKS Fargate, Aurora, WAF, GuardDuty, CloudTrail, SCPs. Le pipeline GitHub Actions utilisait des matrices pour appliquer les changements sur chaque compte avec les credentials appropriées. Les secrets AWS (access keys) étaient stockés dans GitHub Secrets avec rotation automatique. Le résultat : une infrastructure complète reproductible en 45 minutes via terraform apply.
Bonnes pratiques tirées de l'expérience
Quelques leçons apprises à la dure. Premièrement : activez prevent_destroy sur les ressources critiques (bases de données, buckets avec données). Chez un client, un développeur a supprimé un RDS en staging en modifiant le mauvais workspace. Deuxièmement : utilisez Terragrunt ou des workspaces Terraform pour séparer les environnements. Un seul state pour dev et prod est une recette pour le désastre. Troisièmement : testez vos modules Terraform. Chez Bloomflow, chaque module avait des tests automatisés qui vérifiaient que le plan produisait les ressources attendues.
Monitoring post-apply
Le déploiement Terraform ne s'arrête pas à l'apply. Chez F2R2, le workflow GitHub Actions incluait des étapes post-apply : vérification que les endpoints sont accessibles, que les health checks passent, que les métriques CloudWatch sont normales. En cas d'anomalie, une notification Slack alertait l'équipe. GuardDuty surveillait les changements de configuration suspects. CloudTrail loggait toutes les actions API pour l'audit. Cette couche de vérification post-déploiement a attrapé 3 problèmes de configuration en 6 mois qui auraient pu passer inaperçus sans monitoring.
Conclusion
L'automatisation du déploiement continu d'infrastructure avec GitHub Actions et Terraform est un investissement qui se rembourse rapidement. Le pattern plan-en-PR/apply-après-merge apporte la sécurité et la traçabilité que les déploiements manuels ne peuvent pas offrir. C'est cette approche qui me permet de gérer des architectures AWS complexes avec confiance.