Ansible Architecture

Understanding Ansible's architecture is the foundation upon which all practical skills are built. Before you write a single line of YAML, you must have a clear mental model of how Ansible works internally — what the components are, how they communicate, and why the agentless design is such a significant advantage. This lesson builds that mental model from the ground up.

The Big Picture: How Ansible Moves Information

At its most fundamental level, Ansible is a tool that runs on one machine (your control node) and connects to other machines (your managed nodes) to execute tasks. The connection between them uses standard SSH — the same protocol you already use when you type ssh user@server in your terminal. No special protocol, no proprietary agent software, no persistent daemon processes. Just SSH.

When Ansible executes a task, it:

1. Reads the task definition from your playbook or ad-hoc command
2. Generates a small Python script that implements the task logic
3. Copies that script to the managed node via SSH (using SFTP or SCP)
4. Executes the script on the managed node
5. Collects the output and reports results back to the control node
6. Cleans up the temporary script files

This entire cycle happens in seconds. From your perspective as the operator, you run one command and receive a structured report of what happened on every managed node.

The Control Node

The control node is the machine where Ansible is installed and from which all automation is initiated. This can be:

• Your local laptop or workstation
• A dedicated automation server
• A container in a CI/CD pipeline
• An Ansible Tower or AWX instance

The control node must run a Unix-like operating system. Ansible itself does not run natively on Windows — though you can use Windows Subsystem for Linux (WSL) to run Ansible on a Windows machine. The control node needs Python 3.8 or later and Ansible installed.

Critically, the control node is the only machine that needs Ansible installed. This is the essence of the agentless design.

Key Files on the Control Node

ansible.cfg — The main configuration file for Ansible. It controls defaults like the location of the inventory file, the remote user, the SSH private key path, and dozens of other settings. Ansible searches for this file in several locations in order: the current directory, the home directory, and the system-wide configuration at /etc/ansible/ansible.cfg.

Inventory file — A file (or directory, or dynamic script) that tells Ansible which managed nodes exist and how to connect to them. By default, Ansible looks for a file called hosts in /etc/ansible/, but in practice you will always specify your own inventory file.

Playbooks — YAML files containing the automation logic you want to execute. These are the primary artifact of Ansible development.

Managed Nodes

Managed nodes are the servers, network devices, cloud instances, or any other targets that Ansible configures. The requirements for a managed node are minimal:

• SSH must be running and accessible from the control node
• Python must be installed (Python 2.7 or Python 3.5 and above)
• The connecting user must have the appropriate permissions (sudo access for privileged operations)

That is it. No Ansible software, no agent process, no open ports beyond SSH. This minimal requirement is one of the most operationally significant advantages Ansible has over agent-based tools — you can immediately begin managing any server that already exists in your infrastructure without touching it first.

Windows Managed Nodes

Ansible can manage Windows servers as well, but the transport mechanism is different. Instead of SSH and Python, Ansible uses WinRM (Windows Remote Management) and PowerShell. Windows management is a specialised topic covered in advanced Ansible courses; this course focuses on Linux-based managed nodes.

Modules: The Building Blocks of Automation

A module is a discrete unit of work that Ansible knows how to perform. When you write a task in a playbook, you are invoking a module. Ansible ships with over three thousand built-in modules covering an enormous range of operations:

• Package management: apt, yum, dnf, pip
• File operations: copy, template, file, lineinfile
• Service management: service, systemd
• User management: user, group
• Cloud providers: ec2_instance, azure_rm_virtualmachine, gcp_compute_instance
• Network devices: Modules for Cisco IOS, Juniper Junos, Arista EOS, and dozens more
• Databases: mysql_db, postgresql_db, mongodb_user

When you need a module that is not in the standard library, the Ansible Galaxy community repository contains thousands more. If you cannot find what you need there, you can write your own module in Python.

Plugins: Extending Ansible's Core Behaviour

While modules perform the actual work on managed nodes, plugins extend Ansible's core functionality on the control node. Key plugin types include:

• Connection plugins: Define how Ansible connects to managed nodes (SSH, WinRM, Docker, kubectl, local)
• Inventory plugins: Allow dynamic inventory sources like AWS EC2, Azure, GCP, or a CMDB
• Lookup plugins: Retrieve data from external sources (files, databases, Hashicorp Vault, environment variables)
• Filter plugins: Transform data within Jinja2 templates
• Callback plugins: Format output or send notifications when playbooks run

The Agentless Architecture: Why It Matters

The architectural decision to use SSH instead of a persistent agent has profound practical implications:

Zero managed-node overhead. An agent is a process that runs permanently on every managed server. It consumes CPU, memory, and disk space. It must be monitored, updated, and secured. Multiply that overhead by thousands of servers and you have a significant operational burden. Ansible eliminates this burden entirely.

No bootstrapping problem. With agent-based tools, you need to install the agent on a server before you can configure it. But how do you install the agent? Manually, which defeats the purpose. Ansible bypasses this chicken-and-egg problem because it only needs SSH, which is present on virtually every Linux server by default.

Immediate applicability to existing infrastructure. If your organisation has existing servers that were provisioned manually or by another tool, you can begin managing them with Ansible immediately without touching them first. This makes Ansible ideal for gradually automating legacy environments.

Security simplicity. Managing agent certificates, agent-server trust relationships, and agent update processes creates a security surface area. Ansible's security model reduces to: secure your SSH keys and control node access. Most security teams find this significantly simpler to audit and maintain.

How a Typical Ansible Run Works End to End

Let us trace a complete Ansible execution to solidify the architecture in your mind:

1. You type ansible-playbook deploy-webserver.yml -i inventory.ini on your control node.
2. Ansible parses the inventory file and identifies the target hosts.
3. Ansible reads the playbook YAML and builds an internal execution plan.
4. Ansible gathers facts about each managed node (unless told to skip this step) — OS type, IP addresses, memory, installed packages, and hundreds of other variables — by running the setup module via SSH.
5. Ansible processes each play in sequence, evaluating conditionals and variables.
6. For each task, Ansible generates the appropriate module code, transfers it to the managed node via SSH/SFTP, executes it, collects the JSON result, and removes the temporary file.
7. Ansible evaluates the result: if the task resulted in a change, it marks it as "changed" and triggers any relevant handlers. If the system was already in the desired state, it marks it as "ok".
8. After all plays complete, Ansible prints a summary showing how many tasks were ok, changed, failed, or skipped per host.

Try This: Draw the Architecture

On paper or in a diagramming tool, draw the following components and connect them with arrows showing the direction of communication:

• Control Node (with ansible.cfg, inventory.ini, and site.yml playbook)
• Three Managed Nodes (web01, web02, db01)
• SSH connections between control and managed nodes
• A small box labeled "Python script" being transferred and executed on each managed node

Summary

Ansible's architecture consists of a control node running automation logic and managed nodes that receive instructions via SSH. The agentless design eliminates the operational overhead of persistent agent processes, makes Ansible immediately applicable to any SSH-accessible server, and simplifies the security model. Modules are the atomic units of work; plugins extend Ansible's core behaviour. Understanding this architecture makes every subsequent Ansible concept immediately logical.