Maîtriser l'Automatisation des Déploiements avec Ansible et Terraform

Introduction
Ansible et Terraform, c'est le duo que j'utilise depuis plus de 8 ans. Terraform pour provisionner l'infrastructure cloud, Ansible pour configurer les machines. Chez Epiconcept, où je collabore depuis plus de 4 ans, cette combinaison gère l'intégralité de l'infrastructure : serveurs, bases de données, certificats, monitoring. Retour d'expérience sur ce tandem éprouvé.
Ansible : 4 ans de playbooks chez Epiconcept
Chez Epiconcept, Ansible est le pilier de la gestion des configurations. Les playbooks gèrent l'installation de Docker, la configuration de MariaDB (réplication, backups automatisés, tuning), le déploiement des applications pour l'INSERM et les Armées, et les mises à jour de sécurité. Le tout est versionné dans Git et exécuté via GitHub Actions. L'atout majeur d'Ansible : l'idempotence. Un playbook exécuté 10 fois produit le même résultat. Quand un serveur a dû être reconstruit après un incident disque, le ansible-playbook site.yml a remis l'intégralité de la configuration en 12 minutes. Sans Ansible, la reconstruction aurait pris une journée.
Terraform : 25 modules pour une architecture AWS Multi-Compte
Chez F2R2, j'ai conçu et implémenté une architecture AWS Multi-Compte avec 25 modules Terraform : VPC, subnets, NAT Gateways, IAM roles cross-account, EKS Fargate, Aurora PostgreSQL, WAF, GuardDuty, CloudWatch, S3, et bien d'autres. Chaque module est testé via terraform plan dans le pipeline GitHub Actions, et le merge déclenche le terraform apply. La reproductibilité est totale : provisionner un nouvel environnement complet prend 15 minutes. L'audit initial avait révélé un gaspillage de 19% sur la facture AWS ; après le refactoring Terraform, chaque ressource est justifiée, taggée et monitorée.
La synergie Ansible + Terraform en pratique
Ma règle d'or : Terraform gère le "quoi" (quelle infrastructure provisionner), Ansible gère le "comment" (comment configurer les machines). Chez TEKYN, Terraform provisionne l'AWS Organization, les comptes, les réseaux et les services managés (ECS Fargate, CloudFront, RDS). Ansible configure les bastions, les agents de monitoring et les politiques de sécurité. Cette séparation claire des responsabilités simplifie le debugging : si un problème concerne l'infrastructure, on regarde Terraform ; si c'est la configuration, on regarde Ansible.
Intégration CI/CD : tout passe par le pipeline
Chez Bloomflow, chaque modification d'Ansible ou de Terraform passe par une PR avec review. Le pipeline GitHub Actions exécute ansible-lint et terraform validate comme checks de qualité. Pour Terraform, le plan est posté en commentaire sur la PR pour que le reviewer puisse voir les changements. Pour Ansible, un --check --diff (dry-run) montre les modifications sans les appliquer. Ce processus de validation avant application a éliminé les "oups, j'ai cassé la prod" chez tous mes clients.
Monitoring des infrastructures Ansible + Terraform
Provisionner et configurer, c'est bien. Surveiller, c'est indispensable. Chez Metronome, Terraform déploie la stack Prometheus + Grafana (via le provider Helm), et Ansible configure les exporters Node Exporter sur les VM traditionnelles. Les dashboards Grafana montrent la santé de l'infrastructure : CPU, mémoire, disque, certificats TLS (expiration), et état des services. Une alerte Slack prévient 30 jours avant l'expiration d'un certificat. Cette surveillance proactive a évité plusieurs incidents liés à des certificats expirés ou des disques pleins.
Conclusion
Ansible et Terraform sont complémentaires par design. Terraform excelle dans le provisioning déclaratif d'infrastructure cloud, Ansible dans la configuration idempotente des machines. Intégrés dans un pipeline CI/CD avec validation systématique, ils forment une base solide pour toute infrastructure. C'est cette approche que j'applique depuis 8 ans, du projet personnel (WizOps) au grand compte (F2R2, KNDS).