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 :

- name: Configurer les serveurs web
  hosts: webservers
  tasks:
    - name: Configurer nginx
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        mode: "0644"
      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.

Plugin et fichier .yml

Pour qu'Ansible reconnaisse un fichier comme plugin d'inventaire, il doit contenir une ligne plugin: <nom> au top niveau. Sinon il est traité comme un inventaire statique. Voir la page Plugin libvirt KVM.

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

Trois de ces symptômes viennent de l'ordre ou de l'emplacement des sources, deux points qu'on croit accessoires jusqu'à ce qu'une variable de recette parte en production. Les deux derniers concernent la cohabitation elle-même, un plugin non activé et un hôte déclaré dans deux sources, dont le conflit reste silencieux tant que les valeurs concordent.

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

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À 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.

Pour aller plus loin

• Vérifier l'inventaire : contrôler ce que la fusion de plusieurs sources a réellement produit.
• Inventaires dynamiques : la moitié cloud du mélange statique plus dynamique évoqué ici.
• Plugin AWS EC2 : le cas concret d'un inventaire cloud combiné à vos fichiers on-premise.

×

📖 Voir la documentation →