Patterns d'hôtes Ansible : --limit, opérateurs (:, &, !), wildcards

--limit et les patterns d'hôtes permettent de cibler précisément les hôtes voulus sans toucher au playbook. C'est l'outil clé pour des opérations chirurgicales : déployer sur un seul host, tester en staging avant prod, exclure une machine en maintenance. Maîtriser cette syntaxe est mandatory au RHCE, vous y serez confronté à chaque exercice.

Quatre opérateurs couvrent 95 % des cas : : (union), :& (intersection), :! (exclusion), * (wildcard).

Ce que vous allez apprendre

• Lister les hôtes ciblés par un pattern via --list-hosts sans rien exécuter.
• Combiner union, intersection, exclusion dans un même pattern.
• Utiliser des wildcards et des ranges (web[01:05]).
• Appliquer --limit sur un playbook pour réduire la portée.
• Comprendre l'ordre d'évaluation des opérateurs.

Prérequis

• Inventaire fonctionnel (statique ou dynamique).
• Connaître la commande ansible-inventory --graph.

Le tableau de référence

Opérateur	Effet	Exemple	Résultat (avec inventaire du lab inventaires/patterns-hotes)
:	Union (OU logique)	webservers:dbservers	web1, web2, db1
:&	Intersection (ET logique)	webservers:&staging	web1 uniquement
:!	Exclusion	webservers:!web1.lab	web2 uniquement
*	Wildcard	web*.lab	web1.lab, web2.lab
[a:c]	Range	web[01:05].lab	web01.lab à web05.lab
~regex	Regex (rare)	~web[1-3]\.lab	web1, web2, web3

Glissez pour voir

Important : entourer toujours le pattern de quotes simples en CLI : --limit 'webservers:&staging'. Sans quotes, le shell interprète : ou & et casse la commande.

--list-hosts, tester sans exécuter

Avant de lancer un playbook avec un pattern complexe, valider la sélection :

ansible 'webservers:&staging' -i inventory/hosts.yml --list-hosts

Sortie :

  hosts (1):
    web1.lab

--list-hosts est l'équivalent du --check pour les patterns : aucune action, juste la résolution. Mandatory avant un playbook destructif (purge, reboot, drop).

Union avec :

Combiner plusieurs groupes ou hôtes :

ansible 'webservers:dbservers' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab, web2.lab, db1.lab, l'union de tous les hôtes des deux groupes.

ansible 'webservers:db1.lab' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab, web2.lab, db1.lab, un groupe + un host individuel. Le pattern accepte indifféremment des noms de groupes ou des hostnames.

Intersection avec :&

Les hôtes présents dans les deux groupes simultanément :

ansible 'webservers:&staging' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab uniquement, il est dans webservers ET dans staging. web2.lab est dans webservers mais pas dans staging → exclu.

Cas d'usage typique : déployer un patch uniquement sur les machines qui sont à la fois webservers ET en staging, ne pas toucher au prod, ne pas toucher aux dbservers.

Exclusion avec :!

Retirer des hôtes d'un groupe :

ansible 'webservers:!web1.lab' -i inventory/hosts.yml --list-hosts

Sortie : web2.lab uniquement.

ansible 'all:!dbservers' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab, web2.lab, tous sauf ceux dans dbservers.

Cas d'usage typique : machine en maintenance, --limit 'webservers:!web1.lab' pour déployer partout sauf elle.

Wildcards

ansible 'web*.lab' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab, web2.lab, tout ce qui commence par web.

ansible '*1.lab' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab, db1.lab, tout ce qui finit par 1.lab.

Limites : le wildcard ne matche que sur les hostnames, pas sur les noms de groupes. Pour des matchs de groupes, préférer la regex (~) ou définir un méta-groupe.

Combinaisons complexes

Les opérateurs s'évaluent de gauche à droite :

ansible 'prod:!monitoring' -i inventory/hosts.yml --list-hosts

Sortie : web1.lab, web2.lab, tous les hôtes de prod sauf ceux dans monitoring (db1).

ansible 'webservers:dbservers:!staging' -i inventory/hosts.yml --list-hosts

Sortie : web2.lab, db1.lab, union de webservers et dbservers, moins ceux dans staging (web1).

ansible 'all:&prod:!web1.lab' -i inventory/hosts.yml --list-hosts

Évaluation pas-à-pas :

1. all → web1, web2, db1.
2. &prod → intersection avec prod → web1, web2, db1 (tous y sont).
3. !web1.lab → retirer web1 → web2, db1.

Règle d'or : pour des patterns à 3+ opérateurs, valider avec --list-hosts avant le run réel.

--limit sur un playbook

Le pattern peut s'appliquer à un playbook qui cible hosts: all :

ansible-playbook -i inventory/hosts.yml site.yml --limit 'webservers:!web1.lab'

Le playbook tourne uniquement sur web2.lab, --limit filtre par-dessus le hosts: du playbook. L'inverse n'est pas vrai : --limit ne peut pas élargir le hosts: d'origine, seulement le restreindre.

# hosts: webservers dans le playbook, --limit 'all'
# → cible quand même webservers (limit ne peut pas élargir)

Ranges, séquences d'hôtes

Quand vous avez 50 webservers nommés web01 à web50 :

ansible 'web[01:10].lab' -i inventory/hosts.yml --list-hosts

Sortie : web01.lab à web10.lab. Le séparateur est : (pas - comme dans certaines convention).

ansible 'web[01:50]:!web[10:20].lab' -i inventory/hosts.yml --list-hosts

Tous les webservers sauf web10 à web20. Combinaison range + exclusion.

Patterns avec inventaire dynamique

Avec un plugin libvirt ou AWS, les groupes sont générés dynamiquement depuis les tags ou les attributs des VMs :

# Plugin AWS retourne des groupes par tag
ansible 'tag_Environment_prod:&tag_Role_web' -i aws_inventory.yml --list-hosts

Cible toutes les VMs AWS qui ont à la fois Environment=prod ET Role=web. Le pattern syntaxique reste identique au statique, c'est juste la source des groupes qui change.

Pièges courants

Les deux premiers symptômes n'ont rien à voir avec Ansible : c'est le shell qui interprète les deux-points et l'esperluette avant même que la commande parte, d'où les guillemets simples systématiques. Les trois suivants tiennent au motif lui-même, groupe mal orthographié, portée que l'option de limite ne peut pas élargir, ou intervalle écrit avec un tiret au lieu du séparateur attendu.

Symptôme	Cause	Fix
: interprété par le shell	Pas de quotes autour du pattern	Toujours --limit '...'
&staging lance le shell en arrière-plan	& interprété par bash	Quotes simples obligatoires
Pattern matche 0 host	Faute de frappe ou groupe inexistant	--list-hosts puis --graph
--limit n'agit pas	Ne peut élargir un hosts: du playbook	Modifier hosts: all dans le playbook
Range web[1-5] ne marche pas	Tirets - au lieu de deux-points :	web[01:05] (avec :)
Wildcard sur nom de groupe	* matche seulement les hostnames	Définir un méta-groupe explicitement

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

• : = union, :& = intersection, :! = exclusion, * = wildcard.
• Quotes simples obligatoires en CLI : --limit '...'.
• --list-hosts valide la sélection sans exécuter, mandatory avant un run risqué.
• Évaluation gauche-à-droite des opérateurs.
• --limit peut restreindre le hosts: du playbook, pas l'élargir.
• Ranges : web[01:10] (séparateur :).
• Sur inventaire dynamique : la syntaxe reste identique, seuls les groupes diffèrent.

Mettre en pratique

Les opérateurs ne se distinguent vraiment que sur un inventaire où un même hôte appartient à plusieurs groupes. Ce lab vous donne cette configuration, puis vous demande de viser une sélection précise avec --limit et les opérateurs d'union, d'intersection et d'exclusion, sans jamais modifier le playbook. Chaque tentative se contrôle avec --list-hosts avant de compter comme bonne.

Lab pratique

Patterns d'hôtes : wildcards et opérateurs :, &, !

$ dsoxlab run inventaires-patterns-hotes

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run inventaires-patterns-hotes
dsoxlab check inventaires-patterns-hotes

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• Inventaires dynamiques : les mêmes opérateurs s'appliquent aux groupes découverts automatiquement.
• Plugin libvirt (KVM) : un inventaire généré sur lequel rejouer vos patterns sans rien écrire à la main.
• Modules runtime (add_host, group_by) : créer pendant l'exécution les groupes que vos patterns viseront ensuite.

×

📖 Voir la documentation →