Inventaire statique YAML Ansible : format moderne et expressif

Le format YAML est le format moderne et recommandé pour les inventaires Ansible en 2026. Plus expressif que l'INI : il accepte les listes, les dicts imbriqués, les ancres (& / *), et reste lisible sur des inventaires volumineux. C'est le format adopté par les rôles Galaxy de qualité et la plupart des projets en équipe.

L'inconvénient face à l'INI : la syntaxe est plus stricte (indentation 2 espaces, : après chaque clé). Mais une fois le réflexe acquis, l'expressivité justifie largement l'effort.

Ce que vous allez apprendre

• Écrire un inventaire YAML complet avec la structure all.children.<groupe>.hosts.<host>.
• Définir des variables au niveau host, groupe, ou top-level (all.vars).
• Créer des sous-groupes imbriqués sans syntaxe spéciale.
• Utiliser des listes et dicts dans les variables (impossible en INI).
• Migrer un inventaire INI existant vers YAML.

Anatomie d'un fichier YAML minimal

---
all:
  children:
    webservers:
      hosts:
        web1.lab:
        web2.lab:
    dbservers:
      hosts:
        db1.lab:

La structure est strictement hiérarchique :

• all est le groupe racine implicite (tous les hôtes y appartiennent).
• children: liste les sous-groupes.
• hosts: liste les hôtes du groupe.
• Chaque hôte est une clé (avec : final), valeur vide ou dict de variables.

Le : après web1.lab: n'est pas une faute, c'est la syntaxe YAML pour dire « cette clé existe, valeur vide ou nested ». Sans le :, YAML refuse le fichier.

Variables au niveau host

Pour qu'Ansible sache comment se connecter :

---
all:
  children:
    webservers:
      hosts:
        web1.lab:
          ansible_host: 10.10.20.21
          http_port: 8080
        web2.lab:
          ansible_host: 10.10.20.22
          http_port: 8081
    dbservers:
      hosts:
        db1.lab:
          ansible_host: 10.10.20.31
          ansible_port: 2222

Avantage YAML : indentation explicite, types préservés (http_port: 8080 est un int, pas une string). En INI, tout est string par défaut.

Variables de groupe (vars:)

Variables partagées par tous les hôtes d'un groupe :

---
all:
  children:
    webservers:
      hosts:
        web1.lab:
        web2.lab:
      vars:
        http_port: 8080
        worker_count: 4
        nginx_config:
          worker_processes: auto
          worker_connections: 1024

vars: est au même niveau que hosts:. Chaque hôte du groupe webservers reçoit ces 3 variables. Important : nginx_config est un dict, impossible à exprimer en INI sans astuce JSON.

Préférer group_vars/ pour les variables longues

Mettre 30 lignes de vars: dans le fichier inventaire devient illisible. Préférer group_vars/webservers.yml à côté de l'inventaire, c'est le pattern standard en 2026. Voir la page dédiée.

Variables globales, all.vars

Pour des variables qui s'appliquent à tous les hôtes :

---
all:
  vars:
    ansible_user: ansible
    ansible_ssh_private_key_file: ~/.ssh/lab_ed25519
    ansible_python_interpreter: /usr/bin/python3.12

  children:
    webservers:
      hosts:
        web1.lab:
        web2.lab:
    dbservers:
      hosts:
        db1.lab:

all.vars: est l'équivalent YAML du [all:vars] INI. Idéal pour les paramètres SSH partagés (utilisateur, clé, interpréteur Python).

Sous-groupes imbriqués

Pour grouper plusieurs groupes :

---
all:
  children:
    webservers:
      hosts:
        web1.lab:
        web2.lab:

    dbservers:
      hosts:
        db1.lab:

    prod:
      children:
        webservers:
        dbservers:
      vars:
        deploy_env: production

prod.children: liste les groupes membres. Les hôtes de webservers et dbservers héritent de deploy_env: production. Plus lisible qu'en INI où les :children sont disséminés.

Imbriquer profondément est possible :

prod:
  children:
    europe:
      children:
        webservers:
        dbservers:
    asia:
      children:
        webservers_asia:

Listes dans les variables, l'avantage YAML

Impossible en INI, naturel en YAML :

all:
  vars:
    backup_servers:
      - backup1.lab
      - backup2.lab
      - backup3.lab
    allowed_admins:
      - alice
      - bob
      - charlie

Utilisable directement dans un playbook :

- name: Distribuer les clés admin
  ansible.posix.authorized_key:
    user: "{{ item }}"
    key: "{{ lookup('file', 'admin_keys/' + item + '.pub') }}"
  loop: "{{ allowed_admins }}"

Avec INI, il faudrait passer par un fichier group_vars/all.yml séparé.

Dicts imbriqués, configurations complexes

all:
  children:
    webservers:
      vars:
        nginx:
          version: "1.26.1"
          worker_processes: auto
          gzip:
            enabled: true
            level: 6
            types:
              - text/plain
              - text/css
              - application/json

Hiérarchie complète d'une config nginx exposée comme variables. Accès dans un template Jinja : {{ nginx.gzip.level }} ou {{ nginx.gzip.types | join(' ') }}.

Ancres et alias YAML, DRY

Quand plusieurs hôtes partagent une portion identique de config :

all:
  vars:
    common_ssh_args: &common_ssh
      ansible_user: ansible
      ansible_port: 2222
      ansible_ssh_private_key_file: ~/.ssh/lab_ed25519

  children:
    webservers:
      hosts:
        web1.lab:
          <<: *common_ssh
          ansible_host: 10.10.20.21
        web2.lab:
          <<: *common_ssh
          ansible_host: 10.10.20.22

&common_ssh définit une ancre, <<: *common_ssh fusionne le contenu dans le host. Évite de répéter ansible_user, ansible_port, etc. sur chaque ligne. Avancé, utiliser avec parcimonie pour préserver la lisibilité.

Exemple complet, homelab type

/home/bob/Projets/lab-ansible/inventory/hosts.yml

---
all:
  vars:
    ansible_user: ansible
    ansible_ssh_private_key_file: "{{ inventory_dir }}/../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
      vars:
        http_port: 8080
        environment: production

    dbservers:
      hosts:
        db1.lab:
          ansible_host: 10.10.20.31
      vars:
        postgres_version: 17

    rhce_lab:
      children:
        webservers:
        dbservers:

Ce qu'on lit : 4 hôtes managés, paramètres SSH partagés au top, deux groupes par rôle avec leurs variables propres, un méta-groupe rhce_lab qui regroupe webservers + dbservers.

Migrer un inventaire INI vers YAML

Cas typique : vous reprenez un projet historique en INI et passez à YAML.

Avant (INI) :

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

[webservers:vars]
http_port=8080

[dbservers]
db1.lab ansible_host=10.10.20.31

[prod:children]
webservers
dbservers

Après (YAML) :

---
all:
  children:
    webservers:
      hosts:
        web1.lab:
          ansible_host: 10.10.20.21
        web2.lab:
          ansible_host: 10.10.20.22
      vars:
        http_port: 8080
    dbservers:
      hosts:
        db1.lab:
          ansible_host: 10.10.20.31
    prod:
      children:
        webservers:
        dbservers:

Astuce : ansible-inventory -i hosts.ini --list --yaml génère automatiquement la version YAML, point de départ propre pour la migration.

Pièges courants

Symptôme	Cause	Fix
Failed to parse inventory	Indentation incohérente (mélange espaces/tabs)	Toujours 2 espaces, jamais de tabs
Variable host invisible	Pas de : après le nom de l'hôte	web1.lab: (avec :) puis indentation
vars: vu comme un host	vars: mis sous hosts: au lieu d'à côté	vars: au même niveau que hosts:
Listes converties en strings	Mauvaise syntaxe YAML pour les listes	- item (tiret + espace) en début de ligne indentée
Booléens YAML 1.1 piégeux	enabled: yes interprété comme True	Préférer enabled: true (YAML 1.2 strict)

Glissez pour voir

À retenir

• Format YAML = recommandé en 2026. Plus expressif, plus lisible sur gros inventaires.
• Structure stricte : all.children.<groupe>.hosts.<host>.
• vars: au même niveau que hosts: pour des variables de groupe.
• all.vars: pour les variables partagées par tous les hôtes.
• Listes et dicts dans les variables, impossible en INI, naturel en YAML.
• Ancres & / * pour réutiliser des blocs sans dupliquer.
• Migration INI→YAML : ansible-inventory --list --yaml génère automatiquement.

Mettre en pratique

Recopier un inventaire d'exemple n'apprend pas grand-chose, l'écrire de zéro oblige à trancher chaque niveau. Ce lab vous fait déclarer vos groupes d'hôtes, un groupe parent avec children et des variables de groupe, sur une structure vide. La preuve se fait en deux temps : ansible-inventory --graph doit montrer l'arborescence attendue, puis ansible -m ping doit joindre les machines déclarées.

Lab pratique

Écrire un inventaire statique de zéro : groupes, enfants et variables de groupe

$ dsoxlab run inventaires-statiques

Environnement : VM·Durée : ~40 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run inventaires-statiques
dsoxlab check inventaires-statiques

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

• Inventaires multiples : séparer dev, staging et prod sans dupliquer un seul playbook.
• Patterns d'hôtes : cibler les groupes imbriqués que la structure YAML permet de créer.
• Vérifier l'inventaire : afficher l'arborescence obtenue et les variables réellement résolues.

×

📖 Voir la documentation →