Automatisez votre infrastructure avec Terraform et Ansible
Introduction
Terraform et Ansible sont deux outils que j'utilise quotidiennement depuis des années. L'un crée l'infrastructure, l'autre la configure. Ensemble, ils forment un duo redoutable. Sur le projet F2R2, j'ai construit 25 modules Terraform pour une architecture AWS Multi-Compte complète. Chez Epiconcept, Ansible a été mon compagnon pendant 4 ans. Voici comment tirer le meilleur de cette combinaison.
Terraform en pratique : 25 modules pour une archi AWS
Chez F2R2, le besoin était ambitieux : une architecture AWS Multi-Compte complète en 15 jours d'audit suivis de la mise en oeuvre. J'ai structuré le code en 25 modules Terraform couvrant VPC, sous-réseaux, EKS Fargate, Aurora PostgreSQL, WAF, GuardDuty, et bien d'autres services. Chaque module était réutilisable et testé indépendamment. Le state Terraform était stocké dans S3 avec verrouillage DynamoDB, et chaque terraform plan passait par la CI. Résultat de l'audit initial : une réduction de 19% du budget cloud. La modularité Terraform est la clé : un module VPC utilisé sur 3 comptes différents, c'est du code écrit une fois et déployé partout.
Ansible : 4 ans de configuration chez Epiconcept
Chez Epiconcept, j'ai utilisé Ansible pendant plus de 4 ans pour gérer la configuration de serveurs dédiés aux projets INSERM et Armées. Les playbooks couvraient l'installation de MariaDB, la configuration de Docker, le déploiement d'applications, et la gestion des sauvegardes. La force d'Ansible, c'est sa nature agentless : pas de daemon à installer sur les serveurs cibles, juste SSH. Pour des serveurs sensibles dans le domaine de la santé et de la défense, c'est un avantage majeur en termes de surface d'attaque. J'avais structuré les playbooks en rôles réutilisables, avec des variables par environnement (dev, staging, production).
La complémentarité : Terraform crée, Ansible configure
L'astuce pour bien combiner ces outils, c'est de respecter la frontière. Terraform gère tout ce qui est "infrastructure" : instances, réseaux, base de données managées, load balancers. Ansible prend le relais pour la "configuration" : installation de packages, fichiers de configuration, services systemd. Chez Metronome, Terraform provisionnait les clusters Kubernetes OVH et les ressources associées, puis Ansible configurait les noeuds workers avec les paramètres système requis (sysctl, limites de fichiers, modules kernel). Chez TEKYN, Terraform déployait l'infrastructure AWS (ECS, CloudFront, RDS), et Ansible configurait les sidecars Nginx sur les tâches Fargate.
Cas concret : migration GCP vers AWS sans downtime
Chez Earny SA (Suisse), j'ai piloté une migration de GCP vers AWS sans interruption de service. Terraform a créé la nouvelle infrastructure AWS (VPC, EKS, RDS) en parallèle de l'existant GCP. Ansible a configuré les nouveaux noeuds et migré les configurations applicatives. ArgoCD a géré le basculement progressif des workloads. Le tout orchestré via des pipelines CI/CD. La migration s'est faite sur 3 semaines, avec zéro downtime constaté par les utilisateurs. Sans Terraform et Ansible, cette opération aurait pris 3 mois et nécessité des fenêtres de maintenance.
Les pièges à éviter
En 15 ans, j'ai identifié les erreurs récurrentes. Premièrement : ne pas mélanger Terraform et Ansible dans le même périmètre. Si Terraform gère un fichier de config et qu'Ansible le modifie aussi, c'est le chaos du drift. Deuxièmement : versionner les modules Terraform. Un source = "../modules/vpc" qui pointe sur un chemin relatif, c'est une bombe à retardement. Utilisez un registry privé ou des tags Git. Troisièmement : testez vos playbooks Ansible avec Molecule avant de les exécuter en production. Chez Bloomflow, chaque rôle Ansible avait ses tests Molecule intégrés dans la CI.
Conclusion
Terraform et Ansible ne sont pas des concurrents, ce sont des alliés. Terraform pour l'infrastructure déclarative, Ansible pour la configuration impérative. Cette combinaison m'a permis de livrer des architectures complexes sur AWS, GCP, OVH et Scaleway avec fiabilité et rapidité. Le secret : des modules propres, des rôles testés, et une CI qui valide tout.