Ansible Explained: Servers Configured by Declaring What You Want

Introduction

Configuring servers by hand — SSH in, install packages, edit config files, repeat on the next machine — does not scale, and shell scripts that do it tend to break on the second run. Ansible, released in 2012 and now part of Red Hat, automates infrastructure declaratively: you write YAML playbooks describing the desired state, and Ansible makes servers match it, over plain SSH, with no agent installed on the machines it manages. That agentless simplicity made it the gentlest on-ramp to infrastructure automation.

Playbooks, tasks, and idempotence

Ansible's model has three layers:

• Inventory — a list of hosts (servers) to manage, grouped by role: web servers, databases, and so on.
• Playbooks — YAML files of plays, each targeting a host group with a list of tasks.
• Modules — the units of work: apt installs packages, copy places files, service manages daemons — each module knows how to check current state and change only what differs.

A playbook shows the style — declare the outcome, let Ansible handle the steps:

- name: Configure web servers
  hosts: webservers
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    - name: Start nginx
      service:
        name: nginx
        state: started

Run it twice and the second run changes nothing — that property, idempotence, is the point: playbooks describe desired state, not a sequence of commands, so they are safe to rerun and easy to reason about. Roles package reusable playbooks for sharing across projects.

The honest trade

Ansible's trade is speed and scale: SSH-based execution is slower than agent-based tools for very large fleets, and its YAML can grow unwieldy for complex logic (loops and conditionals in YAML are nobody's favourite). Terraform (the batch 12 post) is the better tool for provisioning cloud resources themselves; Ansible shines at configuring what runs on them. The rule of thumb: Ansible when you want agentless, readable server configuration; Terraform for provisioning, Puppet/Chef when an always-on agent model fits better.

Takeaway

Ansible is servers configured by declaring what you want: YAML playbooks, modules, and idempotent tasks, delivered agentlessly over SSH. It trades raw speed for readability and simplicity — and for configuration management, that readability is why teams adopt it.

Originally published at https://practicaldevblog.blogspot.com/2026/10/ansible-explained-servers-configured-by.html