Patterns, --limit & per-env inventories

Lesson 8 gave you an inventory full of groups. Every command since has opened with a target — web, all. Those are the simplest cases of a pattern , the expression deciding which inventory hosts a run touches. Nothing executes until a pattern says where.

Four forms cover most cases:

ansible all -m ansible.builtin.ping             # every host in the inventory
ansible 'web*' -m ansible.builtin.ping          # wildcard: web01, web02, webcache...
ansible 'web:&staging' -m ansible.builtin.ping  # in web AND in staging
ansible 'web:!db' -m ansible.builtin.ping       # in web but NOT in db

Read the last two as set operations on groups. web:&staging is an intersection — hosts in both groups. web:!db is an exclusion — web minus the db members. The quotes are for your shell, not Ansible: ! and & mean things to bash. And a bare : between two group names is a union — web:db is everything in either group.

--limit: narrow the run you already wrote

--limit is a run-control flag: it narrows any run to the hosts you name, without editing a thing. When you reach playbooks in unit 4, each play declares its own targets — --limit cuts below that declaration.

# the full run, as the play targets it
ansible-playbook site.yml -i inventories/staging/
# identical run, narrowed to the one host that failed
ansible-playbook site.yml -i inventories/staging/ --limit web01

That second line is why --limit sits in the debugging toolkit next to -vvv and --check. One host broke mid-run? Fix the cause, re-run against just that host — not the whole fleet.

One inventory directory per environment

This habit matters more than any pattern syntax: a separate inventory directory per environment, each with its own group_vars and host_vars :

inventories/
  production/
    hosts.yml        # prod hosts and groups
    group_vars/      # prod values live with prod
    host_vars/
  staging/
    hosts.yml        # same group names, different machines
    group_vars/
    host_vars/

You choose the environment when you type -i inventories/production/. That’s the mechanism behind the standup phrase “run the playbook against prod” — same playbook, prod inventory. Keep group_vars/all.yml minimal. Anything environment-specific belongs in that environment’s directory, not in a shared file both environments read.

Before trusting any inventory, look at what it contains: ansible-inventory --graph -i inventories/staging/ prints the group tree Ansible resolved. Make that your reflex before the first run against any inventory you didn’t write. Same cheapest-fact-first instinct as the ping in lesson 7, one level up.