CI/CD·

Optimisation des Déploiements Continus avec GitHub Actions et Terraform

Découvrez comment combiner GitHub Actions et Terraform pour des déploiements continus optimisés, sécurisés et automatisés.
Optimisation des Déploiements Continus avec GitHub Actions et Terraform

Introduction

La combinaison GitHub Actions + Terraform est devenue mon stack de référence pour le déploiement d'infrastructure. Sur les projets F2R2, TEKYN et WizOps.fr, cette combinaison a prouvé sa fiabilité. Voici comment optimiser cette intégration pour des déploiements continus vraiment efficaces.

GitHub Actions + Terraform : le workflow idéal

Mon workflow standard pour Terraform dans GitHub Actions suit un pattern éprouvé. À chaque PR qui modifie un fichier .tf, un job exécute terraform init, terraform validate, puis terraform plan. Le résultat du plan est posté en commentaire de la PR grâce à une action dédiée. Le reviewer voit exactement les ressources créées, modifiées ou supprimées. Après merge sur main, un second workflow exécute terraform apply. Chez F2R2, ce pattern gérait 25 modules Terraform sur une architecture AWS Multi-Compte. Chaque modification d'infra était visible, reviewée et traçable.

Infrastructure as Code : au-delà de la théorie

L'IaC avec Terraform, ce n'est pas juste "écrire des fichiers .tf". C'est une discipline. Chez TEKYN, les modules Terraform géraient l'Organisation AWS complète : comptes, SCPs, VPC, ECS Fargate, CloudFront, RDS. Chaque module avait ses tests (via Terratest en Go), ses variables documentées, et ses outputs. Le state était stocké dans S3 avec chiffrement KMS et verrouillage DynamoDB. Chez Bloomflow, Terraform gérait l'infrastructure sur 3 providers simultanément (AWS, Scaleway, Outscale), chacun avec son propre state backend. L'IaC, c'est traiter l'infrastructure avec la même rigueur que le code applicatif.

Sécurisation du pipeline Terraform

La sécurité d'un pipeline Terraform est critique car il a les droits de créer et détruire de l'infrastructure. Chez KNDS (Défense), j'appliquais le principe de moindre privilège : le service account du pipeline n'avait que les permissions nécessaires, pas d'admin. Les secrets (credentials cloud) étaient stockés dans GitHub Secrets avec rotation trimestrielle. Le terraform plan en PR permettait de détecter les changements dangereux avant exécution. Chez F2R2, j'ai ajouté un check OPA (Open Policy Agent) dans le pipeline qui bloquait certains patterns : suppression de base de données, ouverture de ports réseau sensibles, création de ressources dans des régions non autorisées.

Multi-cloud et multi-environnement

Gérer plusieurs clouds et environnements avec GitHub Actions et Terraform demande une bonne organisation. Ma structure : un repo par couche (réseau, compute, applicatif) avec des workspaces Terraform ou des dossiers par environnement. Chez Bloomflow, les workflows GitHub Actions utilisaient des matrices pour déployer sur dev, staging et production avec les mêmes modules mais des variables différentes. Chez Earny SA, la migration GCP vers AWS utilisait deux pipelines parallèles : un pour maintenir l'infra GCP existante, un pour construire la nouvelle infra AWS. Le basculement s'est fait en modifiant le DNS, piloté par un workflow GitHub Actions.

Monitoring et maintenance de l'infra

Un pipeline Terraform sans monitoring, c'est risqué. Sur chaque projet, j'ajoute des steps de vérification post-apply. Chez Metronome, le workflow vérifiait après chaque terraform apply que les endpoints étaient accessibles et que les health checks Kubernetes passaient. Les métriques Terraform (durée du plan, nombre de ressources modifiées) étaient envoyées à Prometheus pour détecter les dérives. Des dashboards Grafana dédiés affichaient l'état de l'infrastructure en temps réel. Chez F2R2, GuardDuty et CloudTrail complétaient le monitoring avec la détection d'intrusions et l'audit des actions sur les comptes AWS.

Conclusion

GitHub Actions et Terraform forment un duo puissant pour le déploiement continu d'infrastructure. La clé du succès : un workflow clair (plan en PR, apply après merge), une sécurité stricte (moindre privilège, review obligatoire), et un monitoring post-déploiement. C'est cette approche qui m'a permis de gérer des infrastructures multi-cloud complexes avec confiance.



RDV