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 because of the inventory — the file
that names every machine you manage and sorts them into
group s. There is no agent to install and no registration
handshake: a host becomes a managed node the moment your
inventory names it and Ansible can log in. One file is the entire membership
list of your estate.
It comes in two formats, INI and YAML. Here is the same small inventory in
both — three hosts, a web group, a db group, and a parent group 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. all you get for free — the
built-in group holding every host in the file, which is 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; be fluent reading both, because older
repos lean INI while 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 (with -i <file> to point at 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 belonging to no group of
yours. Both files render identically because format is spelling — the graph
is the meaning. The command sits in the everyday debugging toolkit next to
-vvv, and it 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 of this file are deliberately not here: variables
attached to 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 start earning their keep
as 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.