Ansible Inventory & Dynamic Inventory: — Host Lists That Never Go Stale

① Static inventory — the INI/YAML host list, groups, children & ranges

Start where everyone starts. Inventory is just Ansible's answer to one question: which machines do I manage, and how do I reach each one? The simplest answer is a static inventory — a text file you write by hand. Rahul, an L1 engineer at Infosys, manages 12 access switches and 6 servers in one branch, so a static file is perfect for him. The host list rarely changes, and he can read the whole thing at a glance.

There are two formats, and both are first-class. INI is the classic — flat, fast to read, great for a small estate. YAML is the structured one — it handles nested groups and typed variables (lists, dicts, booleans) far more cleanly. Same inventory, two spellings:

# hosts.ini
[webservers]
web1.infosys.local
web2.infosys.local

[dbservers]
db1.infosys.local

# nested group: a group OF groups, via :children
[branch_pune:children]
webservers
dbservers

# group variables
[webservers:vars]
ansible_user=svc_ansible

$ ansible-inventory -i hosts.ini --list --yaml | head
all:
  children:
    branch_pune:
      children:
        webservers: {hosts: {web1.infosys.local: ..., web2.infosys.local: ...}}
        dbservers: {hosts: {db1.infosys.local: ...}}

# hosts.yml
all:
  children:
    branch_pune:
      children:
        webservers:
          hosts:
            web1.infosys.local:
            web2.infosys.local:
          vars:
            ansible_user: svc_ansible
        dbservers:
          hosts:
            db1.infosys.local:

$ ansible-inventory -i hosts.yml --graph
@all:
  |--@branch_pune:
  |  |--@webservers:
  |  |  |--web1.infosys.local
  |  |  |--web2.infosys.local
  |  |--@dbservers:
  |  |  |--db1.infosys.local

Two groups exist automatically, in every inventory, whether you write them or not: all (every host) and ungrouped (hosts you didn't put in any group). That's why ansible-inventory --graph always starts at @all. Notice the children idea above — branch_pune contains no hosts directly, only the webservers and dbservers groups. Nested groups let you say "all of Pune" in one word.

Now the trick that saves your fingers. When hosts follow a pattern — sw01 through sw12, or www01 through www50 — you don't list them one by one. You use a host range. The brackets hold start:end, and you can add a stride and even letters:

[switches]
sw[01:12].infosys.local        # sw01 .. sw12  (12 hosts, zero-padded)

[webfarm]
www[01:50:2].example.com       # www01, www03, www05 ... (stride = 2)

[shards]
db-[a:f].infosys.local         # db-a, db-b ... db-f  (alphabetic)

$ ansible switches -i hosts.ini --list-hosts
  hosts (12):
    sw01.infosys.local
    sw02.infosys.local
    ... (sw03 .. sw11) ...
    sw12.infosys.local

Where do the connection details go? Not jammed into the inventory file as a wall of inline vars — that gets unreadable fast. The tidy place is two directories beside your inventory: group_vars/ and host_vars/. A file named after a group applies to every host in it; a file named after a host applies only to that host. This is exactly where ansible_host, ansible_user and (for network gear) ansible_network_os belong.

# group_vars/switches.yml  (applies to every host in @switches)
ansible_network_os: cisco.ios.ios   # tells network modules: this is IOS
ansible_user: svc_netauto
ansible_connection: network_cli

# host_vars/sw01.infosys.local.yml  (just this one box)
# ansible_host: 10.20.10.1          # the real IP to connect to

$ ansible-inventory -i hosts.ini --host sw01.infosys.local
{
  "ansible_connection": "network_cli",
  "ansible_host": "10.20.10.1",
  "ansible_network_os": "cisco.ios.ios",
  "ansible_user": "svc_netauto"
}

② Why static goes stale — and what a dynamic inventory does instead

A static file is honest exactly once: the moment you save it. After that, reality drifts. Priya, an L2 engineer at Flipkart, owns an Auto Scaling group that adds EC2 instances when traffic spikes for a sale and kills them when it dies down. By the time she finishes editing hosts.ini, the IDs in it are already wrong — new instances launched, old ones terminated. Her playbook then configures ghost hosts and skips the real ones.

This isn't only cloud. A network team's switch fleet changes as sites open, gear gets RMA'd, and labs spin up and down. The source of truth for "which hosts exist right now" lives in AWS, Azure, GCP or NetBox — never in a text file a human edits. A static inventory is a photocopy of that truth, and photocopies go out of date.

A dynamic inventory flips the model. Instead of reading a frozen file, Ansible runs a plugin that asks the source of truth — the AWS API, the Azure API, the NetBox API, DNS — "what hosts exist right now?" every single run. The list is generated fresh each time, so there is nothing to keep editing and nothing to go stale. Priya deletes her cron-job-to-edit-the-file and points Ansible at an aws_ec2.yml config instead.

③ Dynamic inventory plugins — the modern way (aws_ec2, azure_rm, nb_inventory)

There are two ways to do dynamic inventory, and only one is current. The legacy way was an inventory script — you ran a Python file that spat out JSON. The modern way is an inventory plugin, configured by a tiny YAML file. Plugins win because they ship inside collections, are maintained for you, and hand you grouping and caching features out of the box. RHCE and every current guide teach plugins; treat scripts as legacy you only meet in old repos.

The plugin you reach for depends on your source of truth. The four you'll meet most:

The four dynamic inventory plugins you'll actually use

Tap each — same idea (query the live source), different source of truth. The string after the dots is the fully-qualified plugin name you put in your config.

A plugin config is short. You name the plugin, say where to look, and then — the powerful part — tell it how to auto-build groups. Two features do the heavy lifting. keyed_groups turns a tag into groups: feed it the role tag and it makes role_web, role_db, one per value. compose sets host variables with a Jinja2 expression — most famously ansible_host.

# File MUST end in aws_ec2.yml (or .yaml) or the plugin ignores it
plugin: amazon.aws.aws_ec2
regions:
  - ap-south-1                      # Mumbai
filters:
  instance-state-name: running     # ignore stopped/terminated
keyed_groups:
  - key: tags.role                  # tag:role  ->  role_web, role_db ...
    prefix: role
  - key: placement.availability_zone
    prefix: az
compose:
  ansible_host: {{ public_ip_address | default(private_ip_address) }}
groups:
  prod: "tags.env == 'prod'"        # custom group from a Jinja2 test

$ ansible-inventory -i prod.aws_ec2.yml --graph
@all:
  |--@aws_ec2:
  |  |--i-0a1b2c3d (10.0.12.7)
  |--@role_web:
  |  |--i-0a1b2c3d (10.0.12.7)
  |--@az_ap_south_1a:
  |--@prod:

For network teams the same idea points at NetBox instead of a cloud. The nb_inventory plugin reads your NetBox API and groups devices by the role/site/tag fields you already maintain there — so the inventory mirrors your DCIM exactly, with no second list to keep in sync.

# File ends in nb_inventory.yml (e.g. dc.nb_inventory.yml)
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.infosys.local
token: "{{ lookup('env', 'NETBOX_TOKEN') }}"   # never hardcode the token
group_by:
  - device_roles                  # -> groups like device_roles_edge_router
  - sites                         # -> groups like sites_mumbai_dc
device_query_filters:
  - has_primary_ip: 'true'        # skip patch panels / passive gear
compose:
  ansible_network_os: platform.slug

$ ansible-inventory -i dc.nb_inventory.yml --graph
@all:
  |--@device_roles_edge_router:
  |  |--mum-edge-01
  |  |--mum-edge-02
  |--@sites_mumbai_dc:
  |  |--mum-edge-01
  |  |--mum-core-01

④ A real setup — auto-group, cache, verify with --graph, and the gotchas

Let's wire a believable production setup, the way an L2 at Airtel would. Source of truth: NetBox for the network gear, AWS for the cloud edge. Goal: zero hand-maintained host lists, groups that build themselves from role/site/tag, and a fast feedback loop. Three moving parts: the plugin configs (done in section ③), caching so you don't hammer the API, and ansible-inventory to verify.

First, point Ansible at a directory of inventory configs and turn on caching. A directory lets static and dynamic sources coexist — your fixed jump-hosts in a YAML file, your cloud and NetBox via plugins, all merged into one inventory.

[defaults]
inventory = ./inventory          # a directory: mixes static + dynamic

[inventory]
# keep the DEFAULTS or your static files stop parsing:
enable_plugins = host_list, script, auto, yaml, ini, toml, amazon.aws.aws_ec2, netbox.netbox.nb_inventory
cache = true
cache_plugin = ansible.builtin.jsonfile
cache_connection = /tmp/ansible_inv_cache
cache_timeout = 3600             # seconds; re-query the source after 1h

$ ansible-inventory --graph | head -1
@all:
# cache cold -> hits AWS+NetBox; warm runs read /tmp/ansible_inv_cache (fast)

Now verify — this is the command you run a hundred times a week. ansible-inventory --graph draws the tree (groups, children, hosts); --list dumps the full JSON with every variable; --host NAME shows one host's resolved vars. If the source changed and you cached, --flush-cache forces a fresh pull.

ram@netauto:~$ ansible-inventory --graph
ram@netauto:~$ ansible-inventory --graph --flush-cache   # ignore cache, re-query
ram@netauto:~$ ansible-inventory --host mum-edge-01       # one host's vars

@all:
  |--@aws_ec2:
  |  |--i-0a1b2c3d
  |--@role_web:
  |  |--i-0a1b2c3d
  |--@device_roles_edge_router:
  |  |--mum-edge-01
  |  |--mum-edge-02
  |--@sites_mumbai_dc:
  |  |--mum-edge-01
  |--@ungrouped:

Once the inventory is correct, you target the right slice with the pattern language. This is where union :, intersection & and exclusion ! earn their keep — and the order matters: Ansible processes : first, then &, then !.

# union: web OR db
ansible 'webservers:dbservers' --list-hosts

# intersection: hosts in BOTH webservers AND prod
ansible 'webservers:&prod' --list-hosts

# exclusion: all prod EXCEPT the mumbai site
ansible-playbook patch.yml --limit 'prod:!sites_mumbai_dc'

# 'webservers:&prod'  ->
  hosts (2):
    i-0a1b2c3d
    i-0e9f8a7b
# only the web boxes that are also tagged env=prod

One current, real-world note for 2025-2026. From ansible-core 2.19 the templating trust model was inverted (the "Data Tagging" change). Variables that come from inventory plugins and other external sources are no longer trusted as Jinja2 templates by default — a value pulled from a tag or a NetBox field that happens to contain {{ ... }} is treated as a literal string unless explicitly trusted. The takeaway for you as an inventory author: your compose/keyed_groups expressions still work, but you can't rely on attacker-controllable external data being re-templated — which is exactly the security behaviour you want.