Dans la plupart des équipes d’exploitation, l’automatisation existe déjà. Elle prend la forme d’une collection de scripts shell, écrits par différentes personnes à différentes époques, que personne n’ose modifier et dont certains ne fonctionnent que sur le poste de leur auteur. Le reste se fait à la main, en se connectant serveur par serveur.
Ansible ne demande pas de jeter tout cela. Il se distingue justement par sa facilité d’adoption progressive, à condition de l’introduire dans le bon ordre.
Pourquoi Ansible plutôt qu’un autre outil
Ansible se connecte aux serveurs en SSH, comme un administrateur. Il n’y a pas d’agent à installer ni de serveur central à maintenir pour commencer : un poste de contrôle et une liste de machines suffisent. Les tâches se décrivent en YAML, dans des fichiers lisibles même par quelqu’un qui ne les a pas écrits.
Surtout, Ansible décrit un état attendu plutôt qu’une suite de commandes. On ne dit pas « ajoute cette ligne au fichier », on dit « ce fichier doit contenir cette ligne ». Exécuté une deuxième fois, le même playbook ne change rien si l’état est déjà le bon. C’est ce qu’on appelle l’idempotence, et c’est ce qui permet de relancer une automatisation sans crainte.
Par où commencer
Le piège classique est de vouloir automatiser d’emblée le déploiement le plus complexe. Les premiers gains viennent de tâches modestes et répétitives.
- L’inventaire. Lister les serveurs, les regrouper par rôle et par environnement. Cet inventaire est souvent le premier document à jour que l’équipe possède sur son propre parc.
- Les vérifications en lecture seule. Version du système, espace disque, services actifs, comptes présents. Rien n’est modifié, et l’on obtient en quelques minutes un état de tout le parc.
- La configuration commune. Comptes d’administration, clés SSH, synchronisation de l’heure, paramètres de journalisation : ce qui doit être identique partout, et ne l’est jamais.
- Les mises à jour. Appliquées par lots, avec vérification après chaque lot, plutôt qu’à la main un soir par mois.
- Le déploiement d’un service. Seulement ensuite, quand l’équipe est à l’aise avec les rôles et les templates.
Les bonnes pratiques qui évitent de recréer le désordre
- Tout dans Git. Un playbook qui n’est pas versionné redevient un script sur un poste.
- Des rôles réutilisables. Un rôle par service, avec ses paramètres séparés de ses tâches, documenté pour que l’équipe puisse s’en servir sans le relire.
- Des secrets protégés. Les mots de passe et clés vont dans Ansible Vault, jamais en clair dans le dépôt.
- Simuler avant d’appliquer. Le mode de vérification montre ce qui changerait, sans rien modifier. C’est le réflexe à prendre avant toute exécution en production.
- Déployer progressivement. Un lot de serveurs d’abord, puis les autres, pour qu’une erreur reste circonscrite.
Et quand l’équipe grandit
Quand plusieurs personnes lancent des automatisations, il faut savoir qui a exécuté quoi, quand, avec quels droits. AWX, la version open source d’Ansible Automation Controller, apporte une interface web, la planification, l’historique des exécutions et un contrôle d’accès. Ce n’est pas une étape de départ, mais c’est la suite logique quand Ansible devient l’outil de toute l’équipe.
Ce qu’on gagne, concrètement
Le gain le plus visible n’est pas la vitesse, même si une mise à jour de parc passe de plusieurs heures à quelques minutes. C’est la reproductibilité : un serveur reconstruit après une panne est configuré exactement comme l’ancien, et un nouvel arrivant comprend la configuration du parc en lisant les rôles plutôt qu’en interrogeant ses collègues.