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.

Pressé ? Le squelette inventaire YAML

inventory/hosts.yml

all:
  vars:
    ansible_user: ansible
    ansible_python_interpreter: /usr/bin/python3
  children:
    webservers:
      hosts:
        web1.lab:
          ansible_host: 10.10.20.21
        web2.lab:
          ansible_host: 10.10.20.22
      vars:
        http_port: 80
    dbservers:
      hosts:
        db1.lab:
          ansible_host: 10.10.20.31
      vars:
        db_port: 3306
    rhce_lab:           # groupe parent qui regroupe les autres
      children:
        webservers:
        dbservers:

Sécurité non négociable :

• Variables sensibles JAMAIS dans l’inventaire principal — utiliser group_vars/<group>/vault.yml chiffré.
• ansible_user: au niveau all.vars plutôt que sur chaque host — DRY, centralisé, modifiable d’un coup.
• Vérifier avec ansible-inventory --graph après chaque modification — détecte les fautes de frappe sur les noms de groupes (silencieuses sinon).
• Format YAML strict : 2 espaces d’indentation, jamais de tab, : après chaque clé.

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.

Prochaines étapes

group_vars et host_vars Convention pour externaliser les variables hors du fichier inventaire

Inventaires multiples Combiner plusieurs inventaires (dev/staging/prod) avec -i inv1 -i inv2

Patterns d'hôtes Cibler des sous-ensembles avec --limit et les opérateurs

Inventaire INI (référence) Le format historique INI — pour les petits parcs ou la lecture de code legacy

×

📖 Voir la documentation →