2.3 : Cas pratique : lire un inventaire de prod (hôtes sans ansible_host, groupes imbriqués)

La théorie, c’est bien. Mais un inventaire réel, en production, ressemble rarement aux exemples propres à trois hôtes qu’on a vus jusqu’ici. Voici un inventaire tel qu’on pourrait le croiser chez Nordika, une fois son parc de serveurs Docker bien installé :

all:
  hosts:
    nrd-abd-lyon-1:
      ansible_host: 10.0.8.12
    nrd-app-supervision-1:
    nrd-dck-app-1:
      ansible_host: 10.0.9.20
    nrd-dck-app-2:
      ansible_host: 10.0.9.21
    nrd-dck-infra-net-1:
      ansible_host: 10.0.9.5
    nrd-rproxy-dmz-1:
      ansible_host: 172.16.1.3
  children:
    docker-servers:
      hosts:
        nrd-dck-app-1:
        nrd-dck-app-2:
        nrd-dck-infra-net-1:
        nrd-rproxy-dmz-1:
adguard_instances:
  hosts:
    doh1:
    doh2:

Décortiquons trois détails qu’on ne voit jamais dans un exemple pédagogique simplifié, mais qu’on croise tout le temps en vrai.

Détail 1 : un hôte sans ansible_host

Regardez nrd-app-supervision-1 : contrairement à ses voisins, il n’a aucune ligne ansible_host en dessous.

Ce n’est pas un oubli. Quand ansible_host n’est pas précisé, Ansible utilise directement le nom de l’hôte tel qu’il apparaît dans l’inventaire comme cible de connexion — ici, il va essayer de joindre une machine nommée nrd-app-supervision-1, en comptant sur la résolution DNS ou sur le fichier /etc/hosts du nœud de contrôle pour la retrouver.

C’est un raccourci courant quand tous vos serveurs sont déjà enregistrés dans un DNS interne : pas besoin de dupliquer l’IP dans l’inventaire, le nom suffit. Le même principe s’applique à doh1 et doh2 dans le groupe adguard_instances.

⚠️ Piège classique pour un débutant qui reprend cet inventaire : si votre DNS ne connaît pas le nom, la connexion échoue avec une erreur de résolution, pas une erreur Ansible. Le réflexe à avoir : ping nrd-app-supervision-1 depuis le nœud de contrôle avant de blâmer Ansible.

Détail 2 : une convention de nommage cachée dans les noms

Regardez bien les noms d’hôtes : nrd-dck-app-1, nrd-dck-infra-net-1, nrd-rproxy-dmz-1. Ce n’est pas aléatoire — c’est une convention de nommage qui encode plusieurs informations directement dans le nom :

• nrd- : Nordika (l’entreprise)
• dck / rproxy / abd : son rôle (docker, reverse-proxy, annuaire…)
• app / infra / dmz : sa fonction ou sa zone réseau
• -1, -2 : son numéro dans la série

Ce n’est pas une obligation d’Ansible, c’est une pratique d’organisation qui permet, rien qu’en lisant ansible-inventory --list, de savoir à quoi sert chaque machine sans aller consulter une documentation à part. Sur un parc de cinquante serveurs, ce genre de convention fait gagner un temps précieux.

Détail 3 : un groupe qui vit hors de all

Regardez la fin du fichier : adguard_instances est déclaré au même niveau que all, pas à l’intérieur de all.children. C’est parfaitement valide en YAML pour Ansible : tout top-level key est traité comme un groupe. Ça permet de définir un groupe complètement séparé de la hiérarchie principale, pratique si doh1/doh2 n’ont pas vocation à hériter des variables définies sous all.vars.

Ce qu’il faut retenir

• Un hôte sans ansible_host n’est pas cassé : il s’appuie sur la résolution DNS du nom lui-même.
• Une convention de nommage cohérente dans l’inventaire vaut toutes les documentations séparées.
• Un groupe peut exister en dehors de all — utile pour des ensembles de machines complètement indépendants du reste de la flotte.

Dans la prochaine leçon, on aborde un piège fréquent chez les débutants : mettre trop de configuration directement dans l’inventaire, alors que certaines données n’ont rien à y faire.