Optimisez votre pipeline CI/CD avec GitHub Actions et Terraform
GitHub Actions + Terraform : mon pipeline IaC de référence
La combinaison GitHub Actions et Terraform est celle que je déploie le plus souvent pour gérer l'infrastructure as code. Voici le pipeline que j'ai affiné au fil des projets.
Pourquoi GitHub Actions pour l'IaC
GitHub Actions élimine le besoin d'un serveur Jenkins dédié pour l'Infrastructure as Code. Chez F2R2, le pipeline Terraform tourne intégralement dans GitHub Actions : terraform fmt pour le formatage, terraform validate pour la syntaxe, terraform plan sur chaque pull request, et terraform apply automatique au merge sur main. Les secrets AWS (access key, secret key, assume role) sont stockés dans les secrets GitHub, jamais en clair dans le code. Cette approche a permis de gérer 25 modules Terraform et une architecture AWS multi-comptes sans aucun serveur CI à maintenir.
Terraform : la gestion d'infrastructure multi-cloud
Terraform gère l'infrastructure de la majorité de mes clients. Chez TEKYN, les fichiers Terraform provisionnent l'AWS Organization complète : 3 comptes (dev, staging, prod), les services ECS Fargate, les distributions CloudFront, et les politiques IAM. Chez Metronome, Terraform crée le cluster Kubernetes OVH Cloud et toute l'infrastructure réseau. Chez Earny SA, Terraform a été l'outil clé pour recréer sur AWS toute l'infrastructure qui existait sur GCP, en assurant la parité fonctionnelle. La syntaxe HCL est intuitive, et les modules permettent de réutiliser des blocs de configuration entre projets.
L'intégration en pratique : le workflow type
Voici le workflow que j'utilise sur la plupart de mes projets : (1) Un développeur crée une branche et modifie un fichier Terraform. (2) Il ouvre une pull request. GitHub Actions exécute automatiquement terraform plan et poste le résultat en commentaire sur la PR. (3) L'équipe review le plan : quelles ressources seront créées, modifiées ou détruites. (4) Après approbation et merge, GitHub Actions exécute terraform apply sur l'environnement cible. (5) Des notifications Slack informent l'équipe du résultat. Ce workflow GitOps appliqué à l'infrastructure a été déployé chez F2R2, TEKYN et Bloomflow avec succès.
Les avantages mesurables
Les gains sont concrets et mesurables. Chez F2R2, l'audit AWS de 15 jours a identifié 82 actions d'optimisation. La mise en oeuvre via Terraform et GitHub Actions a permis de réduire le budget cloud de 19%, principalement grâce à la suppression de ressources inutilisées et au right-sizing des instances. Chez Coopengo, le passage de Terraform en standalone à un pipeline GitHub Actions/Terraform a éliminé les "terraform apply depuis le laptop de quelqu'un" qui causaient des dérives de configuration régulières. Chaque modification d'infrastructure est désormais tracée, reviewée et appliquée de manière reproductible.
Les bonnes pratiques que j'applique
Première règle : versionner l'état Terraform dans un backend distant (S3 + DynamoDB pour le lock). Jamais en local. Deuxième règle : utiliser des workspaces ou des répertoires séparés par environnement pour éviter d'appliquer accidentellement un changement de dev en production. Troisième règle : des modules versionnés avec des tags Git pour contrôler précisément quelle version de chaque module est utilisée. Quatrième règle : le terraform plan doit être lisible par un humain. Si le plan fait 500 lignes, il faut découper la modification en pull requests plus petites.
Ce pipeline est réplicable en une journée
L'avantage de cette combinaison, c'est sa reproductibilité. Une fois le pattern maîtrisé, je peux le déployer chez un nouveau client en quelques heures. Les fichiers YAML de workflow sont réutilisables, les modules Terraform sont paramétrables, et les bonnes pratiques sont universelles. C'est cette efficacité qui me permet de livrer rapidement sur chaque mission.