La gestion efficace des configurations avec Ansible
Introduction à Ansible : retour d'expérience
Ansible est l'outil de gestion de configuration que j'utilise le plus au quotidien. Simple, sans agent, basé sur SSH et YAML -- il a tout pour plaire aux équipes DevOps. Voici comment je l'exploite concrètement sur le terrain.
Pourquoi Ansible s'impose naturellement
Sur ma mission la plus longue avec Ansible -- plus de 4 ans chez un client dans la santé publique -- l'outil gère l'intégralité de la configuration : serveurs applicatifs, bases de données MariaDB, load balancers, monitoring. Les développeurs, qui n'avaient jamais touché à de la gestion de configuration, contribuent aux playbooks en quelques jours de montée en compétence.
L'absence d'agent est un atout majeur dans les environnements contraints. Chez un acteur de la Défense, installer un agent sur chaque serveur était hors de question pour des raisons de sécurité. Ansible en mode SSH convenait parfaitement.
Les principes qui font la différence
L'idempotence est le concept clé. Vous pouvez relancer un playbook autant de fois que vous voulez, le résultat sera toujours le même. C'est ce qui permet de l'intégrer dans un pipeline CI/CD sans crainte.
Le YAML comme langage rend les playbooks lisibles par tout le monde. Pas besoin d'être développeur Ruby (Chef) ou de maîtriser un DSL spécifique (Puppet). Un ops qui connaît Linux se met à Ansible en une journée.
Les playbooks et les rôles en pratique
La structuration en rôles est fondamentale. Chez Bloomflow, ma bibliothèque de rôles Ansible couvre : configuration OS (sysctl, limites, users), Docker (installation, configuration daemon, log rotation), Nginx (virtualhost, TLS, hardening), PostgreSQL (installation, réplication, backups), et monitoring (node_exporter, promtail).
Chaque rôle est paramétrable via des variables. Le même rôle postgresql s'adapte à un PostgreSQL 14 sur Debian 11 ou un PostgreSQL 16 sur Ubuntu 22.04, juste en changeant les variables.
Les inventaires dynamiques : s'adapter au Cloud
Dans les environnements Cloud, les serveurs apparaissent et disparaissent. Les inventaires dynamiques d'Ansible (plugins AWS EC2, GCP, Azure) découvrent automatiquement les instances et les catégorisent par tags. Chez un éditeur de logiciels sur AWS, les nouvelles instances EC2 sont automatiquement configurées par Ansible dès leur lancement, via un hook dans le pipeline de provisioning Terraform.
Ansible dans le pipeline CI/CD
J'intègre Ansible dans GitHub Actions pour appliquer les configurations automatiquement. Le workflow : un développeur modifie un playbook, ouvre une PR, la CI vérifie la syntaxe (ansible-lint, yamllint), un pair review approuve, et le merge déclenche l'application du playbook sur les serveurs cibles.
Chez Epiconcept, ce workflow est en place depuis des années. Les changements de configuration sont tracés, revus et appliqués de manière automatisée. Zéro SSH manuel en production.
Conclusion : Ansible, le pilier silencieux
Ansible n'est pas l'outil le plus médiatique de l'écosystème DevOps (Kubernetes monopolise la lumière), mais c'est peut-être le plus universellement utile. Que vous gériez 3 serveurs ou 300, que vous soyez sur AWS ou on-premise, Ansible simplifie et fiabilise la gestion de configuration. C'est le premier outil que je recommande à quiconque veut commencer l'Infrastructure as Code.