unit 3 · Inventory
Inventory: INI and YAML
Same hosts, two spellings
you may want to read 7 · Your first ad-hoc command first — but nothing is locked
tl;dr
- The inventory is the file naming every host Ansible manages, sorted into named groups.
- Two formats — INI and YAML — describe the same thing; parent groups nest via children.
- ansible-inventory --graph shows what Ansible actually parsed. Trust the graph, not the file.
why it matters Every ad-hoc command and playbook targets inventory groups — get this file wrong and you configure the wrong machines, or none, before a single task runs.
Lesson 7’s anatomy had a word you were told to park: web, the target.
Ansible resolved it from the inventory — the file that
names every machine you manage and sorts them into group s.
No agent, no registration handshake: a host becomes a
managed node the moment your inventory names it and
Ansible can log in.
Inventory comes in two formats, INI and YAML. Here is the same one in both:
three hosts, a web group, a db group, and a parent holding them.
The INI spelling
[web]
web01.example.com
web02.example.com
[db]
db01.example.com
# ":children" — this group's members are GROUPS, not hosts
[myapp:children]
web
dbA [header] names a group; the lines under it are its hosts. The third block
is the nesting move: [myapp:children] declares a parent group whose
members are other groups. Target myapp and you hit everything in web
and db; target web, just the two web boxes. You get all for free —
the built-in group holding every host in the file. That’s what ansible all
targeted in lesson 7.
The YAML spelling
all:
children:
myapp:
children:
web:
hosts:
web01.example.com: # trailing colon — hosts are keys, not list items
web02.example.com:
db:
hosts:
db01.example.com:Same groups, same nesting. children: is the YAML spelling of :children,
and hosts sit under a hosts: key as mapping keys — hence the trailing
colons. Both formats are first-class. Read both fluently: older repos lean
INI; the standard repo layout in lesson 36 carries a YAML hosts.yml.
Ask Ansible what it parsed
Never trust your own reading of an inventory file — ask the tool. Run
ansible-inventory --graph (add -i <file> for a specific file) and you
get the parsed tree:
@all:
|--@ungrouped:
|--@myapp:
| |--@web:
| | |--web01.example.com
| | |--web02.example.com
| |--@db:
| | |--db01.example.com@ marks a group; @ungrouped collects hosts in none of your groups. Both
files render identically because format is spelling — the graph is the
meaning. It sits in the debugging toolkit next to -vvv. It also
closes lesson 6’s loop: the inventory = inventories/dev/ line in
ansible.cfg is this file’s address, so no command needs -i.
Three neighbours are deliberately not here: variables for groups and
hosts (group_vars/host_vars, lesson 9); patterns, --limit and
per-environment inventory directories (lesson 10); and inventories
generated from cloud APIs (dynamic inventory, lesson 11). For now the
static file is plenty. Next lesson, groups become the place per-environment
configuration lives.
at work, this sounds like
- “Run it against prod.”
- Execute the playbook with the inventory that names the prod hosts — different inventory, same playbook.
self-check — recall, not a test
1 What makes a machine a managed node, as far as Ansible is concerned?
2 In an INI inventory, what does [myapp:children] mean — and how does YAML spell the same thing?
3 You just edited an inventory file. What one command do you run before trusting it, and why?
lab (optional — never required)
Write an INI inventory putting localhost in a web and a db group under one parent via :children, then run ansible-inventory --graph -i <file> and confirm the nesting matches your intent.
needs: The control node from lesson 5.