L'automatisation des tâches avec Ansible
Introduction
Ansible est l'outil que j'utilise depuis plus de 8 ans pour la gestion de configuration. Chez Epiconcept, je l'ai utilisé pendant 4 ans pour gérer l'infrastructure de santé publique. C'est un outil que je connais intimement, et dont je peux vous parler avec le recul de centaines de playbooks écrits et maintenus.
Ansible sur le terrain : architecture sans agent
L'architecture sans agent d'Ansible est un avantage décisif dans certains contextes. Chez un client dans la santé publique, les contraintes de sécurité interdisaient l'installation d'agents sur les serveurs de production. Ansible, qui n'a besoin que d'un accès SSH, a passé la validation de sécurité sans problème. Un poste de contrôle, une clé SSH, et c'est parti. Pas de daemon à maintenir, pas de port supplémentaire à ouvrir.
Les vrais avantages d'Ansible au quotidien
Le YAML d'Ansible est lisible par n'importe qui dans l'équipe. Chez Epiconcept, les développeurs pouvaient lire les playbooks et comprendre exactement comment les serveurs étaient configurés. C'est une documentation vivante. Quand un nouveau développeur arrivait, il lisait les playbooks au lieu d'un wiki obsolète. L'idempotence est l'autre atout majeur : vous lancez le playbook 10 fois, le résultat est le même. Zéro effet de bord.
Ansible en production : exemples concrets
Chez un de mes clients, j'ai automatisé avec Ansible le provisioning complet d'un serveur : installation des paquets, configuration du pare-feu, déploiement de Docker, configuration des certificats TLS, mise en place du monitoring. Ce qui prenait 2 jours de travail manuel prend désormais 15 minutes. Et surtout, chaque serveur est identique. Plus de "mais pourquoi celui-là a une config différente ?"
Ansible dans la chaîne DevOps
Chez Bloomflow, Ansible s'intègre dans un workflow plus large. Terraform provisionne l'infrastructure (VMs, réseaux, load balancers), puis Ansible configure les machines (installation de Docker, configuration système, hardening sécurité). Ensuite, Kubernetes prend le relais pour l'orchestration des applications. Chaque outil fait ce qu'il fait le mieux. Ansible n'est pas un couteau suisse, c'est un tournevis très précis.
L'écosystème Ansible : collections et bonnes pratiques
Avec l'arrivée des Collections Ansible, l'écosystème s'est structuré. J'utilise régulièrement les collections community.docker, community.kubernetes, et amazon.aws. Mon conseil : structurez vos playbooks en rôles réutilisables, testez-les avec Molecule, et versionnez-les dans Git. Chez mes clients, les rôles Ansible sont traités comme du code applicatif : revus en pull request, testés en CI, déployés automatiquement.
Conclusion
Ansible reste un outil indispensable dans ma toolbox DevOps. Il excelle là où Terraform ne va pas : la configuration des machines, le déploiement d'applications non conteneurisées, le hardening sécurité. Sa simplicité et son architecture sans agent en font un choix évident pour quiconque veut automatiser la gestion de configuration. Après 8 ans d'utilisation quotidienne, je n'ai toujours pas trouvé mieux pour ce use case.