Inventaires Ansible : statique, dynamique, group

L'inventaire est la source de vérité d'Ansible : c'est lui qui dit quelles machines sont gérées, comment les regrouper, et quelles variables chaque machine reçoit. Sans inventaire bien structuré, vos playbooks deviennent rapidement illisibles — codes en dur, conditionnels qui s'empilent, secrets qui se baladent. Cette section couvre les inventaires statiques (INI/YAML édités à la main, au programme RHCE) et les inventaires dynamiques (AWS, NetBox, Proxmox, scripts custom — incontournables au-delà de 50 hôtes).

Aller droit au but

🚀 Inventaire YAML (recommandé 2026) Format moderne avec all.children, plus expressif que INI

📚 group_vars / host_vars La convention 90 % des projets : un fichier par groupe, par host

🎯 Patterns d'hôtes & --limit web*, &prod, !staging, ranges web[01:05] — tir précis

🔥 Inventaire dynamique (cloud) Plugins AWS, NetBox, Proxmox — quand le statique ne suffit plus

Ce que vous allez apprendre

Choisir entre INI et YAML pour vos inventaires statiques.
Structurer group_vars/ et host_vars/ pour des configs lisibles.
Sélectionner un sous-ensemble d'hôtes via --limit et les patterns (web*, :&prod, :!staging).
Vérifier un inventaire avec ansible-inventory --graph et --list.
Combiner plusieurs inventaires pour gérer dev/staging/prod.
Découvrir les inventaires dynamiques (plugins AWS, Proxmox, NetBox, scripts custom).

Prérequis

Avant cette section, vous devez avoir :

Validé les sections Découvrir et Premiers pas.
Un lab fonctionnel avec 4 hôtes (control-node, web1, web2, db1) qui répondent à ansible all -m ping.
Compris la différence entre hosts: dans un play et un groupe d'inventaire.

Mon retour d'expérience — pour ceux qui veulent comprendre

Si l'une des cartes en haut de page vous a déjà orienté, vous êtes parti sur le bon pied. La suite de cette page s'adresse à ceux qui veulent comprendre la philosophie de cette section : pourquoi je préfère YAML à INI dès qu'il y a deux groupes, pourquoi group_vars/ est la convention non négociable, et pourquoi je décourage le passage prématuré au dynamique.

J'ai vu des équipes basculer en inventaire dynamique « parce que c'est plus pro » alors qu'elles avaient 12 hôtes — résultat : appel API à chaque commande, lab impossible à reproduire offline, debug impossible quand AWS ne répond pas. Le dynamique a un coût caché énorme quand on n'en a pas vraiment besoin. Les sections qui suivent compilent les habitudes que je n'aurais jamais relâchées sur un projet Ansible que je dirige.

Le rôle central de l'inventaire

L'inventaire répond à quatre questions simultanément :

Qui : la liste des hôtes managed (web1.lab, db1.lab...).
Comment : avec quels paramètres SSH (ansible_host, ansible_user, ansible_port).
Où : dans quels groupes (webservers, dbservers, prod, dev).
Quoi : avec quelles variables (http_port, db_password, app_version).

Sans inventaire propre, vous mélangez vite ces 4 dimensions dans le code des playbooks — résultat : impossible de déployer en staging sans modifier le playbook lui-même. Avec un inventaire bien structuré, le code reste générique et chaque environnement a son inventaire dédié.

Statique vs dynamique — quand utiliser lequel ?

Critère	Statique (INI/YAML)	Dynamique (plugin)
Nombre d'hôtes	< 50	> 50 ou cloud
Provisionnement	Manuel ou Terraform	Cloud auto-scaling
Source de vérité	Le fichier inventaire	Console cloud, NetBox, CMDB
Scope RHCE EX294	✅ Au programme	❌ Hors-périmètre
Vitesse	Instantané	Lent (appel API)
Cas typique	Lab, petite prod, RHCE	Cloud public, parc évolutif

Règle pragmatique : commencer toujours en statique. Migrer en dynamique uniquement quand l'inventaire change plusieurs fois par jour ou dépasse 50 entrées.

Ce que je défends pour les inventaires

Cinq positions tranchées que cette section assume :

YAML par défaut, dès qu'il y a deux groupes. INI est lisible en 5 secondes, mais sa hiérarchie de groupes ([group:children], [group:vars]) devient illisible au-delà de 3 niveaux. YAML = all.children propre et expressif — démarrer en YAML évite la migration douloureuse.
group_vars/<groupe>.yml au lieu de [group:vars] dans l'inventaire ou de vars_files: dans le playbook. Un seul mécanisme, automatiquement chargé, scanné par Ansible. Mélanger ces approches crée des bugs de précédence introuvables.
host_vars/ réservé aux overrides individuels, jamais comme dépôt principal de variables. Un host_vars/web1.yml qui contient 50 variables est un signal : promouvoir la majorité dans group_vars/webservers.yml, garder dans host_vars/ uniquement ce qui est vraiment spécifique à web1.
Statique avant dynamique, sans honte. Ne basculez en dynamique qu'au-delà de 50 hôtes ou en cas de cloud auto-scaling. Le statique est plus simple, plus rapide, plus debuggable, plus reproductible offline. Le dynamique a un coût caché que beaucoup d'équipes paient sans en avoir besoin.
ansible-inventory --graph à chaque modification d'inventaire. Vérification gratuite en 1 seconde, qui détecte les fautes de frappe sur les noms de groupes et les hiérarchies cassées avant qu'un playbook ne plante.

Ce que je vous interdis

Cinq erreurs typiques sur les inventaires — chacune source de bugs ou d'incidents :

Variables sensibles en clair dans group_vars/all.yml. Un db_password: "p@ssw0rd" dans Git est un secret compromis. Toute variable sensible passe par Ansible Vault ou un secret manager — non négociable, dès le premier inventaire.
host_vars/<host>.yml placé n'importe où. Le fichier doit être à côté du fichier d'inventaire (ou du dossier d'inventaires). Ailleurs = ignoré silencieusement, variables non appliquées, debug impossible.
Inventaire en dur dans le playbook (hosts: web1.lab,web2.lab). Tue la portabilité : impossible de déployer en staging ou prod avec le même playbook. Le playbook ne nomme jamais d'hôte — il nomme un groupe (hosts: webservers), l'inventaire fait le reste.
Plusieurs inventaires fusionnés sans contrôle de précédence. -i inv1 -i inv2 fusionne avec des règles précises ; deux variables homonymes peuvent se réécrire dans un ordre que vous ne voyez pas. Tester systématiquement avec --graph + --host quand on combine des inventaires.
Migration prématurée vers le dynamique. Si votre inventaire a moins de 50 entrées et change moins d'une fois par semaine, vous n'avez pas besoin du dynamique. Vous payez de la complexité et de la latence pour rien. Restez en statique.

Le parcours en 6 étapes

Le parcours est séquentiel : chaque page suppose acquis ce qui précède.

1. Choisir un format

INI est le plus simple, YAML est plus expressif. Les deux sont valides, mais YAML s'impose en équipe.

Inventaire statique INI Format historique, simple à lire, idéal pour des labs ou petits parcs

Inventaire statique YAML Format moderne avec all.children, recommandé en production

2. Structurer les variables

C'est ici que votre inventaire devient maintenable ou se transforme en plat de spaghetti.

group_vars et host_vars La convention 90 % des projets Ansible : un fichier par groupe et par host

Inventaires multiples -i inv1 -i inv2, dossiers d'inventaires, fusion des variables, séparation dev/prod

3. Sélectionner les hôtes cibles

Patterns d'hôtes et --limit : la précision du tir Ansible.

Patterns d'hôtes web*, &prod, :, !, ranges web[01:05] — sélectionner exactement les hôtes voulus

Vérifier un inventaire ansible-inventory --graph, --list, --host pour debugger les variables résolues

4. Aller plus loin — inventaires dynamiques

Quand le statique ne suffit plus.

Concepts des plugins d'inventaire Comment fonctionne un plugin, où il vit, comment l'activer dans ansible.cfg

Plugin AWS EC2 Inventaire dynamique AWS : tags, regions, filtres, exemples concrets

Plugin NetBox NetBox comme source de vérité IPAM/DCIM, plugin officiel community

Écrire un script custom Le format JSON attendu, le hook --list/--host, fallback quand aucun plugin n'existe

La place dans la RHCE EX294

Les inventaires statiques représentent environ 15 % de l'examen RHCE — souvent en début d'épreuve quand il faut structurer le projet.

Objectif RHCE	Page couvrante
Comprendre l'inventaire statique	Statiques INI + Statiques YAML
Configurer host vars et group vars	group_vars / host_vars
Utiliser les patterns d'hôtes	Patterns d'hôtes
Valider un inventaire	Vérifier un inventaire

Les inventaires dynamiques ne sont pas testés à l'examen — vous arrivez avec un inventaire statique pré-fourni. Mais maîtriser la lecture de --graph et --list reste indispensable pour debugger.

Symptômes et fixes rapides

Pour les bugs récurrents en pratique, voici les cinq diagnostics les plus utiles à garder sous la main :

Symptôme	Cause	Fix
Variables d'hôte qui ne s'appliquent pas	`host_vars/web1.yml` mal placé (pas à côté de l'inventaire)	Placer `host_vars/` au même niveau que le fichier d'inventaire
`groups['webservers']` vide	Faute de frappe sur le nom du groupe	`ansible-inventory --graph` pour voir les groupes réels
Précédence inattendue	`host_vars/` > `group_vars/<groupe>` > `group_vars/all` mal compris	Voir la page Précédence des variables
Inventaire dynamique invisible	Plugin pas activé dans `ansible.cfg`	`[inventory] enable_plugins = aws_ec2, ...`
`--limit` n'agit pas	Pattern mal échappé en shell	Quoter : `--limit "webservers:!web1"`

À retenir

L'inventaire est la source de vérité : qui, comment, où, quoi.
YAML est le format moderne recommandé ; INI reste valable pour les petits parcs.
group_vars/ et host_vars/ sont les emplacements standard pour les variables (chargés automatiquement, pas besoin de vars_files:).
ansible-inventory --graph et --list sont vos meilleurs amis pour valider et debugger.
Statique pour le RHCE et les petits parcs, dynamique dès que le cloud entre en jeu.

Prochaines étapes

Inventaire statique YAML Le format moderne et expressif — par où commencer en 2026

group_vars / host_vars La convention qui rend votre inventaire vraiment maintenable

Patterns d'hôtes Cibler exactement les hôtes voulus sans toucher au playbook

Précédence des variables Les 22 niveaux de précédence officielle — objectif RHCE explicite