unit 3 · Inventory

Dynamic inventory & plugins

Query the source of truth instead of maintaining a list

supplementary · 6 min · linux + windows

you may want to read 8 · Inventory: INI and YAML first — but nothing is locked

tl;dr

  • Dynamic inventory = a host list generated at run time by a plugin querying an API, not a static file.
  • Inventory plugins pull from cloud sources and CMDBs, and run on the control node like every plugin.
  • Static files suit estates you control by editing the file; dynamic suits estates whose truth lives elsewhere.

why it matters The moment your hosts churn faster than a file gets edited, a hand-maintained inventory starts rotting — and the hosts it silently misses are the ones that never get configured or patched.

Three lessons ago you wrote an inventory file by hand: hosts, groups, saved next to your playbooks, committed to Git. That model carries a hidden assumption — that you know what your hosts are, and that the list holds still long enough for a file to describe it. For a rack of on-prem servers it holds. For an estate where machines are created and destroyed by pipelines, autoscaling and other teams, it doesn’t — and no amount of discipline keeps the file honest.

dynamic inventory is Ansible’s answer: an inventory generated from a plugin or API at run time, not read from a static file. The generating side is an inventory plugin — inventory is one of the plugin types, so like every plugin it runs on the control node. Plugins exist for cloud sources and CMDBs. Instead of you telling Ansible what the estate looks like, the plugin asks the system that actually knows.

Static or dynamic is a question about the source of truth

Choose a static file when the file is the truth: you decide what belongs to the estate by editing it, a Git diff is your change review, and nothing adds hosts behind your back. That’s most on-prem fleets, and it’s why the static format came first in this course.

Reach for dynamic inventory when the truth lives somewhere else — a cloud control plane, a CMDB. Then a committed host file is just a cached copy of another system’s data, with no expiry date. The plugin turns inventory into a generated view of that system instead, correct at the moment each run starts.

What changes, and what doesn’t

Only the origin of the host list. Groups, group_vars/host_vars, patterns, --limit — everything from lessons 8–10 works the same on top of a generated inventory, and you can inspect the result the same way:

ansible-inventory --graph
Show the resolved inventory, whatever produced it

As for configuring one: setup is per-plugin, and the official docs’ inventory guide covers it plugin by plugin. This course deliberately stops at recognition — you’d pick that guide up on the day a team’s repo points you at a plugin instead of a hosts file.

You’ll also meet the idea wearing platform clothes: AWX and AAP offer inventory sync, refreshing their inventory from an external source on the controller’s side. Same concept, different trigger — lesson 39 puts those names in order. Until then, when someone says “dynamic inventory,” hear: we query the estate, we don’t maintain it.

at work, this sounds like

“We use dynamic inventory for that environment.”
The host list is generated from a plugin/API at run time, not maintained in a static file.
“The controller syncs inventory from the source.”
AWX/AAP refreshing its inventory from an external source — the same idea, run as a platform feature.

self-check — recall, not a test

  1. 1 A colleague says the cloud estate uses dynamic inventory. What exactly is different from what you built in lesson 8?

  2. 2 When does a static inventory file stop being the right tool?

  3. 3 Does going dynamic change how groups, group_vars or patterns work?

PLAY RECAP ************************** 11-dynamic-inventory : ok=1 next=12-playbook-anatomy read=7m