2.2 : host_vars et group_vars : où ranger quoi

On a vu en 2.1 comment lister et grouper les avions de la flotte. Mais chaque avion (ou groupe d’avions) a souvent besoin d’informations qui lui sont propres : un port SSH différent, un utilisateur de connexion spécifique, une variable métier (comme un nom de base de données). Il existe trois façons de définir ces variables, et chacune a son intérêt.

Option 1 : les variables directement sous l’hôte

La méthode la plus simple, celle qu’on a déjà croisée avec ansible_host :

all:
  hosts:
    web1:
      ansible_host: 10.0.1.10
      ansible_user: admin
      ansible_port: 2222

Parfait pour deux ou trois variables propres à une seule machine, mais ça devient vite répétitif si plusieurs hôtes partagent les mêmes réglages.

Option 2 : un bloc vars directement dans le fichier d’inventaire

Moins connue, et pourtant très pratique : on peut ajouter une clé vars à côté de hosts, aussi bien sous all que sous n’importe quel groupe. Toutes les variables qui s’y trouvent s’appliquent à tous les hôtes de ce groupe, sans avoir à les répéter sur chaque hôte :

all:
  hosts:
    web1:
      ansible_host: 10.0.1.10
    web2:
      ansible_host: 10.0.1.11
    db1:
      ansible_host: 10.0.1.20
  vars:
    ansible_user: admin
  children:
    webservers:
      hosts:
        web1:
        web2:
      vars:
        http_port: 80
        document_root: /var/www/html
    databases:
      hosts:
        db1:
      vars:
        mysql_port: 3306

Ici, ansible_user: admin sous all.vars s’applique à toute la flotte. http_port et document_root sous webservers.vars ne s’appliquent qu’à web1 et web2. Un seul fichier, toute la configuration visible d’un coup d’œil — pas besoin d’aller ouvrir cinq fichiers différents pour comprendre ce qui s’applique à quoi.

C’est un bon compromis quand votre inventaire reste de taille raisonnable : tout est au même endroit, ce qui rend le fichier particulièrement lisible pour quelqu’un qui le découvre.

Option 3 : les dossiers host_vars/ et group_vars/

Dès que l’inventaire grossit vraiment (des dizaines d’hôtes, des variables plus sensibles comme des mots de passe), même un bloc vars bien organisé finit par alourdir le fichier. La bonne pratique devient alors de séparer la structure (qui sont mes hôtes) de la configuration (quelles sont leurs particularités), dans des fichiers dédiés à côté de l’inventaire :

mon-projet/
├── inventaire.yaml
├── group_vars/
│   ├── all.yml
│   ├── webservers.yml
│   └── databases.yml
└── host_vars/
    ├── web1.yml
    └── db1.yml

Le nom du fichier doit correspondre exactement au nom du groupe ou de l’hôte tel qu’il apparaît dans l’inventaire.

group_vars/webservers.yml :

http_port: 80
document_root: /var/www/html

host_vars/db1.yml :

mysql_root_password: SuperRoot123!
mysql_port: 3306

Pourquoi c’est important : ordre de priorité

Si une même variable est définie à plusieurs endroits, Ansible applique une règle simple à retenir pour l’instant : plus une variable est spécifique, plus elle l’emporte. Une variable d’hôte écrase celle de son groupe, qui elle-même écrase celle de all — peu importe qu’elles soient écrites inline, en bloc vars, ou dans un dossier host_vars/group_vars. On détaillera l’ordre complet de précédence (il y a plus de deux niveaux) en section 4.

Ce qu’il faut retenir

• Inline sous l’hôte → une variable propre à une seule machine, sans rien de partagé.
• Bloc vars dans l’inventaire → variables partagées par un groupe, tout en gardant un seul fichier lisible.
• host_vars/ et group_vars/ → dès que l’inventaire grandit, ou que certaines variables méritent d’être chiffrées séparément (on y reviendra avec Vault en section 8).

Il n’y a pas de méthode « meilleure » dans l’absolu : le bloc vars inline convient très bien à un inventaire de lab ou de petite PME comme Nordika à ses débuts ; les dossiers séparés prennent tout leur sens quand plusieurs personnes travaillent sur le même dépôt Git.

Dans la prochaine leçon, on met tout ça en pratique en analysant un vrai inventaire de production — avec ses subtilités et ses raccourcis qu’on ne devine pas forcément en théorie.