2.4 : Séparer topologie et configuration (jusqu’où aller dans l’inventaire)

   -     -    3 minutes
📚Ansible pour les débutants : La Tour de Contrôle
📄 Article

En 2.2, on a vu qu’on peut mettre des variables directement dans l’inventaire, via un bloc vars. Pratique, lisible, tout au même endroit. Mais il y a une limite à ne pas dépasser — et le meilleur moyen de la comprendre, c’est de regarder un cas où ça part un peu trop loin.

Un exemple qui pousse le curseur trop loin

Imaginons que Nordika automatise le redémarrage nocturne de ses stacks Docker avec Ansible (on reverra ce cas en détail dans le bonus de fin de formation). Chaque serveur Docker héberge ses propres containers, différents d’un serveur à l’autre. Voici ce qu’un admin pressé pourrait être tenté d’écrire, directement dans l’inventaire :

all:
  hosts:
    nrd-dck-app-1:
      ansible_host: 10.0.9.20
      docker_stacks:
        - path: /containers/bookstack
        - path: /containers/vaultwarden
      docker_stacks_priority:
        - path: /containers/traefik
          extra_sleep: 15
        - path: /containers/authentik
          extra_sleep: 60
          compose_scale:
            worker: 2
    nrd-dck-app-2:
      ansible_host: 10.0.9.21
      docker_stacks:
        - path: /containers/listmonk
        - path: /containers/drawio

Ça fonctionne très bien techniquement. Le problème n’est pas la syntaxe, c’est l’endroit : ces listes commencent déjà à alourdir sérieusement chaque ligne d’hôte, et l’inventaire perd sa lisibilité de base — « qui sont mes machines » se noie dans « que font-elles exactement ».

Pourquoi ce n’est pas non plus un cas pour group_vars

On pourrait être tenté de tout remonter dans group_vars/all.yml, comme on l’a fait pour ansible_user en 2.2. Mais ce serait une erreur ici : docker_stacks n’est pas partagé par tout le parc, ni même par tout le groupe docker-servers. nrd-dck-app-1 et nrd-dck-app-2 n’hébergent pas les mêmes containers. Mettre ça dans group_vars donnerait la même liste de stacks à toutes les machines du groupe — ce qui casserait complètement la logique du playbook.

Cette configuration est propre à un seul hôte. C’est donc host_vars qu’il faut utiliser, pas group_vars.

La bonne pratique : host_vars/<nom_de_l_hôte>.yml

mon-projet/
├── inventaire.yaml
└── host_vars/
    ├── nrd-dck-app-1.yml
    └── nrd-dck-app-2.yml

host_vars/nrd-dck-app-1.yml :

docker_stacks:
  - path: /containers/bookstack
  - path: /containers/vaultwarden

docker_stacks_priority:
  - path: /containers/traefik
    extra_sleep: 15
  - path: /containers/authentik
    extra_sleep: 60
    compose_scale:
      worker: 2

host_vars/nrd-dck-app-2.yml :

docker_stacks:
  - path: /containers/listmonk
  - path: /containers/drawio

inventaire.yaml redevient léger, et se concentre uniquement sur la topologie :

all:
  hosts:
    nrd-dck-app-1:
      ansible_host: 10.0.9.20
    nrd-dck-app-2:
      ansible_host: 10.0.9.21
  children:
    docker-servers:
      hosts:
        nrd-dck-app-1:
        nrd-dck-app-2:

Le résultat pour Ansible est strictement identique — ces variables restent accessibles exactement de la même façon dans vos playbooks. Ce qui change, c’est la clarté : l’inventaire dit « qui », chaque fichier host_vars dit « quoi, pour cette machine précisément ».

Le bon réflexe à retenir : à qui appartient vraiment la donnée ?

Une règle simple pour choisir entre les trois options vues jusqu’ici :

  • La variable est identique pour toute la flotte (ex. ansible_user) → group_vars/all.yml.
  • La variable est partagée par un sous-ensemble cohérent de machines (ex. http_port pour tous les serveurs web) → group_vars/<nom_du_groupe>.yml.
  • La variable est propre à une seule machine, différente d’une machine à l’autre (ex. la liste de stacks Docker d’un serveur précis) → host_vars/<nom_de_l_hôte>.yml.

Le critère n’est pas « est-ce que c’est une liste ou une seule valeur », c’est à quel niveau cette information est-elle vraie : à toute la flotte, à un groupe, ou à une machine précise.

Dans la prochaine leçon, on regarde les patterns d’hôtes et l’option --limit, pour cibler finement une partie de la flotte sans avoir à créer un nouveau groupe à chaque fois.