Optimiser vos déploiements avec Ansible et Terraform
Ansible + Terraform : le duo qui a structuré ma carrière
Si je devais résumer mes 15 ans d'expérience Infrastructure as Code en deux outils, ce serait Terraform pour le provisioning et Ansible pour la configuration. J'ai utilisé ce duo sur des dizaines de projets, du serveur bare-metal chez SFR Business Team jusqu'aux architectures multi-comptes AWS chez F2R2.
Terraform : penser l'infrastructure comme du code
Mon projet Terraform le plus ambitieux reste l'architecture AWS Multi-Compte pour F2R2 : 25 modules Terraform, couvrant EKS Fargate, Aurora PostgreSQL, WAF, GuardDuty, VPC peering, et tout le networking associé. La clé du succès a été la modularisation dès le départ.
Chaque module avait une responsabilité unique et des interfaces claires (variables d'entrée, outputs). Le module réseau ne connaissait rien au module base de données. Cette séparation permet de faire évoluer un composant sans risquer de casser les autres.
Un pattern que je recommande systématiquement : le remote state avec des backends S3 + DynamoDB pour le locking. Sur un projet chez Bloomflow, deux ingénieurs ont lancé un terraform apply en même temps sur le même state. Sans locking, c'est la corruption garantie. Avec DynamoDB, le second apply attend proprement que le premier se termine.
Les erreurs Terraform que j'ai vues (et commises)
La première erreur classique : mettre toute l'infrastructure dans un seul state file. Chez TEKYN, le state initial contenait l'Organisation AWS, les comptes, le réseau, les clusters ECS, les bases de données et les distributions CloudFront. Un terraform plan prenait 8 minutes, et le moindre changement faisait transpirer toute l'équipe. Nous avons découpé en 6 states séparés : le plan est passé à 30 secondes, et les déploiements sont devenus ciblés et sûrs.
La deuxième erreur : ne pas utiliser de structure de répertoires pour séparer les environnements. J'utilise une structure environments/{dev,staging,prod}/ avec un backend S3 par environnement et des tfvars spécifiques. Simple, lisible, maintenable.
Ansible : la configuration qui tient dans le temps
Chez Epiconcept, j'ai géré pendant plus de 4 ans l'infrastructure avec Ansible. Des serveurs MariaDB en réplication, des serveurs web, des environnements de build GitHub Actions. Ce qui m'a frappé, c'est la durabilité d'Ansible quand il est bien structuré.
La clé est l'idempotence. Chaque playbook doit pouvoir être rejoué sans effet de bord. Cela semble évident, mais en pratique je vois régulièrement des tâches shell avec creates: oublié, des templates qui écrasent des fichiers de configuration manuellement modifiés, ou des handlers qui ne se déclenchent pas dans le bon ordre.
Mon approche : un rôle Ansible par service, avec des defaults sensés, des variables documentées dans defaults/main.yml, et des molecule tests pour valider chaque rôle en isolation. Chez Epiconcept, cette rigueur nous a permis de reconstruire un serveur de production complet en 45 minutes après un incident matériel.
Quand utiliser quoi ?
Après des années de pratique, ma règle est simple. Terraform gère tout ce qui est provisionné via une API cloud : instances, réseaux, bases de données managées, DNS, load balancers. Ansible gère tout ce qui se passe à l'intérieur de la machine : packages, configuration, services, utilisateurs.
Il y a une zone grise pour Kubernetes. On peut provisionner un cluster EKS avec Terraform et déployer les applications avec Helm (piloté par ArgoCD). C'est l'approche que j'ai adoptée chez F2R2 et Earny SA, et elle fonctionne très bien : Terraform s'arrête au cluster et aux add-ons critiques (ingress controller, cert-manager, external-secrets), ArgoCD prend le relais pour tout le reste.
Le piège de l'over-engineering
Un dernier conseil issu de l'expérience : ne sur-ingénieriez pas votre IaC. J'ai vu des projets avec des modules Terraform tellement abstraits qu'il fallait 30 minutes pour comprendre comment déployer un simple bucket S3. L'Infrastructure as Code doit rester lisible par toute l'équipe, pas seulement par celui qui l'a écrite. Si un nouveau venu ne peut pas comprendre votre code en 15 minutes, c'est trop complexe.