1. The Big Idea — Agentless Automation
Ansible runs on one machine (the control node — your laptop or a management server). From there it connects to all the servers you want to manage (the managed nodes) using plain SSH. The managed nodes need no agent, no daemon, no special software — just SSH and Python, which almost every Linux server already has.
🍕 Classroom analogy: Think of the control node as a teacher and managed nodes as students. The teacher reads instructions from a lesson plan (the playbook), checks the attendance list (the inventory) to know who's in class, and tells each student exactly what to do. The students don't need any special training beforehand — they just need to hear the teacher (SSH).
✅ Key point: Ansible is push-based. You run a command → Ansible pushes tasks out. Nothing runs on the servers waiting for orders (unlike Chef/Puppet agents that "pull" configuration).
2. The Data Flow — Animated
Press ▶ Play and watch what happens when you run ansible-playbook site.yml:
Ready — press Play to run the playbook.
3. What Happens in Each Step
| # | Step | What actually happens |
|---|---|---|
| 1 | Read playbook | Ansible parses playbook.yml — the list of plays and tasks you wrote in YAML. |
| 2 | Read inventory | It checks the inventory file to find which hosts belong to the group targeted by the play (e.g. webservers). |
| 3 | Generate module code | For each task, Ansible turns the module + parameters into a small Python script. |
| 4 | Push over SSH | The script is copied to each managed node over SSH and executed there. |
| 5 | Report & clean up | Each node returns a JSON result (ok / changed / failed), and the temporary script is deleted. Nothing is left behind. |
✅ Idempotency: If the server is already in the desired state, the module reports
ok and changes nothing. Run the same playbook 100 times → the result is the same. This is why Ansible describes the desired state, not commands to blindly repeat.4. The Inventory — Who Do I Manage?
The inventory is a simple list of your servers, organized into groups so a play can target many machines at once:
A play that says hosts: webservers automatically runs on every machine in that group — add a 50th web server to the group and the same playbook configures it too. That's how Ansible scales.
5. Vocabulary You'll See Everywhere
| Term | Meaning | Analogy |
|---|---|---|
| Control node | Machine where Ansible is installed and runs | The teacher |
| Managed node | Server being configured (no agent needed) | A student |
| Inventory | List of managed nodes, in groups | Attendance register |
| Playbook | YAML file with plays & tasks | Lesson plan |
| Play | Maps a group of hosts to a list of tasks | One lesson for one class |
| Task | One unit of work (calls one module) | One instruction |
| Module | Reusable code that does the actual work (apt, copy, service…) | A tool in the toolbox |
| Idempotent | Safe to run repeatedly — only changes what's needed | "Already done? Skip it." |