Before configuration management tools existed, setting up a server meant SSHing in and running commands by hand, install this package, edit that config file, start this service, then doing it again identically on the next server, and hoping you didn’t forget a step or fat-finger something along the way. Ansible replaces that manual, error-prone process with a declarative description of what a server’s configuration should look like, called a playbook, which Ansible then applies consistently across as many servers as you point it at.

What makes Ansible distinct from other configuration management tools is that it’s agentless: it doesn’t require installing any special software on the servers it manages, it simply connects over standard SSH (or WinRM for Windows) and runs Python modules remotely. That’s a meaningfully lower operational burden than tools requiring a persistent agent on every managed machine, and it’s a big part of why Ansible became so widely adopted.

This guide covers the core inventory-and-playbook model, a real working playbook installing and configuring nginx, idempotency (the design principle that makes Ansible safe to run repeatedly), variables and templates, organizing larger projects with roles, encrypting secrets with Vault, and the practical distinction between Ansible and Terraform that trips up a lot of people first learning infrastructure automation. It also covers the tools for running only part of a large playbook, handling dynamic cloud inventory, and testing changes safely before they touch real servers.

How Ansible Actually Works

Three pieces make up the core of any Ansible setup: an inventory file listing which servers to manage, playbooks describing what should be true about those servers, and Ansible itself, which connects over SSH and applies the playbook. There’s no central server or database to run; Ansible executes from wherever you run it (your laptop, a CI runner), connecting outward to the managed servers.

# inventory.ini
[webservers]
web-1.example.com
web-2.example.com

[databases]
db-1.example.com

[webservers:vars]
ansible_user=deploy

This inventory groups servers into webservers and databases, letting playbooks target specific groups rather than listing individual hostnames repeatedly. The ansible_user variable sets which SSH user to connect as for that group, one of many connection settings that can be scoped per group or per host.

A Real Playbook

A playbook is a YAML file describing a series of tasks to run against a group of hosts. Here’s one that installs and configures nginx on every server in the webservers group.

- name: Configure web servers
  hosts: webservers
  become: true
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
        update_cache: true

    - name: Copy nginx config
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx

    - name: Ensure nginx is running
      service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

ansible-playbook -i inventory.ini webservers.yml

become: true runs tasks with elevated privileges (sudo). The apt module installs nginx declaratively, state: present meaning “make sure this is installed,” not “install it every time regardless.” The template task renders a configuration file from a template and pushes it to the server, and notify triggers the restart handler only if that file actually changed, avoiding an unnecessary service restart when nothing changed.

Idempotency: The Core Design Principle

Idempotency means running the same playbook multiple times produces the same end result without unwanted side effects, a second run against an already-configured server reports “nothing changed” rather than reinstalling nginx or restarting a service that’s already running correctly. This is what makes Ansible safe to run repeatedly and on a schedule, rather than something you have to carefully track “have I already run this” for. Nearly every built-in Ansible module is written to be idempotent by default, which is a big part of what separates Ansible from a plain Bash script doing the same conceptual work: the same shell commands run twice would blindly reinstall and restart every time, while Ansible’s modules check current state first and only act when something actually needs to change.

Variables and Templates

Variables let a single playbook adapt to different environments or hosts without duplicating logic, and Jinja2 templates let configuration files reference those variables directly, rendering a different final file per environment from one template source.

# templates/nginx.conf.j2
server {
    listen 80;
    server_name {{ server_domain }};
    worker_processes {{ worker_count | default(2) }};
}

Variables like server_domain can come from the inventory, a separate variables file, or be passed on the command line, letting the same template render correctly for staging and production without maintaining two nearly-identical config files by hand. The | default(2) filter supplies a fallback value if worker_count isn’t explicitly set anywhere, a small but genuinely useful pattern for keeping templates robust.

Organizing Larger Projects With Roles

A single playbook file works fine for small setups, but real infrastructure typically needs reusable, shareable units of configuration, a “role” for setting up nginx, another for PostgreSQL, another for a monitoring agent, that can be composed together and reused across projects. Ansible Roles provide a standard directory structure for exactly this.

roles/
  nginx/
    tasks/main.yml
    handlers/main.yml
    templates/nginx.conf.j2
    defaults/main.yml

# In a playbook:
- hosts: webservers
  roles:
    - nginx
    - monitoring-agent

Once configuration is organized as roles, a playbook becomes a short, readable list of which roles apply to which hosts, and individual roles can be shared across multiple projects or even published to Ansible Galaxy, a public registry of community-maintained roles for common software.

Encrypting Secrets With Ansible Vault

Playbooks often need sensitive values, database passwords, API keys, that shouldn’t be committed to version control in plain text. Ansible Vault encrypts variable files, letting you commit the encrypted version safely while decrypting it automatically at runtime with a password or key file.

ansible-vault create secrets.yml
ansible-vault edit secrets.yml
ansible-playbook -i inventory.ini site.yml --ask-vault-pass

This is the same underlying goal as the .gitignore and secrets-management practices covered in our Git and GitHub guide, applied specifically to configuration values Ansible needs at runtime, keeping secrets encrypted at rest while still version-controlled alongside the rest of the configuration.

Ansible vs. Terraform: Different Jobs

These tools solve adjacent but distinct problems and are frequently used together: Terraform (covered in depth on our Terraform page) provisions the actual servers and networking, then Ansible configures software and settings on top of that freshly provisioned infrastructure. Some teams also use Ansible for lighter application deployment tasks, though that overlaps with the territory covered in our CI/CD pipelines guide.

A common real-world pattern chains the two directly: a Terraform local-exec or remote-exec provisioner triggers an Ansible playbook run immediately after a new server finishes provisioning, so a freshly created instance goes from “exists but unconfigured” to “fully configured and ready to serve traffic” in a single automated pipeline run, with no manual handoff step between the infrastructure and configuration layers.

Ad Hoc Commands for Quick Tasks

Not every task needs a full playbook. Ad hoc commands run a single module against an inventory directly from the command line, useful for quick, one-off operations like checking disk space across a fleet or restarting a service everywhere at once.

ansible webservers -i inventory.ini -m shell -a "df -h"
ansible all -i inventory.ini -m ping
ansible databases -i inventory.ini -m service -a "name=postgresql state=restarted" --become

The ping module (despite the name, it’s an Ansible connectivity check, not an ICMP ping) is a fast way to verify Ansible can actually reach and authenticate to every host in your inventory before running anything more consequential against them.

Tags: Running Only Part of a Playbook

A large playbook covering many concerns, package installation, configuration, monitoring setup, security hardening, doesn’t always need to run in full every time. Tags let you label specific tasks and then run (or skip) only those tasks on a given invocation, useful when you only want to push a config change without re-running the slower package installation steps that haven’t changed.

tasks:
  - name: Install nginx
    apt:
      name: nginx
      state: present
    tags: [install]

  - name: Copy nginx config
    template:
      src: templates/nginx.conf.j2
      dest: /etc/nginx/nginx.conf
    tags: [config]

ansible-playbook -i inventory.ini site.yml --tags config
ansible-playbook -i inventory.ini site.yml --skip-tags install

This selective execution becomes genuinely valuable once playbooks grow large enough that running the entire thing on every small change would be noticeably slow, letting you target exactly the part of the configuration you’re actively iterating on.

Dynamic Inventory for Cloud Environments

A static inventory file works fine when your server list is small and stable, but cloud environments where instances are created and destroyed regularly (especially alongside autoscaling) make a hand-maintained list impractical. Dynamic inventory plugins query your cloud provider’s API directly at runtime, automatically discovering current instances rather than relying on a manually updated file.

# aws_ec2.yml (dynamic inventory config)
plugin: aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
keyed_groups:
  - key: tags.Role
    prefix: role

With this configured, running ansible-inventory -i aws_ec2.yml --list queries AWS directly and groups instances automatically based on their tags, meaning a newly launched instance with the right tags is picked up automatically on the next playbook run, with no manual inventory file editing required at all.

Testing Playbooks Before They Touch Real Servers

Beyond the built-in --check dry-run mode, more disciplined Ansible projects use Molecule, a dedicated testing framework that spins up temporary containers or VMs, runs a role or playbook against them, and verifies the result matches expectations, all in an isolated environment that never touches real infrastructure. This mirrors the testing philosophy from our CI/CD pipelines guide: catching a broken playbook in an automated test before it ever runs against production is far cheaper than discovering the mistake live.

How This Connects to the Rest of DevOps

Ansible playbooks execute the same underlying Linux commands and concepts covered in our command line guide, just declared as structured YAML and applied at scale instead of typed manually one server at a time. It commonly runs as a stage inside a CI/CD pipeline, and frequently follows Terraform provisioning in the same automated deployment flow, handling the configuration layer once infrastructure exists.

Frequently Asked Questions

Building Real Fluency With Ansible

The fastest way to build genuine comfort with Ansible is writing a playbook for something you’d otherwise configure by hand anyway: setting up a personal server, configuring a home lab, or automating the setup of a development environment you rebuild periodically. Starting from a real, motivating use case makes the abstract concepts, idempotency, handlers, variables, click far faster than working through a generic tutorial with no stakes attached to getting it right.

As with the other automation topics in this curriculum, resist the urge to reach for maximum complexity immediately. A simple, flat playbook that correctly configures one server is a better starting point than an elaborate role-based structure you don’t yet understand the need for; roles and dynamic inventory earn their complexity once you’re managing enough servers, or enough variation between them, that the simpler approach starts genuinely breaking down under its own weight.

Related reading: continue to AWS for DevOps, revisit Terraform and infrastructure as code for the provisioning layer Ansible complements, or return to the full topics overview.