What Ansible Is

Ansible is Red Hat's configuration-management and automation tool. It configures servers by connecting to them over plain SSH and pushing changes — with no agent to install, no daemon polling in the background, and crucially no central state file. You install Ansible on one control node, list your servers in an inventory, and describe the desired state in YAML; Ansible logs into each machine, checks what it looks like right now, and makes only the changes needed to match.

Three design choices define it, and they are best understood together: agentless, push-based, and stateless. Each one is a deliberate departure from the configuration-management tools that came before, and each one shapes how you work with Ansible every day. The rest of this topic takes them in turn.

Agentless over SSH

There is nothing to install on a managed node beyond two things a Linux server already has: an SSH daemon and Python. Ansible connects over SSH, copies small module programs to the machine, runs them, collects the results, and removes them. Onboarding a new server is therefore adding a line to an inventory file — not bootstrapping an agent, opening a new port, or managing yet another piece of software that itself needs patching.

That single property removes a whole category of problems. There is no agent fleet to upgrade, no agent-to-server version skew, and no chicken-and-egg of "how do I configure the thing that configures the machine?" If a host answers SSH and has Python, it is already manageable, which is why Ansible spread to teams that never wanted to run a configuration-management server at all.

Push, Not Pull

You trigger a run from the control node and Ansible pushes the changes out to the fleet. This is the opposite of the agent model, where each machine pulls its configuration from a central server on a timer. Push means you decide exactly when change happens — now, in this pipeline step, in this order — which is precisely what an orchestrated deploy needs, because step two must be able to wait for step one. The trade is that nothing enforces state between your runs; if you want continuous enforcement, you schedule the runs yourself.

No State File

This is the deepest difference from a provisioning tool like Terraform, and the idea the whole course leans on: Ansible stores no record of what it has done, because the managed node is the record. Every run gathers the machine's current facts and reconciles them against your declared state, live. There is no state file to lock, corrupt, drift from reality, or accidentally check into git.

The consequence is freeing and limiting at once. Freeing, because there is nothing to manage besides your playbooks and inventory, and two people can run the same playbook without coordinating over a shared state lock. Limiting, because Ansible cannot cleanly destroy what it no longer manages — remove a task and Ansible simply stops touching that thing; it has no memory that it once created it. Stateful cleanup is the provisioning layer's job, and the next two topics draw that line.

Idempotency Lives in the Modules

Ansible's idempotency is not a global engine feature — it is enforced module by module. The apt module checks whether a package is already installed before installing it; the service module checks whether a service is already running; the copy module compares checksums before overwriting. Each reports changed only when it actually changed something, which is what lets you run a playbook repeatedly and watch it settle to all-green after the first pass. Choosing idempotent modules over raw commands is the single most important habit in writing good Ansible, and a later chapter is devoted to it.

YAML All the Way Down

Inventory, variables, and playbooks are YAML — a format readable by people who do not write Python. The playbook below installs and starts nginx on every host in the web group; it reads almost like English, and that low floor is why Ansible reached network engineers and operators who never adopted a Ruby or Puppet DSL. The two tasks are idempotent: run this twice and the second run reports no change, because nginx is already present and running.

- hosts: web
  become: true            # escalate to root for package + service management
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Ensure nginx is running and enabled at boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Nothing in that file says how to install a package or how to start a service — it declares the state it wants, and the modules figure out the rest against whatever the machine currently looks like. That is configuration management in miniature, and every chapter after this one is an expansion of it.