Inventory, playbook, module: the Ansible trinity
Summary: these three words come up constantly in any discussion about Ansible, and 8 out of 10 beginners confuse them. This lesson distinguishes them once and for all with the analogy of an orchestra conductor, then shows a real YAML file to anchor the concepts.
1. The symphony orchestra analogy
Imagine a conductor directing a symphony. This scene involves three distinct elements:
The mapping with Ansible:
| Orchestra element | Ansible equivalent |
|---|---|
| The score (what the orchestra must play) | Playbook — the YAML file describing the tasks to do |
| The list of musicians and desks | Inventory — the file listing the servers and their groups |
| Each specialized instrument | Module — each building block that knows how to do one precise action (install a package, copy a file…) |
There is a fourth concept we will see a bit further on: the role, which is a shareable and reusable score.
2. The inventory — the address book of your servers
The inventory is the first file you write when starting with Ansible. It lists all the machines that Ansible will be able to drive, and groups them logically.
Inventory example (in .ini format, the historical and most readable format):
[web]
web1.example.com
web2.example.com
web3.example.com
[db]
db1.example.com
db2.example.com
[cache]
redis1.example.com
[production:children]
web
db
cache
Decoding:
[web],[db],[cache]are groups.- Each line under a group is a server (host).
[production:children]is a group of groups — saying "production" designates all the web, db and cache servers.
What it enables:
Bonus: in the modern cloud world, the inventory can be dynamic — built automatically from AWS, GCP, Azure. Ansible queries the cloud, obtains the list of active machines, and updates the inventory by itself.
3. The playbook — the musical score
A playbook is a YAML file describing a series of tasks to execute on the servers of one or several inventory groups.
Here is what a real playbook looks like (do not try to memorize it, we just want to see the shape):
- name: Web server configuration
hosts: web
become: true
tasks:
- name: Install Nginx
apt:
name: nginx
state: present
update_cache: true
- name: Copy the Nginx configuration
copy:
src: files/nginx.conf
dest: /etc/nginx/nginx.conf
mode: '0644'
- name: Start and enable Nginx
service:
name: nginx
state: started
enabled: true
Key-by-key decoding:
| YAML line | What it tells Ansible |
|---|---|
name: Web server configuration | Human title of this play |
hosts: web | Targets the web group of the inventory |
become: true | Elevates privileges (equivalent of sudo) |
tasks: | List of tasks to execute in order |
apt: name: nginx | Uses the apt module to install nginx |
copy: src: ... dest: ... | Uses the copy module to send a file |
service: state: started | Uses the service module to start nginx |
This file is your single source of truth: every person who runs this playbook on the web group gets exactly the same result. End of configuration drift.
4. The modules — the specialized building blocks
An Ansible module is a small building block of Python code that knows how to perform one precise action on a target server. It is Ansible's unit of work.
There are more than 3000 of them in the Ansible world in 2026, spread across major families:
What makes modules powerful:
- They are written in Python but transparent to the user — you write YAML, Ansible transmits and executes the Python on the server side.
- They are idempotent: running
apt: name=nginx state=presenttwice does not reinstall nginx if already installed. - They report their result:
changed(something was modified),ok(already in the expected state),failed(error).
You can also write your own modules in Python. But 99% of real needs are already covered by the existing modules.
5. The role — the shareable score
An Ansible role is a structured set of playbooks, variables, files and templates, packaged to be reusable and shareable.
Major benefit: instead of rewriting "install and configure nginx" every time, you download a community role that already does everything, correctly, tested by thousands of users.
It is via Ansible Galaxy — the Docker Hub equivalent for Ansible — that these roles are shared. We come back to it in lesson 5.
6. The complete cycle — from idea to execution
Here is how these four building blocks articulate day to day.
This cycle is the foundation of all professional Ansible usage. In CI/CD, it is automated: a git push on the infrastructure repository triggers an ansible-playbook run, with a mandatory review via pull request.
7. Ad-hoc vs playbook — the two execution modes
Ansible offers two modes of use, complementary to each other.
Ad-hoc example for testing connectivity:
ansible all -m ping
This command asks Ansible to say "hello" to all the servers in the inventory. Useful to check that your inventory is correct and that SSH works everywhere, before writing your first playbooks.
In practice, a mature team uses 90% playbooks and 10% ad-hoc.
8. The trick question in interviews
"What is the difference between a playbook and a role?"
Clear answer: a playbook is a YAML file describing the tasks to do. A role is a structured, packaged and reusable playbook — with its files, its variables, its templates. You can see the role as a playbook + its environment, ready to be shared.
Analogy: a playbook is like an isolated bash script. A role is like a complete Git project with structure, variables, files.
Another frequent question: "Can I use Ansible for something other than Linux?"
Yes: Ansible drives Windows via WinRM, Cisco/Juniper network equipment, cloud APIs (AWS, Azure, GCP), databases, Docker, Kubernetes. That is what explains its longevity — it is a true universal automation tool, not just a Linux tool.
Remember in 30 seconds
- Inventory = address book of your servers, grouped logically.
- Playbook = musical score — YAML file describing the tasks to execute.
- Module = specialized instrument — Python building block that knows how to do one precise action.
- Role = shareable score — structured and reusable playbook.
- Two modes: ad-hoc (one command) and playbook (versioned file).
- Ansible Galaxy is the world catalog of shared roles.
Next: Agentless and idempotence: the 2 founding principles →