What Is Ansible

In the early days of system administration, managing servers was a manual process. If you needed to deploy a web application across ten servers, you had to log into each server individually, run installation commands, edit configuration files, restart services, and verify that the application was running.

This manual approach had several issues:

• Inconsistency: It is easy to make a typo on the seventh server, resulting in configuration drift.
• Lack of Scalability: Managing 1,000 servers manually is impossible.
• No Version Control: There was no record of who modified a configuration or why.

To solve this, the industry adopted Configuration Management tools. Ansible is one of the most popular open-source configuration management, application deployment, and task automation engines. Created by Michael DeHaan in 2012 and acquired by Red Hat in 2015, Ansible simplifies system administration by allowing you to define your infrastructure as code.

In this guide, we will explore the core philosophy of Ansible, examine how it works under the hood, analyze its building blocks, and compare it to traditional scripting methods.

The Core Philosophy of Ansible

Ansible was designed around four key principles:

1. Agentless Architecture

Unlike other configuration management tools (such as Chef or Puppet) that require you to install agent software on all target servers, Ansible is agentless. It does not require any background daemons or packages installed on your client nodes. Instead, it connects to your servers using standard SSH (for Linux/Unix) or WinRM (for Windows) to execute tasks, reducing system overhead and security risks.

2. Simplicity (YAML Playbooks)

Ansible configurations are written in YAML (Yet Another Markup Language). These configuration files, called Playbooks, are human-readable and act as self-documenting code. You do not need to be a programmer or know complex scripting languages to read or write playbooks.

3. Idempotency

An operation is idempotent if running it multiple times yields the same system state, without generating duplicate configurations or throwing errors. For example, if a playbook task ensures that Nginx is installed, running it the first time installs Nginx. Running it a second time checks that Nginx is present and skips the installation step, preventing duplicate modifications.

4. Declarative vs. Imperative

Traditional bash scripts are imperative: you define the exact steps to execute (e.g. "download this zip, copy to /var/www, run unzip"). Ansible is declarative: you define the desired final state of the system (e.g. "the directory /var/www/html must contain the unzipped contents of source.zip"). Ansible handles the underlying logic to achieve that state.

---

How Ansible Works Under the Hood

When you execute an Ansible playbook, the engine follows a structured execution path to configure your target servers:

Here is a step-by-step description of the execution process:

1. Load Configurations: The Ansible engine reads your playbook (the tasks to run) and the inventory (the list of target servers).
2. Compile Modules: For each task, Ansible locates the corresponding Module (e.g., apt or copy) and packages it with the input arguments into a small Python script.
3. Establish Connection: Ansible opens SSH connections to the target servers.
4. Copy and Run: The Python scripts are copied to a temporary directory on the remote nodes (typically ~/.ansible/tmp/) and executed.
5. Report Status: The remote Python script executes, changes the system state if needed, and returns the result as a structured JSON payload.
6. Clean Up: Ansible deletes the temporary Python files on the remote hosts, closes the SSH connection, and displays the execution summary on your console.

---

The Core Building Blocks of Ansible

Every Ansible project is composed of these four basic elements:

1. The Control Node

The machine where Ansible is installed. You execute playbooks and ad-hoc commands from the control node. It must be a Linux/Unix machine (macOS is supported for development, but Windows is not supported as a control node).

2. Managed Nodes (Hosts)

The target client servers, network devices, or cloud instances that Ansible configures. Managed nodes can run Linux, Unix, or Windows. They do not need Ansible installed; they only need Python (for Linux/Unix) or PowerShell (for Windows) to run the copied modules.

3. The Inventory

A configuration file (formatted as INI or YAML) that lists the IP addresses or DNS names of your managed nodes. Inventories allow you to group servers by role (e.g. [webservers], [databases]) or environment (e.g. [staging]).

4. Playbooks

YAML files containing one or more plays. A play maps a group of hosts from your inventory to a list of tasks. Each task calls an Ansible module to perform a specific action (e.g., creating a directory, starting a service, or deploying a file template).

---

Ansible vs. Traditional Shell Scripting

Here is a comparison between writing custom bash scripts and using Ansible to manage configurations:

---

Summary

Ansible is an agentless, declarative configuration management engine that simplifies system administration. By using YAML playbooks and connecting to servers via standard SSH, you can manage system states safely and consistently. In the next section, we will cover Ansible Use Cases.