Ansible Architecture

 

When I started learning Ansible, one of the first things I wanted to understand was how it actually works internally. My trainer explained the architecture in a simple way, and once I understood the flow, everything else in Ansible became easier.

In this blog, I’m sharing Ansible Architecture exactly how I understood it during my DevOps training.

⭐ How I Understand Ansible Architecture

Ansible’s architecture is simple and lightweight. There are mainly three major components:

  1. Control Node (Controller)

  2. Managed Nodes (Target Machines)

  3. Inventory File

Ansible uses SSH to connect to servers — no agents, no background services, no complicated setup.

⭐ 1. Control Node (Where Ansible Runs)

This is the machine where Ansible is installed.

From here, I run:

  • ad-hoc commands

  • playbooks

  • inventory operations

  • automation tasks

During my practice, I used an Ubuntu EC2 instance as the controller.

The controller is the “brain” of Ansible.

⭐ 2. Managed Nodes (Servers I Control)

These are the remote servers where Ansible performs tasks like:

  • installing packages

  • creating users

  • deploying applications

  • starting services

What I found interesting:

👉 Managed nodes don’t need Ansible installed.
👉 SSH access is enough.

This is why Ansible is called agentless, and this is one of the biggest reasons teams prefer it.

⭐ 3. Inventory – Server List

The inventory tells Ansible which servers to connect to.

Example INI format I used:

[web]
192.168.1.10
192.168.1.11

[db]
192.168.1.20

YAML example:

all:
  children:
    web:
      hosts:
        web1:
          ansible_host: 192.168.1.10

Inventory is basically the “address book” for Ansible.

⭐ Architecture Diagram (How I Visualized It)

+-------------------+        SSH        +----------------------+
|   Ansible Control |  ----------------> |   Managed Node 1     |
|      Machine      |                   |   (EC2 / VM / Server)|
+-------------------+                   +----------------------+

                            SSH        +----------------------+
                     ----------------> |   Managed Node 2     |
                                      +----------------------+

This diagram made the architecture very easy for me to remember.

⭐ Putting It All Together (My Practice Flow)

Here’s how everything fits when I run a playbook:

  1. I install Ansible on the controller

  2. I create an inventory with my server IPs

  3. I write a YAML playbook

  4. I run it using ansible-playbook

  5. Ansible connects via SSH

  6. Modules execute tasks

  7. Server configuration changes automatically

This simple workflow made automation feel powerful and smooth.

⭐ Quick Example (Architecture In Action)

Inventory:

[web]
54.23.10.12 ansible_user=ubuntu ansible_ssh_private_key_file=key.pem

Playbook:

- hosts: web
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

Command:

ansible-playbook -i inventory.ini install-nginx.yml

Ansible → SSH → Managed Node → Task Completed ✔

⭐ Final Thoughts

Ansible’s architecture is one of the simplest in DevOps.
No agents, no extra services — just:

  • one control machine

  • multiple target machines

  • one inventory

  • and SSH

Once this clicked for me, learning modules, playbooks, and inventory management became much easier.

Next, I will write about Ansible Modules — the building blocks of all automation.

Comments

Post a Comment

Popular posts from this blog

Ansible Playbooks – How I Learned to Automate Complete Tasks

 After getting comfortable with ad-hoc commands, I moved on to the most important part of Ansible — Playbooks . This is where the real automation happens. Ad-hoc commands are good for quick tasks, but playbooks allow me to write repeatable, structured, and complete automation scripts . In this blog, I’ll explain playbooks in the simplest way possible, based on how I understood and practiced them. ⭐ What Are Ansible Playbooks? (In My Own Words) Playbooks are YAML files where I define: what tasks I want to run on which servers in what order with what configurations Playbooks allow me to automate full workflows like: installing packages configuring services deploying applications managing files creating users restarting services For me, a playbook is basically: “A step-by-step automation recipe written in YAML.” ⭐ Basic Structure of a Playbook Here’s the structure I internalised: - name: <description> hosts: <target_serv...
Read more

Understanding Ansible Modules

 As I continued learning Ansible, one of the most important concepts I came across was Modules . They are the core of how Ansible performs automation. Once I understood modules clearly, writing playbooks and running ad-hoc commands became much easier and more meaningful. In this blog, I’m sharing what Ansible modules are and how I understood them through hands-on practice. ⭐ What Are Ansible Modules? (In My Own Words) Modules are the actual actions Ansible performs on a server. If I want to: install a package create a file add a user start a service copy a configuration Ansible uses a module to do it. So for me: “Modules are the building blocks of every automation task in Ansible.” Every ad-hoc command and every task inside a playbook uses a module. ⭐ How I Understand the Working of Modules Whenever I run Ansible: Ansible connects to the server through SSH The selected module runs on the remote machine It performs the action I defined I...
Read more

“What is Ansible? – My Understanding as a DevOps Learner”

  What is Ansible? – My Understanding as a DevOps Learner When I started my DevOps journey, Ansible was one of the first automation tools I learned. At the beginning, I only knew that Ansible “automates tasks,” but after going through my training sessions and hands-on practice, I understood how powerful and simple it actually is. In this blog, I want to explain what Ansible means in my own words , exactly how I understood it as a beginner. ⭐ How I Understand Ansible Ansible is an open-source automation tool that helps us manage servers without doing everything manually. Instead of logging into each machine and running commands one by one, I can write instructions in a simple YAML file, and Ansible applies them to any number of servers at the same time. So for me, Ansible is basically: “Write once → run anywhere → automate everything.” That’s the beauty of it. ⭐ Why Ansible is Very Useful From my learning, these are the main reasons: 1. It is agentless This was the ...
Read more