2.1 : Inventaire YAML : hosts, groups, children

Jusqu’ici, on a tapé les adresses IP directement en ligne de commande, séparées par des virgules. Ça marche pour deux machines et un test rapide, mais ça devient vite ingérable dès que la flotte de Nordika grandit. Impossible de retenir 30 IP par cœur, et encore moins de les retaper à chaque commande.

C’est le rôle de l’inventaire : un fichier qui liste, une bonne fois pour toutes, tous les avions que votre tour de contrôle peut piloter.

La structure de base

Un inventaire Ansible au format YAML démarre toujours par la clé all, avec une sous-clé hosts :

all:
  hosts:
    web1:
      ansible_host: 10.0.1.10
    web2:
      ansible_host: 10.0.1.11
    db1:
      ansible_host: 10.0.1.20

Ici, web1, web2 et db1 sont les noms que vous donnez à vos machines dans Ansible — ils n’ont pas besoin de correspondre au hostname réel. ansible_host indique l’adresse IP (ou le nom DNS) réellement utilisée pour la connexion.

Une fois ce fichier enregistré (par exemple inventaire.yaml), vous pouvez cibler toute la flotte :

ansible all -i inventaire.yaml -m ping

Les groupes : organiser la tour par escadrille

Rarement, en pratique, on traite tous les serveurs de la même façon. Nordika a des serveurs web, des serveurs de base de données, des serveurs DNS… Chacun a besoin d’actions différentes. C’est là qu’interviennent les groupes, via la clé children :

all:
  hosts:
    web1:
      ansible_host: 10.0.1.10
    web2:
      ansible_host: 10.0.1.11
    db1:
      ansible_host: 10.0.1.20
  children:
    webservers:
      hosts:
        web1:
        web2:
    databases:
      hosts:
        db1:

Remarquez que sous children, on ne fait que référencer les noms déjà déclarés dans hosts — pas besoin de répéter ansible_host, Ansible sait déjà où les trouver.

Vous pouvez maintenant cibler un groupe précis :

ansible webservers -i inventaire.yaml -m ping

Sous-groupes : des escadrilles dans l’escadrille

Les groupes peuvent eux-mêmes contenir des sous-groupes. Utile si, par exemple, tous vos serveurs sont sous Debian, mais que certains sont aussi des serveurs web :

all:
  hosts:
    web1:
      ansible_host: 10.0.1.10
    web2:
      ansible_host: 10.0.1.11
    db1:
      ansible_host: 10.0.1.20
  children:
    debian:
      children:
        webservers:
          hosts:
            web1:
            web2:
        databases:
          hosts:
            db1:

Ici, cibler debian revient à cibler web1, web2 et db1 en même temps — le groupe parent regroupe tous les hôtes de ses sous-groupes.

Le groupe implicite ungrouped

Un hôte qui apparaît dans all.hosts mais qui n’est rattaché à aucun groupe dans children se retrouve automatiquement dans un groupe spécial nommé ungrouped. Pas d’inquiétude si vous le voyez apparaître dans certaines commandes de diagnostic (comme ansible-inventory --graph, qu’on utilisera plus tard) : c’est normal, ça ne casse rien.

Ce qu’il faut retenir

• all.hosts : la liste complète de vos machines, avec leur adresse de connexion.
• children : vos groupes, qui référencent des hôtes ou d’autres groupes.
• Un même hôte peut appartenir à plusieurs groupes en même temps (web1 peut être à la fois dans webservers et dans debian).

Dans la prochaine leçon, on regarde où ranger les variables propres à un hôte ou à un groupe — parce que l’inventaire ne sert pas qu’à lister des noms, il sert aussi à décrire leurs spécificités.