Architecture

Ansible Architecture – Detailed Explanation

Ansible is an open-source configuration management, automation, and orchestration tool enabling scale infrastructure automation. It follows a declarative approach and does agentless execution over SSH (for Linux) or WinRM (for Windows).

---

1. Ansible Architecture Overview

Ansible has a simple architecture consisting of the following key components:

1. Control Node (Master) – The system where Ansible is installed and executed.

2. Managed Nodes (Hosts) – Target machines that Ansible manages over SSH or WinRM.

3. Inventory File – A list of managed nodes (hosts) grouped under categories.

4. Modules – Small programs used to perform specific tasks (e.g., install a package, start a service).

5. Playbooks – YAML-based automation scripts that define tasks and configurations.

6. Plugins – Extend Ansible’s capabilities (e.g., connection plugins, lookup plugins).

7. Facts – System information collected dynamically before execution.

8. Roles – A structured way to organize playbooks and tasks for reusability.

---

2. Ansible Architecture Diagram

              +----------------------+
              |   Control Node        |
              |   (Ansible Master)    |
              +----------------------+
                        |
                        | SSH / WinRM
                        |
        --------------------------------------
        |               |                    |
   +----------+   +----------+          +----------+
   |  Host 1  |   |  Host 2  |   ...    |  Host N  |
   | (Linux)  |   | (Linux)  |          | (Windows) |
   +----------+   +----------+          +----------+

---

3. Components of Ansible Architecture

3.1. Control Node (Master)

• The main machine where Ansible is installed and executed.

• Contains the inventory file, playbooks, and modules.

• Uses SSH (Linux) or WinRM (Windows) to communicate with managed nodes.

• No agent installation is required on managed nodes.

👉 Example (Checking Ansible Version on Control Node)

ansible --version

---

3.2. Managed Nodes (Hosts)

• The servers, network devices, or cloud instances that Ansible configures.

• Ansible executes commands on these nodes via SSH (Linux) or WinRM (Windows).

• Hosts do not require an Ansible agent.

👉 Example (Running a Command on Managed Nodes)

ansible all -m ping

🔹 This command verifies connectivity to all managed nodes.

---

3.3. Inventory File

• A list of target hosts that Ansible manages.

• Can be stored in a static file (/etc/ansible/hosts) or dynamically fetched from cloud providers (AWS, Azure).

👉 Example (hosts Inventory File)

[web_servers]
192.168.1.10
192.168.1.11

[db_servers]
db1.example.com
db2.example.com

🔹 Groups like [web_servers] and [db_servers] help categorize servers.

---

3.4. Modules

• Small predefined programs that perform actions on managed nodes.

• Can handle tasks like installing packages, managing users, handling files, etc.

• Can be built-in or custom modules written in Python, Shell, or PowerShell.

👉 Example (Using the ping Module)

ansible all -m ping

🔹 Checks if all hosts are reachable.

👉 Example (Using the apt Module to Install Nginx)

- name: Install Nginx
  hosts: web_servers
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present

---

3.5. Playbooks

• YAML files containing a set of instructions (tasks) for automation.

• Can define configurations, software installations, or orchestration tasks.

👉 Example (Basic Playbook to Install Apache on Web Servers)

- name: Install Apache
  hosts: web_servers
  become: yes
  tasks:
    - name: Install Apache package
      apt:
        name: apache2
        state: present
    - name: Start Apache Service
      service:
        name: apache2
        state: started

🔹 become: yes allows running tasks with sudo privileges.

---

3.6. Plugins

Ansible plugins enhance functionality and include:

• Connection Plugins (e.g., SSH, WinRM)

• Lookup Plugins (e.g., retrieving values from databases or cloud APIs)

• Filter Plugins (e.g., formatting data)

👉 Example (Using a Lookup Plugin to Fetch Environment Variables)

- debug:
    msg: "Home directory is {{ lookup('env', 'HOME') }}"

---

3.7. Facts

• System information (e.g., OS type, IP address, CPU, memory).

• Gathered before execution using the setup module.

👉 Example (Fetching System Facts)

ansible all -m setup

---

3.8. Roles

• A structured way to organize Ansible playbooks into reusable components.

• Each role consists of tasks, handlers, templates, variables, and defaults.

📌 Role Structure Example (webserver_role/)

webserver_role/
├── tasks/main.yml
├── handlers/main.yml
├── templates/index.html.j2
├── vars/main.yml
├── defaults/main.yml
└── meta/main.yml

🔹 Roles improve scalability and reusability.

---

4. Ansible Execution Flow

1. User writes an inventory file defining managed nodes.

2. User writes playbooks describing tasks to execute.

3. User runs ansible-playbook to execute automation.

4. Control Node connects to Managed Nodes over SSH/WinRM.

5. Ansible executes modules on remote machines.

6. Results are displayed on the Control Node.

👉 Example (Running a Playbook)

ansible-playbook install_apache.yml

---

5. Ansible vs Other Configuration Management Tools

Feature	Ansible	Puppet	Chef	SaltStack
Agentless	✅ Yes	❌ No	❌ No	❌ No
Uses SSH	✅ Yes	❌ No	❌ No	❌ No
Declarative	✅ Yes	✅ Yes	✅ Yes	✅ Yes
Ease of Learning	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐
YAML Syntax	✅ Yes	❌ No	❌ No	✅ Yes

🔹 Ansible is simpler and easier to adopt compared to others.

---

6. Key Advantages of Ansible

✅ Agentless – No need to install software on managed nodes. ✅ Idempotent – Avoids unnecessary changes if the desired state is already met. ✅ Declarative – You define "what" to achieve, not "how". ✅ Multi-Cloud Support – Works with AWS, Azure, GCP, and Kubernetes. ✅ Easier to Learn – Uses human-readable YAML syntax.

---

7. Summary

Component	Description
Control Node	The master machine running Ansible.
Managed Nodes	Target machines managed by Ansible.
Inventory	A list of hosts or target systems.
Modules	Small programs that perform specific tasks.
Playbooks	YAML-based automation scripts.
Plugins	Extend Ansible’s capabilities.
Facts	System details collected before execution.
Roles	Structured reusable playbook components.

---

🔥 Interview Tip:

💡 Be ready to explain how you use Ansible in real-world projects (e.g., automating server provisioning, CI/CD, Kubernetes deployments).

Would you like Ansible scenario-based interview questions for practice? 🚀