Gérer les configurations avec Ansible en DevOps
Introduction
Ansible est l'un des outils que j'utilise le plus au quotidien. Depuis plus de 4 ans chez un client dans la santé publique (Epiconcept), c'est Ansible qui gère l'ensemble de la configuration serveur : applications, bases de données MariaDB, services systemd, certificats TLS, le tout versionné dans Git.
Pourquoi Ansible plutôt qu'un autre outil ?
J'ai travaillé avec Chef, Puppet et Salt au fil de mes missions. Ce qui fait la force d'Ansible, c'est sa simplicité : pas d'agent à installer sur les machines cibles, une connexion SSH standard, et des playbooks en YAML lisibles par n'importe qui dans l'équipe. Chez Epiconcept, même les développeurs contribuent aux playbooks Ansible, ce qui n'aurait jamais été le cas avec Puppet.
Structurez vos playbooks avec des rôles
L'erreur que je vois souvent : un seul playbook monolithique de 500 lignes. Ma recommandation : découpez en rôles. Un rôle nginx, un rôle postgresql, un rôle docker, etc. Chaque rôle est testable indépendamment et réutilisable d'un projet à l'autre.
Chez Bloomflow, j'ai constitué une bibliothèque de rôles Ansible réutilisables. Quand je monte un nouveau serveur, l'ensemble de la configuration est appliquée en moins de 10 minutes, avec la certitude que tout est identique aux autres serveurs du parc.
Ansible et les environnements multi-cloud
Ansible s'intègre avec tous les cloud providers que j'utilise : AWS, Azure, GCP, Scaleway, OVH. Les inventaires dynamiques permettent de découvrir automatiquement les instances. Chez un client sur AWS, l'inventaire dynamique EC2 garantit que les nouveaux serveurs sont automatiquement configurés dès leur lancement.
Sur OVH Cloud, j'utilise Ansible pour bootstrapper les nodes Kubernetes avant que le cluster ne prenne le relais. C'est la combinaison Terraform (provisioning infra) + Ansible (configuration OS) + Helm (déploiement applicatif) qui forme le trio gagnant.
L'idempotence : le concept clé
Le principe d'idempotence est fondamental : vous pouvez relancer un playbook 10 fois, le résultat sera toujours le même. Chez un client, un administrateur avait peur de relancer un script de configuration par crainte de casser quelque chose. Avec Ansible, cette peur disparaît. Le playbook vérifie l'état actuel et n'applique que les changements nécessaires.
Ansible dans le pipeline CI/CD
J'intègre Ansible dans les pipelines GitHub Actions pour appliquer les configurations automatiquement après chaque merge sur la branche principale. Le workflow : commit sur Git -> CI valide la syntaxe Ansible -> Ansible applique les changements sur les serveurs. Infrastructure as Code, de bout en bout.
Conclusion
Ansible reste mon outil de choix pour la gestion de configuration. Sa simplicité, son approche agentless et sa compatibilité multi-cloud en font un incontournable. Le conseil que je donne systématiquement : commencez par automatiser la tâche que vous faites le plus souvent manuellement. Le reste suivra naturellement.