Inventaire, playbook, module : la trinité Ansible
Résumé : ces trois mots reviennent sans arrêt dans toute discussion sur Ansible, et 8 débutants sur 10 les confondent. Cette leçon les distingue une bonne fois pour toutes avec l'analogie d'un chef d'orchestre, puis montre un vrai fichier YAML pour ancrer les concepts.
1. L'analogie de l'orchestre symphonique
Imaginez un chef d'orchestre qui dirige une symphonie. Cette scène met en jeu trois éléments distincts :
Le mapping avec Ansible :
| Élément d'orchestre | Équivalent Ansible |
|---|---|
| La partition (ce que l'orchestre doit jouer) | Playbook — le fichier YAML qui décrit les tâches à faire |
| La liste des musiciens et pupitres | Inventaire — le fichier qui liste les serveurs et leurs groupes |
| Chaque instrument spécialisé | Module — chaque brique qui sait faire une action précise (installer un paquet, copier un fichier…) |
Il y a un quatrième concept qu'on verra un peu plus loin : le rôle, qui est une partition partageable et réutilisable.
2. L'inventaire — le carnet d'adresses de vos serveurs
L'inventaire est le premier fichier que vous écrivez quand vous démarrez avec Ansible. Il liste toutes les machines qu'Ansible va pouvoir piloter, et les groupe logiquement.
Exemple d'inventaire (au format .ini, format historique et le plus lisible) :
[web]
web1.exemple.com
web2.exemple.com
web3.exemple.com
[db]
db1.exemple.com
db2.exemple.com
[cache]
redis1.exemple.com
[production:children]
web
db
cache
Décodage :
[web],[db],[cache]sont des groupes.- Chaque ligne sous un groupe est un serveur (host).
[production:children]est un groupe de groupes — dire « production » revient à désigner tous les serveurs web, db et cache.
Ce que ça permet :
Bonus : dans le monde cloud moderne, l'inventaire peut être dynamique — construit automatiquement à partir d'AWS, GCP, Azure. Ansible interroge le cloud, obtient la liste des machines actives, et met à jour l'inventaire tout seul.
3. Le playbook — la partition musicale
Un playbook est un fichier YAML qui décrit une série de tâches à exécuter sur les serveurs d'un ou plusieurs groupes de l'inventaire.
Voici à quoi ressemble un playbook réel (n'essayez pas de le retenir, on veut juste voir la forme) :
- name: Configuration des serveurs web
hosts: web
become: true
tasks:
- name: Installer Nginx
apt:
name: nginx
state: present
update_cache: true
- name: Copier la configuration Nginx
copy:
src: files/nginx.conf
dest: /etc/nginx/nginx.conf
mode: '0644'
- name: Démarrer et activer Nginx
service:
name: nginx
state: started
enabled: true
Décodage clé par clé :
| Ligne YAML | Ce qu'elle dit à Ansible |
|---|---|
name: Configuration des serveurs web | Titre humain de ce play |
hosts: web | Cible le groupe web de l'inventaire |
become: true | Élève les privilèges (équivalent de sudo) |
tasks: | Liste des tâches à exécuter dans l'ordre |
apt: name: nginx | Utilise le module apt pour installer nginx |
copy: src: ... dest: ... | Utilise le module copy pour envoyer un fichier |
service: state: started | Utilise le module service pour démarrer nginx |
Ce fichier est votre source unique de vérité : chaque personne qui lance ce playbook sur le groupe web obtient exactement le même résultat. Fin de la dérive de configuration.
4. Les modules — les briques spécialisées
Un module Ansible est une petite brique de code Python qui sait faire une action précise sur un serveur cible. C'est l'unité de travail d'Ansible.
Il en existe plus de 3000 dans le monde Ansible en 2026, répartis en grandes familles :
Ce qui rend les modules puissants :
- Ils sont écrits en Python mais transparents pour l'utilisateur — vous écrivez du YAML, Ansible transmet et exécute le Python côté serveur.
- Ils sont idempotents : lancer deux fois
apt: name=nginx state=presentne réinstalle pas nginx si déjà installé. - Ils rapportent leur résultat :
changed(quelque chose a été modifié),ok(déjà dans l'état attendu),failed(erreur).
Vous pouvez aussi écrire vos propres modules en Python. Mais 99 % des besoins réels sont déjà couverts par les modules existants.
5. Le rôle — la partition partageable
Un rôle Ansible est un ensemble structuré de playbooks, variables, fichiers et templates, empaqueté pour être réutilisable et partageable.
Bénéfice majeur : au lieu de réécrire à chaque fois « installer et configurer nginx », on télécharge un rôle communautaire qui fait déjà tout, correctement, testé par des milliers d'utilisateurs.
C'est via Ansible Galaxy — l'équivalent Docker Hub pour Ansible — que ces rôles sont partagés. On en reparle dans la leçon 5.
6. Le cycle complet — de l'idée à l'exécution
Voici comment ces quatre briques s'articulent au quotidien.
Ce cycle est le fondement de tout usage professionnel d'Ansible. En CI/CD, il est automatisé : un git push sur le dépôt d'infrastructure déclenche le lancement d'un ansible-playbook, avec relecture obligatoire via pull request.
7. Ad-hoc vs playbook — les deux modes d'exécution
Ansible offre deux modes d'utilisation, complémentaires.
Exemple ad-hoc pour tester la connectivité :
ansible all -m ping
Cette commande demande à Ansible de dire « bonjour » à tous les serveurs de l'inventaire. Utile pour vérifier que votre inventaire est correct et que SSH fonctionne partout, avant d'écrire vos premiers playbooks.
En pratique, on utilise 90 % de playbooks et 10 % d'ad-hoc dans une équipe mûre.
8. La question qui piège en entretien
« Quelle est la différence entre un playbook et un rôle ? »
Réponse claire : un playbook est un fichier YAML qui décrit les tâches à faire. Un rôle est un playbook structuré, empaqueté et réutilisable — avec ses fichiers, ses variables, ses templates. On peut voir le rôle comme un playbook + son environnement, prêt à être partagé.
Analogie : un playbook c'est comme un script bash isolé. Un rôle c'est comme un projet Git complet avec structure, variables, fichiers.
Autre question fréquente : « Puis-je faire d'Ansible autre chose que du Linux ? »
Oui : Ansible pilote Windows via WinRM, les équipements réseau Cisco/Juniper, les API cloud (AWS, Azure, GCP), les bases de données, Docker, Kubernetes. C'est ce qui explique sa longévité — c'est un vrai outil universel d'automatisation, pas juste un outil Linux.
Retenir en 30 secondes
- Inventaire = carnet d'adresses de vos serveurs, groupés logiquement.
- Playbook = partition musicale — fichier YAML qui décrit les tâches à exécuter.
- Module = instrument spécialisé — brique Python qui sait faire une action précise.
- Rôle = partition partageable — playbook structuré et réutilisable.
- Deux modes : ad-hoc (une commande) et playbook (fichier versionné).
- Ansible Galaxy est le catalogue mondial de rôles partagés.
Suivant : Agentless et idempotence : les 2 principes fondateurs →