Premier inventaire Ansible : INI minimal puis YAML structuré

L’inventaire est le fichier qui dit à Ansible quels hôtes piloter et comment les contacter. Sans inventaire, ansible-playbook ne sait littéralement rien : ni les IPs, ni les utilisateurs SSH, ni les groupes logiques. Cette page écrit votre tout premier inventaire en deux versions — INI minimal pour comprendre, puis YAML structuré pour passer à l’échelle. Validation avec ansible-inventory --graph et --list à chaque modification — c’est exactement le format attendu à l’examen RHCE.

all:
  children:
    webservers:
      hosts:
        web1.lab:
          ansible_host: 10.10.20.21
        web2.lab:
          ansible_host: 10.10.20.22
    dbservers:
      hosts:
        db1.lab:
          ansible_host: 10.10.20.31

ansible-inventory --graph doit afficher l’arborescence ; ansible all -m ping doit retourner pong. Si ça plante, les détails (variables de connexion, groupes parents, patterns) sont ci-dessous.

Ce que vous allez apprendre

Écrire un inventaire INI minimal à 4 hôtes en moins de 5 lignes ;
Convertir cet inventaire en YAML structuré avec groupes parents et variables de groupe ;
Définir les variables de connexion clés : ansible_host, ansible_user, ansible_python_interpreter, ansible_ssh_private_key_file ;
Valider l’inventaire avec ansible-inventory --graph (vue arborescente) et --list (vue exhaustive) ;
Limiter une commande à un sous-ensemble avec --limit et les patterns d’hôtes (webservers:!web1, webservers:&db1).

Prérequis

Le lab provisionné et préparé (cf. Préparer le lab KVM et Préparer les nœuds gérés) ;
ansible-core installé sur le poste de contrôle ;
Une clé SSH (ssh/id_ed25519) qui passe en ssh ansible@web1.lab.

Version 1 — l’inventaire INI minimal

Le format INI est l’historique d’Ansible, encore très utilisé pour les inventaires courts. Créez un fichier inventory/hosts.ini :

[control]
control-node.lab ansible_host=10.10.20.10

[webservers]
web1.lab ansible_host=10.10.20.21
web2.lab ansible_host=10.10.20.22

[dbservers]
db1.lab ansible_host=10.10.20.31

[rhce_lab:children]
webservers
dbservers

Trois conventions à retenir :

[groupe] déclare un groupe et liste ses hôtes en dessous ;
hostname ansible_host=IP sépare le nom logique (utilisé dans les commandes) de l’IP réelle (utilisée pour la connexion) ;
[parent:children] déclare un groupe parent qui agrège plusieurs sous-groupes — pratique pour cibler rhce_lab (= web1 + web2 + db1) en une seule fois.

Version 2 — l’inventaire YAML structuré

Au-delà de quelques hôtes, le YAML devient plus lisible et permet des variables structurées. Voici le inventory/hosts.yml du lab :

---
all:
  vars:
    ansible_user: ansible
    ansible_ssh_private_key_file: "{{ playbook_dir | default('.') }}/ssh/id_ed25519"
    ansible_python_interpreter: /usr/bin/python3.12

  children:
    control:
      hosts:
        control-node.lab:
          ansible_host: 10.10.20.10

    webservers:
      hosts:
        web1.lab:
          ansible_host: 10.10.20.21
        web2.lab:
          ansible_host: 10.10.20.22

    dbservers:
      hosts:
        db1.lab:
          ansible_host: 10.10.20.31

    rhce_lab:
      children:
        webservers:
        dbservers:

Trois différences notables avec la version INI :

Les variables globales (ansible_user, clé SSH, interpréteur Python) sont déclarées une seule fois sous all.vars au lieu d’être répétées sur chaque ligne ;
Les groupes parents s’écrivent naturellement avec children: imbriqué — pas de syntaxe spéciale [parent:children] ;
Le format gère les variables complexes : listes, dictionnaires, structures imbriquées (impossible à exprimer en INI).

C’est ce format que vous utiliserez dès qu’un inventaire dépasse 5 hôtes ou que vous avez besoin de variables structurées.

Valider la structure avec `ansible-inventory`

Quel que soit le format choisi, le moteur Ansible résout l’inventaire avant chaque commande. La commande ansible-inventory vous montre exactement ce qu’il a vu — sans rien exécuter sur les managed nodes.

Vue arborescente avec `--graph`

ansible-inventory -i inventory/hosts.yml --graph

Sortie attendue :

@all:
  |--@ungrouped:
  |--@control:
  |  |--control-node.lab
  |--@webservers:
  |  |--web1.lab
  |  |--web2.lab
  |--@dbservers:
  |  |--db1.lab
  |--@rhce_lab:
  |  |--@webservers:
  |  |  |--web1.lab
  |  |  |--web2.lab
  |  |--@dbservers:
  |  |  |--db1.lab

C’est la vue de référence : on voit les 4 groupes, les hôtes affectés, et la double appartenance (web1 et web2 apparaissent dans webservers ET dans rhce_lab parce que rhce_lab agrège webservers).

Vue exhaustive par hôte avec `--host`

Pour voir précisément ce qu’Ansible sait sur un hôte particulier (variables résolues, héritage de groupes) :

ansible-inventory -i inventory/hosts.yml --host control-node.lab

Sortie :

{
    "ansible_host": "10.10.20.10",
    "ansible_python_interpreter": "/usr/bin/python3.12",
    "ansible_ssh_private_key_file": "{{ playbook_dir | default('.') }}/ssh/id_ed25519",
    "ansible_user": "ansible"
}

Les trois variables globales (ansible_user, clé SSH, interpréteur Python) ont bien été héritées depuis all.vars — vous n’avez pas eu à les répéter sur chaque hôte.

Vue complète au format YAML avec `--list --yaml`

ansible-inventory -i inventory/hosts.yml --list --yaml

Affiche tous les groupes, tous les hôtes et toutes les variables au format YAML. Pratique pour vérifier qu’une variable de groupe atterrit bien sur les bons hôtes après une refacto.

Limiter à un sous-ensemble avec `--limit`

L’inventaire n’oblige pas à cibler l’intégralité des hôtes. La syntaxe --limit <pattern> restreint l’exécution :

# Cibler tous les webservers
ansible-playbook -i inventory/hosts.yml site.yml --limit webservers

# Cibler tous les webservers SAUF web1
ansible-playbook -i inventory/hosts.yml site.yml --limit 'webservers:!web1.lab'

# Intersection : hôtes qui sont à la fois dans webservers ET dans rhce_lab
ansible-playbook -i inventory/hosts.yml site.yml --limit 'webservers:&rhce_lab'

# Liste explicite
ansible-playbook -i inventory/hosts.yml site.yml --limit 'web1.lab,db1.lab'

Ces patterns d’hôtes sont identiques pour les commandes ad-hoc et pour --limit. Vous y reviendrez dans la page suivante sur les commandes ad-hoc.

Pièges fréquents

Symptôme	Cause	Fix
`provided hosts list is empty, only localhost is available`	Mauvais chemin vers l’inventaire	Vérifier `-i inventory/hosts.yml` ou positionner `inventory =` dans `ansible.cfg`
`[WARNING]: Unhandled error in Python interpreter discovery`	`ansible_python_interpreter` non posé sur des hôtes hétérogènes	Mettre `ansible_python_interpreter: /usr/bin/python3.12` (ou la bonne version) en variable de groupe
Une variable d’`all.vars` ne s’applique pas à un hôte	Variable redéfinie au niveau hôte qui écrase la globale	`ansible-inventory --host <name>` pour voir la valeur réellement appliquée
`web1.lab` introuvable mais `web1` fonctionne	FQDN vs nom court — Ansible ne réécrit pas	Utiliser exactement le nom déclaré dans l’inventaire, sans suffixe `.lab` ajouté à la volée

À retenir

L’inventaire dit à Ansible quels hôtes piloter (hostname + ansible_host pour l’IP).
Le format INI convient pour 1 à 10 hôtes ; le format YAML s’impose dès qu’on a des variables de groupe ou des structures complexes.
all.vars est le bon endroit pour les variables partagées par tous les hôtes (ansible_user, clé SSH).
ansible-inventory --graph affiche l’arbre des groupes et hôtes ; --host <name> montre les variables résolues pour un hôte.
Les patterns d’hôtes (webservers:!web1, webservers:&db1) sont la base du ciblage Ansible et fonctionnent partout (commandes ad-hoc, --limit, hosts: d’un play).

Prochaines étapes

Première connexion SSH ssh-keygen Ed25519, ssh-copy-id, ansible all -m ping — la chaîne fonctionnelle bout en bout

Commandes ad-hoc Maîtriser ansible -m sur des patterns d'hôtes : ping, setup, dnf, service, copy, file

Premier playbook Du ad-hoc au playbook : installer nginx, ouvrir port 80, démarrer le service de manière idempotente