Inventaires multiples Ansible : combiner dev, staging et prod

Un seul inventaire ne suffit plus dès qu’on a plusieurs environnements (dev, staging, prod) ou plusieurs sources (statique pour le control node + dynamique pour les VMs cloud). Ansible permet de combiner plusieurs inventaires avec -i inv1 -i inv2 ou un dossier d’inventaires.

Cette page explique les deux stratégies principales (multi -i vs dossier), comment Ansible fusionne les variables, et le pattern recommandé pour séparer dev / staging / prod sans dupliquer les playbooks.

Ce que vous allez apprendre

Combiner 2+ fichiers d’inventaire en CLI avec -i inv1 -i inv2.
Utiliser un dossier d’inventaires comme source unique.
Comprendre l’ordre de fusion des variables.
Structurer un projet dev/staging/prod sans dupliquer les playbooks.
Mélanger un inventaire statique et un dynamique dans le même run.

Méthode 1 — Plusieurs `-i` en CLI

Chaque -i ajoute une source d’inventaire. Ansible les fusionne dans l’ordre :

ansible-playbook -i inventory/static.yml -i inventory/cloud.aws.yml site.yml

Cas d’usage typique : un fichier statique pour le control node + un script ou plugin dynamique pour les machines cloud.

Ordre de fusion : le dernier -i gagne sur les précédents en cas de conflit de variables. Pratique : on met le statique en premier (valeurs par défaut) et le dynamique en second (override depuis le cloud réel).

Méthode 2 — Dossier d’inventaires

Au lieu de lister tous les fichiers en CLI, pointer vers un dossier :

ansible-playbook -i inventory/ site.yml

Avec :

inventory/
├── 01-static.yml
├── 02-libvirt.yml
└── 03-aws.aws_ec2.yml

Ansible lit tous les fichiers du dossier dans l’ordre alphabétique et les fusionne. Convention : préfixer par un numéro (01-, 02-) pour contrôler l’ordre.

Mêmes règles de fusion que pour les -i multiples : le dernier alphabétiquement gagne. group_vars/ et host_vars/ sont chargés depuis ce même dossier.

Pattern recommandé — séparation dev/staging/prod

Le pattern standard 2026 : un dossier par environnement, chacun avec son inventaire et ses variables.

ma_formation/
├── ansible.cfg
├── playbooks/
│   └── deploy.yml
├── inventories/
│   ├── dev/
│   │   ├── hosts.yml
│   │   ├── group_vars/
│   │   │   └── all.yml          ← env: dev, log_level: debug
│   │   └── host_vars/
│   ├── staging/
│   │   ├── hosts.yml
│   │   ├── group_vars/
│   │   │   └── all.yml          ← env: staging, log_level: info
│   │   └── host_vars/
│   └── prod/
│       ├── hosts.yml
│       ├── group_vars/
│       │   ├── all.yml          ← env: prod, log_level: warning
│       │   └── vault.yml        ← secrets chiffrés
│       └── host_vars/
└── roles/

Le playbook reste générique :

- hosts: webservers
  tasks:
    - name: Configurer nginx
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      vars:
        log_level: "{{ log_level }}"  # vient de group_vars/all.yml

L’exécution choisit l’environnement cible :

ansible-playbook -i inventories/dev/      playbooks/deploy.yml   # → dev
ansible-playbook -i inventories/prod/     playbooks/deploy.yml   # → prod

Aucune modification du playbook entre dev et prod — tout passe par les variables d’environnement. C’est exactement ce qu’on veut.

Ordre de fusion — règles précises

Quand une même variable est définie dans 2 inventaires, le dernier l’emporte. Mais avec une nuance importante : la précédence officielle Ansible s’applique d’abord dans chaque inventaire, puis entre inventaires.

ansible-playbook \
  -i inventories/static.yml \
  -i inventories/dynamic.yml \
  -i inventories/overrides.yml \
  site.yml

Si app_port est défini dans :

static.yml → 80
dynamic.yml → 8080
overrides.yml → 9090

Le résultat final est 9090 (dernier -i). Mais si static.yml définit dans host_vars/web1.yml et dynamic.yml dans group_vars/all.yml, alors host_vars reste prioritaire dans son inventaire — sauf si dynamic.yml redéfinit aussi dans host_vars/web1.yml.

Règle pratique : ne pas mélanger les niveaux de précédence entre inventaires. Sinon le résultat devient vite imprévisible.

Inventaire statique + dynamique

Un cas réel courant : déployer du code sur des VMs provisionnées par Terraform (visibles via un plugin libvirt) + des serveurs on-premise statiques.

inventories/
├── static-onprem.yml       ← inventaire YAML classique
└── kvm-libvirt.yml         ← plugin community.libvirt.libvirt

ansible-playbook -i inventories/ site.yml

Ansible voit l’union des hôtes des deux sources. Pratique pour migrer progressivement on-prem → cloud sans casser l’existant.

Configurer un dossier d’inventaire par défaut

Dans ansible.cfg, on peut figer l’inventaire par défaut :

[defaults]
inventory = ./inventories/dev

Toutes les commandes utilisent inventories/dev sauf si vous override avec -i. Pratique pour le développement — un développeur n’a pas à taper -i inventories/dev/ à chaque fois.

Variables d’environnement équivalente : ANSIBLE_INVENTORY=./inventories/dev.

Pièges courants

Symptôme	Cause	Fix
Variables d’un inventaire ignorées	Ordre des `-i` non maîtrisé (le dernier gagne)	Ordonner explicitement : statique en 1er, dynamique en 2nd
`inventories/dev` vu comme un fichier	Ansible cherche un dossier ou un fichier	Vérifier que `inventories/dev/` existe et contient `hosts.yml`
`group_vars/` non chargé	Placé à côté du playbook au lieu de l’inventaire	Bouger dans `inventories/dev/group_vars/`
Plugin dynamique invisible	`enable_plugins` non configuré	`[inventory] enable_plugins = community.libvirt.libvirt, ...`
Hôtes dupliqués	Même hôte défini dans 2 inventaires différents	Pas grave si les variables matchent ; sinon conflit silencieux

À retenir

-i inv1 -i inv2 : combine plusieurs inventaires, le dernier gagne sur conflit de variables.
Dossier d’inventaires : Ansible lit tous les fichiers en ordre alphabétique — préférer cette méthode.
Pattern dev/staging/prod : un dossier par environnement avec ses propres group_vars/ et host_vars/.
Le playbook reste générique, seul l’inventaire change entre environnements.
Mélanger statique et dynamique est légitime et fréquent (on-prem + cloud).
ansible.cfg peut figer un inventaire par défaut pour le développement.

Prochaines étapes

Inventaire dynamique pour KVM Quand le statique ne suffit plus — découvrir automatiquement les VMs libvirt

Patterns d'hôtes Cibler un sous-ensemble : --limit dev:webservers ou --limit prod:!web1

group_vars et host_vars Bien structurer les variables dans chaque inventaire d'environnement

Vérifier un inventaire ansible-inventory -i inventories/ --graph pour valider la fusion