What is Ansible? Configuration Management Explained
Imagine you need to install Nginx, configure it with your company's standard settings, open the correct firewall ports, and set up log rotation -- across 200 servers. Doing it manually is error-prone and slow. Writing custom shell scripts works but is fragile and hard to audit. Ansible gives you a third option: describe what you want in readable YAML, and let Ansible ensure every server matches that description.
Ansible was created by Michael DeHaan in 2012 and acquired by Red Hat in 2015. Today it is one of the most widely used configuration management tools, particularly for Linux infrastructure. It is part of the core DevOps tools skillset.
Why Agentless Matters
Most configuration management tools require an agent -- a daemon running on every managed host that polls a central server for instructions. Ansible takes a different approach: it connects over SSH (or WinRM for Windows), runs tasks, and exits. There is nothing persistent on the managed host.
This has practical advantages. You can manage hosts you do not control long-term, onboard existing servers without pre-installing software, and reduce the attack surface. The tradeoff is that push-based systems can be slower at scale (you are opening thousands of SSH connections) compared to agents that run in parallel against a central server. For most teams under a few thousand hosts, this is not a real constraint.
Core Concepts
Inventory
An inventory is a list of the hosts Ansible will manage, organized into groups. It can be a static INI or YAML file, or a dynamic inventory script that queries your cloud provider in real time.
[web_servers]
web01.prod.example.com
web02.prod.example.com
[db_servers]
db01.prod.example.com
[production:children]
web_servers
db_servers
Playbooks
A playbook is a YAML file that describes a sequence of tasks to run against a group of hosts. Tasks call modules -- pre-built units of automation for common operations (installing packages, managing files, starting services, running commands).
---
- name: Configure web servers
hosts: web_servers
become: true # Run as root via sudo
tasks:
- name: Install Nginx
ansible.builtin.package:
name: nginx
state: present
- name: Deploy Nginx configuration
ansible.builtin.template:
src: templates/nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: "0644"
notify: Restart Nginx
- name: Ensure Nginx is started and enabled
ansible.builtin.service:
name: nginx
state: started
enabled: true
handlers:
- name: Restart Nginx
ansible.builtin.service:
name: nginx
state: restarted
A few things worth noting here. The state: present on the package task is idempotent -- Ansible checks if Nginx is already installed before attempting the install. Running this playbook 100 times produces the same result as running it once. The notify/handler pattern ensures the service only restarts if the config file actually changed.
Roles
As playbooks grow, roles provide a standard directory structure to organize tasks, templates, variables, and files into reusable units. A role named nginx would live at roles/nginx/ and contain tasks/main.yml, templates/, vars/, and so on. Ansible Galaxy is the public registry where the community shares roles.
Running a Playbook
# Run a playbook against your inventory
ansible-playbook -i inventory.ini site.yml
# Dry-run to preview changes without applying them
ansible-playbook -i inventory.ini site.yml --check --diff
# Limit to a specific host group
ansible-playbook -i inventory.ini site.yml --limit web_servers
# Run a single task for debugging
ansible web_servers -i inventory.ini -m ansible.builtin.ping
The --check --diff combination is invaluable before running against production. It shows you which files would change and what the diff looks like, without touching anything.
Ansible vs. Terraform: The Right Tool for the Job
This distinction comes up constantly. Terraform is purpose-built for provisioning cloud resources -- it talks to cloud provider APIs to create VPCs, EC2 instances, RDS databases, and EKS clusters. Ansible can technically provision cloud resources too (it has AWS modules), but it is not its strength.
Ansible shines at configuration: installing software, writing config files, managing users and cron jobs, deploying application code. The most effective pattern is using Terraform to create the infrastructure, then Ansible to configure what runs on it. For containerized workloads, Docker handles the application packaging and Kubernetes handles orchestration -- in those environments, Ansible is often used primarily for cluster bootstrapping and host-level configuration.
Ansible in Modern DevOps
Ansible integrates cleanly into CI/CD pipelines. Many teams trigger playbooks from GitHub Actions or Jenkins to handle deployment steps that are awkward to express as container commands -- database migrations, certificate renewals, cache warm-ups.
For large-scale infrastructure, Ansible Automation Platform (Red Hat's commercial product) adds a web UI, role-based access control, and audit logging on top of the open-source core. For most teams, the open-source CLI is sufficient.