Ansible Overview

First PublishedFeb 16, 2026Last UpdatedMar 30, 2026ByAtif Alam

Ansible is an open-source automation tool for configuration management, application deployment, and orchestration. It connects to machines over SSH (or WinRM for Windows), runs tasks, and requires no agent on the target hosts — just Python and SSH.

Why Configuration Management?

• Repeatable — Define the desired state of your servers once, apply it everywhere.
• Drift prevention — Re-run the same playbook and it corrects any manual changes.
• Self-documenting — Playbooks describe exactly what’s installed and configured.
• Scalable — Configure 1 server or 1,000 with the same code.

Why Ansible?

• Agentless — No daemon to install or maintain on target hosts. Just SSH + Python.
• Simple syntax — YAML playbooks are readable even by non-developers.
• Idempotent — Running the same playbook twice produces the same result (no unintended side effects).
• Batteries included — Thousands of built-in modules for packages, files, services, users, cloud APIs, containers, and more.
• Push-based — You run Ansible from a control node and it pushes changes. No pull agent polling.

Ansible vs Alternatives

Tool	Approach	Agent	Language
Ansible	Push, agentless	None (SSH)	YAML (playbooks)
Chef	Pull, agent-based	Yes	Ruby (recipes) — see Chef overview
Puppet	Pull, agent-based	Yes	Puppet DSL (manifests)
SaltStack	Push or pull	Optional (minion)	YAML + Jinja2

Ansible vs Terraform

They solve different problems and are often used together:

	Terraform	Ansible
Purpose	Provision infrastructure (create VMs, networks, databases)	Configure infrastructure (install packages, deploy apps, manage files)
State	Tracks state in a state file	Stateless — checks current state each run
Approach	Declarative	Procedural (tasks run in order) with declarative modules
Typical flow	Terraform creates the VMs → Ansible configures them

How Ansible Works

Control node (your laptop / CI server)
    │
    │  SSH
    ├──────→  Host 1  (web server)
    ├──────→  Host 2  (web server)
    └──────→  Host 3  (database)

1. Ansible reads the inventory (which hosts to target)
2. Reads the playbook (what tasks to run)
3. Connects via SSH
4. Copies a small Python script to each host
5. Executes the script (the module)
6. Collects results and reports back
7. Cleans up the script

No persistent connection, no agent process. Each run is independent.

Key Terminology

• Control node — The machine where you run Ansible (your laptop, a CI server).
• Managed node (host) — A remote machine Ansible configures.
• Inventory — A list of managed nodes, organized into groups.
• Playbook — A YAML file containing plays (sets of tasks to run on hosts).
• Task — A single action (install a package, copy a file, start a service).
• Module — The code that performs a task (e.g. apt, copy, service). Ansible ships with thousands.
• Role — A reusable, structured package of tasks, templates, files, and variables.
• Handler — A task triggered by a notification (e.g. restart nginx after config changes).
• Facts — System information Ansible gathers from hosts (OS, IP, memory, etc.).

Installing Ansible

# pip (recommended)
pip install ansible

# macOS
brew install ansible

# Ubuntu/Debian
sudo apt install ansible

Verify:

ansible --version

Topics in This Section

Start with inventory (which hosts), then playbooks (what to do), then modules, roles, and best practices.

• Inventory — Static and dynamic inventory, groups, host variables, and children.
• Playbooks — Plays, tasks, handlers, conditionals, loops, error handling, rolling updates, delegation, async, and strategies.
• Modules — Common modules for packages, files, services, users, commands, and writing custom modules.
• Roles — Role structure, creating roles, Ansible Galaxy, and dependencies.
• Variables and Templates — Variable precedence, facts, Jinja2 templates, filters, and conditionals.
• Best Practices — Idempotency, tagging, Vault, Molecule, project layout, troubleshooting, and performance tuning.