Ansible

L’automatisation avant, c’était souvent un joyeux bazar. Entre les scripts bash qui s’accumulent et les commandes qu’on tape à la main à minuit, on finit vite par rêver d’un outil simple et efficace pour tout gérer. Et c’est là qu’Ansible entre en scène !

Comme pour GitLab ou Terraform, j’ai envie de partager ce que j’ai appris en l’utilisant sur le terrain, dans des projets qui allaient du simple déploiement d’une VM à la configuration complète d’un cluster de serveurs. Et comme d’habitude, ce n’est que mon point de vue : le mien, celui d’une passionnée qui a testé, raté, corrigé, et (parfois) réussi.

C’est quoi encore ce truc ?

Ansible, c’est un outil open-source d’automatisation de la configuration et de l’orchestration. Une grande phrase qui signifie qu’Ansible permet de décrire l’état souhaité de vos machines ou applications. Pour cela, on utilise des playbooks, écrits en YAML et on les applique pour rendre l’infrastructure conforme aux besoins.

Son gros avantage ? Pas besoin d’agent à installer sur les machines : Ansible se connecte via SSH et exécute les tâches qu’on lui a confié, comme :

• Installer des paquets,
• Configurer des fichiers,
• Déployer des applications,
• Orchestrer plusieurs serveur en même temps,
• Et même déclencher des actions sur le cloud (AWS, Azure, GCP, etc.) ou dans vos clusters Kubernetes.

Ce qu’on aime avec Ansible

Ansible a de vrais atouts :

• Simplicité d’utilisation : un simple « ansible-playbook monplaybook.yml » suffit pour lancer toute la procédure.
• Pas d’agent : comme je l’ai déjà dit en introduction, les serveurs restent « propres ». Ansible utilise juste SSH et ne nécessite aucun dépôt sur les hôtes qu’il va contacter.
• Idempotence : c’est le principe phare de l’outil ! Si le serveur est déjà dans l’état souhaité, Ansible ne fera rien !
• Grande communauté et nombreux modules pour presque tout (gestion système, cloud, réseaux, etc.).
• Extensible : possibilité de créer ses propres rôles et modules.
• YAML : langage lisible même par ceux qui ne sont pas experts.

Quelques points faibles

Malheureusement (ou heureusement), Ansible n’est pas parfait. Il peut être :

• Lent pour gérer des milliers de machines, car il fonctionne de manière séquentielle (sauf avec l’option « forks »).
• Peu performant pour des workflows très complexes avec beaucoup de dépendances entre tâches.
• Limité en cas de besoin de « state » persistant : il n’est pas conçu pour stocker l’état d’une infrastructure comme Terraform.
• Sensible à la qualité de vos playbooks : mal écrits, ils deviennent vite ingérables.

Les raisons pour lesquelles j’utilise Ansible

Tout simplement, parce qu’Ansible simplifie la vie ! L’outil me permet de centraliser tout dans des playbooks clairs et versionnés. J’automatise des tâches répétitives, je garantis la cohérence entre mes environnements de dev, de test et de prod et je réduis le risque d’erreurs humaines.

C’est un excellent choix pour les petites et moyennes équipes qui veulent améliorer la qualité de leur infra sans investir dans une usine à gaz. Et si votre stack évolue, Ansible peut facilement s’intégrer dans un pipeline CI/CD pour automatiser vos déploiements.

Les bases à connaître

Ansible nécessaite de connaître et comprendre quelques concepts :

• Les inventaires : un fichier (ini, yaml, …) qui liste vos serveurs avec leurs adresses et groupes.
• Les modules : les « briques » d’Ansible pour exécuter des actions spécifiques comme installer des paquets, copier des fichiers, lancer des commandes shell ou bash, etc.
• Les playbooks : des fichiers YAML qui décrivent les tâches étape par étape.

Voici un exemple minimaliste de playbook :

- hosts: webservers
  become: yes
  tasks:
    - name: Installer nginx
      apt:
        name: nginx
        state: present
    - name: Démarrer le service nginx
      service:
        name: nginx
        state: started

Avec ça, vous installez et lancez Nginx sur tous les serveurs du groupe « webservers » en une seule commande.

• Les rôles : ils permettent d’organiser les playbooks de façon modulaire et réutilisable.
• Les handlers : très pratique pour redémarrer des services uniquement si nécessaire (et éviter ainsi la redondance de code).

Quelques bonnes pratiques

Selon, il y a des règles à appliquer dès le départ, pour prendre de bonns habitudes et permettre une bonne maintenance des playbooks.

• Se fier à la documentation. On ne le dit jamais assez mais avant de balancer des « ça marche pas » sans essayer de résoudre le soucis seul, je conseille vivement de se référer à la doc qui contient souvent toutes les réponses.
• Centralisez les variables dans des fichiers séparés pour éviter les duplications. Et surtout, se reporter régulièrement à la précédence des variables.
• Testez vos playbooks sur un environnement de staging avant la production !
• Apprenez à lire les logs en cas de bug ! Je l’ai souvent vu sur le terrain. Il y a du rouge et au lieu de comprendre pourquoi, ça bidouille dans tous les coins pour changer les choses. Personnellement, j’appelle ça du « bricolage ». Et c’est pas forcément un compliment de ma part…
• Versionnez vos playbooks avec Git pour garder un historique.
• Documentez vos tâches pour que vos collègues comprennent pourquoi elles existent (oui, savoir écrire des commentaires et de la doc restent, selon moi, une réelle compétence, malheureuse trop peu acquise).
• Vérifier la syntaxe avant d’exécuter un playbook via l’option « –syntax-check ».

Conclusion

Ansible, c’est un peu comme le couteau suisse de l’automatisation : simple, puissant et prêt à l’emploi. Il s’adapte aussi bien à des petites équipes qu’à de plus gros projets, et vous permet d’améliorer la cohénrece, la qualité et la rapidité de vos déploiements.

Et cerise sur le gâteau : il est possible de « lier » Ansible et Terraform pour que ce dernier lui communique les informations sur les machines qu’il vient de créer (IP, petit nom, etc.) en générant automatiquement un inventaire ! C’est pas beau ça ? Imaginez un peu :

• Je mets à jour mon code que je push sur Git
• Et là, la magie opère ! Sans intervention de ma part, un pipeline CI/CD relie mon code, me renvoie des informations en cas de problèmes de syntaxe ou autre, exécute automatiquement Terraform et Ansible et j’ai plus qu’à me connecter sur mon appli qui sera déjà installée et configurée ! J’adore !

Comme toujours, je rappelle le plus important : Ansible n’est qu’un outil ! Il peut devenir votre meilleur allié pour une infra fiable et sereine mais cela nécessite un process clair en amont, compris, partagé et appliqué. La préparation humaine a encore de beaux jours devant elle alors profitez-en pour réfléchir avec bonne humeur et ouverture d’esprit !