Environment separation you can rely on · Ansible

There are two ways to keep a staging change away from production, and they are not equally strong.

The common one is to put both environments in one inventory, in groups called production and staging, and rely on everyone always targeting the right group. The other is to put them in separate inventory sources, so that when the staging run is loaded, production hosts do not exist.

The second one costs a directory. It is worth far more than it costs.

Excluded is not the same as absent

Under a single shared inventory, safety is a property of the command line. ansible-playbook site.yml --limit staging is safe; the same command with the limit forgotten is a fleet-wide production change. The inventory permitted both. Something outside the inventory — a habit, a wrapper script, a code review — was the only thing standing between them.

Under separate sources, safety is a property of the data. The staging inventory contains staging hosts. A production hostname typed into a staging run does not resolve, because it is not in the file that was loaded.

This distinction has a name in security engineering and it is worth importing: exclusion is a filter, absence is a boundary. Filters are applied by whoever remembers to apply them.

estate/
  ansible.cfg
  site.yml
  roles/                     # shared: the automation itself
  inventory/
    production/
      hosts.yml              # only production hosts
      group_vars/
    staging/
      hosts.yml              # only staging hosts
      group_vars/
    development/
      hosts.yml
      group_vars/

Roles and playbooks are shared, because the whole point of staging is to run the same automation against different machines. Inventory is not shared, because the whole point of an environment is that its machines are different machines.

What the boundary actually does

Load the staging inventory and ask for everything:

Read-only / Safeall means all of staging— With the staging source loaded, the pattern 'all' cannot reach beyond it.

$ ansible -i inventory/staging 'all' --list-hosts

  hosts (2):
  web-s1.example.com
  db-s1.example.com

Now try to reach a production host from that run — the mistake this design exists to stop:

Read-only / Safethe host is not there to be named— A production hostname passed to --limit against the staging inventory. The run refuses to start.

$ ansible -i inventory/staging 'all' --limit web-a1.example.com --list-hosts

[WARNING]: Could not match supplied host pattern, ignoring: web-a1.example.com
[ERROR]: Specified inventory, host pattern and/or --limit leaves us with no hosts to target.

Exit status 1, no tasks, nothing attempted. There is no version of that command that reaches production, because the name means nothing to the loaded inventory.

Two empty results, two different exit codes

This is a distinction worth memorising, because it decides whether an automated job notices its own mistake.

A pattern that matches nothing produces [WARNING]: No hosts matched, nothing to do, hosts (0):, and exit status 0. The run is considered successful.
A --limit that leaves nothing produces [ERROR]: Specified inventory, host pattern and/or --limit leaves us with no hosts to target. and exit status 1.

Both were checked on ansible-core 2.21.3. The practical consequence: a scheduled job whose pattern silently stopped matching looks green indefinitely, while a scheduled job whose limit stopped matching fails loudly. Where a job must affect hosts, prefer expressing the target as a --limit over burying it in the pattern, and assert on the host count regardless.

The honest comparison

Separate inventories are not free, and pretending otherwise makes the argument weaker than it is.

	Single inventory, environment groups	Separate inventory sources
Cost of a fleet-wide question	One command over everything	One command per environment, or an explicit merge
Group definitions	Written once	Written once per environment
Cross-environment reporting	Trivial	Requires passing `-i` twice on purpose
A forgotten `--limit`	Changes production	Changes only the loaded environment
A typo in an environment group name	Silently widens the target	Cannot widen past the file
Onboarding a new engineer	They must learn the discipline	The tool enforces it

The first three rows are real costs. Row four is why you pay them.

The duplication in row two is smaller than it looks, because what is duplicated is membership, which is genuinely different per environment, not behaviour, which lives in roles and is shared. If you find yourself copying the same group_vars content between environments, that content is not environment-specific and belongs in the role’s defaults/ instead.

Under the hood

-i does not name a file. It names an inventory source, and Ansible resolves it through the enabled inventory plugins. When the source is a directory, the directory is read recursively and every parseable file inside it becomes part of one merged inventory.

That recursion is the mechanism behind the layout above — pointing at inventory/production/ picks up hosts.yml and its neighbours without naming them — and it is also the way the boundary gets undone. Pointing one level higher merges everything below:

$ ansible -i inventory 'all' --list-hosts
  hosts (5):
    web-a1.example.com
    web-a2.example.com
    db-a1.example.com
    web-s1.example.com
    db-s1.example.com

Five hosts, three environments, one pattern. The directory structure did not protect anything; the -i argument did. Which is exactly why the next lesson in this part cares so much about where that argument is set.

The three ways separation gets undone

Every one of these has happened in real estates, and none of them announce themselves.

1. -i pointed at the parent directory. Shown above. Five hosts appear where two were expected. The tell is the host count in --list-hosts; if you never look at it, there is no tell.

2. A default inventory in ansible.cfg that spans environments. Setting inventory = inventory/ in the project config means every command that omits -i silently loads everything. The fix is to make the default either the safest environment or nothing at all, and to require -i for production. A default that includes production is a default that turns a forgotten flag into an incident.

3. A shared group_vars/all.yml outside the environment directories. Ansible looks for group_vars/ beside the inventory source and beside the playbook. A group_vars/all.yml sitting next to site.yml applies to every environment, so a variable that was meant to be a staging convenience — a shortened timeout, a relaxed check, a test endpoint — reaches production too. Keep group_vars/ inside the environment directory, and treat a playbook-adjacent group_vars/ as a finding in review.

What happens if you genuinely need both environments at once?

Occasionally you do: an inventory report, a certificate expiry sweep, a “which hosts are running the vulnerable package” question during an incident.

Do it explicitly and read-only:

ansible -i inventory/production -i inventory/staging all \
  -m ansible.builtin.setup -a 'filter=ansible_distribution*' --one-line

Two -i flags merge the sources into one inventory, and later sources override earlier ones where they overlap. That is fine for an inspection.

What it must not become is a habit, or a wrapper script, or a default in ansible.cfg. The moment “both environments” is the easy path, the boundary is decorative. If cross-environment reporting is a routine need, the right answer is a read-only reporting job with its own merged inventory and no ability to change anything — not a relaxation of the inventory used for changes.

The group named web that contains staging

Here is the failure this lesson prevents, in its most ordinary form.

Someone builds a single inventory with production and staging groups for environment, and web, database, cache for role. It is a correct orthogonal taxonomy. Then somebody writes a playbook that targets hosts: web, because the role group is the one that describes what the play does.

web contains staging hosts and production hosts. The play does not mention environment at all, so it changes both, and it will do so every time it runs, and the recap will say ok for all of them.

Nothing in the taxonomy is wrong. What is wrong is that role groups span environments by construction, so the environment boundary has to be enforced somewhere the play cannot forget. Separate inventory sources put it there. If you keep a single inventory instead, then every play must name the environment as well as the role — hosts: production:&web — and you have to be right about that on every play, forever.

Promotion works the same either way

A concern people raise about separate inventories is promotion: if the environments are separate, how do you know the staging test proves anything about production?

The answer is that promotion has never been about inventory. What gets promoted is the automation — the roles, the playbook, the pinned collection versions, the variable defaults — and that is shared already. The inventory is deliberately different, because staging hosts are deliberately different machines.

What you do owe is structural equivalence: if production has web, database and cache groups, staging should have all three, even if each holds one host. A staging environment missing a group is a staging environment that cannot exercise the play that targets it, and you will discover that during the production run.

Excluded is not the same as absent

What the boundary actually does

The honest comparison

The three ways separation gets undone

Promotion works the same either way

Knowledge check