Ansible Course
Ansible Architecture
In this lesson
Ansible's architecture is the set of components that work together to deliver automation — from the machine you run commands on, to the servers you manage, to the files that describe what should happen. Understanding how these components relate to each other is essential before writing a single line of YAML, because every playbook, every module, and every inventory file you encounter in this course maps directly to one of these architectural pieces.
The Big Picture
At its core, Ansible has a simple three-layer structure. You write automation code on a control node, define your targets in an inventory, and Ansible pushes tasks to managed nodes over SSH. No agents. No daemons. No message queues.
Core Components
Ansible's architecture has five named components. Each has a specific job, and together they cover the complete automation workflow — from defining targets to executing tasks and reporting results.
Control Node
The machine where Ansible is installed and from which all automation is triggered. This is your laptop, a jump server, or a CI/CD runner — never the servers you are managing.
Managed Nodes
The servers, network devices, or cloud instances that Ansible configures. They require only SSH access and Python — no Ansible installation needed on these machines.
Inventory
A file (or dynamic source) listing all managed nodes and organising them into groups. Ansible reads the inventory to know which hosts to target and how to connect to them. Covered in depth in Lesson 7.
Modules
The units of work. Each module does one thing — install a package, copy a file, start a service. Ansible ships with 5,000+ built-in modules and transfers them to managed nodes at runtime. Covered in Lesson 9.
Playbooks
YAML files that describe a series of tasks to run against a set of hosts. A playbook is the main unit of reusable automation in Ansible — think of it as the script that orchestrates modules against your inventory. Covered in depth from Lesson 12 onwards.
The Building Site Analogy
Think of the control node as the site office where the project manager works. The inventory is the list of buildings on the site. The playbook is the construction schedule — what gets built, in what order, and on which buildings. The modules are the individual tradespeople (electrician, plumber, painter) who each do one specific job. The project manager (Ansible) dispatches the right tradesperson to the right building at the right time, checks the work is done, and reports back.
How a Playbook Run Works
When you run
ansible-playbook, a precise sequence of events unfolds. Understanding this
sequence helps you debug failures and reason about what Ansible is doing at any point.
Phase 1
Parse the playbook and inventory
Ansible reads your YAML playbook and inventory file, validates the syntax, resolves variables, and builds an internal task list. No connection to any server happens yet.
Phase 2
Open SSH connections
Ansible opens SSH connections to all targeted managed nodes in parallel — up to the configured fork count (default: 5 at a time). This is the only network requirement.
Phase 3
Transfer and execute modules
For each task, Ansible transfers the relevant module (a small Python script) to the managed node, executes it remotely, collects the result, then removes the temporary file. The node does the actual work; the control node orchestrates.
Phase 4
Collect results per task
Each task returns
one of four statuses: ok (no change needed), changed
(change applied), failed (error), or skipped (condition
not met). Ansible halts a host's task chain on failure by default.
Phase 5
Print the play recap
After all tasks complete, Ansible prints a summary showing how many hosts were ok, changed, failed, or unreachable. This recap is your primary signal of whether the run succeeded and what changed.
Optional Components
Beyond the five core components, Ansible has a set of optional pieces that become relevant as your automation grows more sophisticated. You will not need most of these in the early lessons, but it is worth knowing they exist.
Optional Ansible components
Set Up Your Practice Environment
Now that you understand Ansible's architecture, it's time to get your environment ready. The hands-on lessons from Section II onwards assume you have these tools installed. Set them up now so you can follow along from Lesson 5 (Installation and Setup) without interruption.
Tools used in this course
Install these before Lesson 5 — click each link to go to the official download page
Visual Studio Code
The recommended editor for writing YAML playbooks. Install the Ansible extension by Red Hat for syntax highlighting, linting, and auto-complete.
WSL 2 (Windows) / Linux / macOS
Ansible's control node must run on Linux or macOS. Windows users should install WSL 2 (Windows Subsystem for Linux) to get a full Ubuntu environment.
Vagrant + VirtualBox
Spin up local Linux VMs to act as managed nodes — perfect for practising without needing a cloud account. Free and runs entirely on your machine.
Git
Version control for your playbooks. All course examples assume your work is in a Git repository — this is industry-standard practice for Infrastructure as Code.
Ansible Documentation
The official reference for every module, plugin, and configuration option. Bookmark this now — you will use it throughout the course and beyond.
Ansible VS Code Extension
Adds YAML-aware Ansible syntax highlighting, linting via
ansible-lint, and module auto-complete
directly in VS Code. Maintained by Red Hat.
💡 Cloud alternative: If you prefer not to set up local VMs, any cloud provider works as your managed nodes. A free-tier AWS account ↗ or GCP free tier ↗ gives you enough to practise everything in this course at no cost.
Ansible Cannot Run on Windows as a Control Node
Ansible's control node requires a Unix-like operating system. Windows is not supported as a control node — only as a managed node (via WinRM). Windows users must use WSL 2, a Linux VM, or a remote Linux server as their control node. Attempting to install Ansible directly on Windows will fail. This is a hard architectural constraint, not a configuration issue.
Key Takeaways
Teacher's Note
Get your environment set up this week — every lesson from Lesson 5 onwards has something to run. Watching without doing is the slowest way to learn Ansible.
Practice Questions
1. What is the name for the machine where Ansible is installed and from which all automation is triggered?
2. Which Ansible component lists all the managed nodes and organises them into groups?
3. What must Windows users install to run Ansible as a control node on their machine?
Quiz
1. When Ansible runs a task, what does it do with the relevant module?
2. What are the only two requirements on a managed node for Ansible to work?
3. What is the correct order of phases when Ansible runs a playbook?
Up Next · Lesson 4
Control Node and Managed Nodes
A deeper look at the relationship between your control node and managed nodes — connection methods, privileges, and how Ansible handles large fleets efficiently.