Ansible: what it is and when it is the right tool.

What Ansible actually is

Ansible is a configuration management and orchestration tool. It reads a file you write in YAML describing the desired state of your servers, connects to each one, and applies whatever is different. It is written in Python, it was created in 2012, and it has been maintained by Red Hat since 2015.

The design decision that made it popular is that it is agentless. Comparable tools require a daemon installed on every managed machine plus a central server for them to check in with — a project in itself, and the reason many teams never adopt configuration management at all. Ansible connects over ordinary SSH and needs nothing pre-installed on the target beyond Python, which means you can start automating infrastructure you inherited this afternoon.

The second decision is that it is push-based and declarative. You run a playbook from your laptop or a CI pipeline and it pushes the changes out immediately, rather than agents polling a server on a schedule and converging eventually. That makes it good at orchestration — rolling restarts, ordered deployments across tiers — and not only at holding a fleet in a fixed state.

A real example

A playbook, explained

This is a complete, working playbook. It installs a web server, deploys a config file from a template, and makes sure the service is running — and it reloads nginx only if the config actually changed.

- name: Web servers
  hosts: webservers
  become: true

  vars:
    app_port: 8080

  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Deploy site config
      ansible.builtin.template:
        src: site.conf.j2
        dest: /etc/nginx/conf.d/site.conf
        owner: root
        mode: "0644"
      notify: Reload nginx

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

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Read it as a description, not a script. "state: present" does not mean "install nginx" — it means nginx should be installed, so if it already is, nothing happens. Same with the service: it should be started and enabled at boot, and if it already is, the task reports "ok" and moves on.

The `notify` line is the piece worth copying. It fires the handler only when the template task actually changed the file, and handlers run once at the end of the play no matter how many tasks notified them. That is how you avoid restarting a service on every single run — the classic way naive automation causes outages.

Note the module names are written in full: `ansible.builtin.package` rather than just `package`. Since collections were introduced, the fully-qualified name is the correct modern style and it removes any ambiguity about which module you meant.

The key property

Idempotency, and why it makes automation safe

A shell script is a list of commands, and running it twice does the work twice: it appends the line to the config again, it creates the user again and errors, it restarts the service for no reason. That is why people are nervous about running automation against a live system.

Ansible tasks assert state instead. Each module checks the current situation first and only acts on the difference, then reports one of three outcomes: ok (nothing needed), changed (it fixed something), or failed. A run against a correctly-configured fleet does nothing at all and reports zero changes, which is exactly what you want to see.

That property also gives you a free compliance check. Run the same playbook with --check and it reports what it would change without touching anything — so the description of how your systems should be configured doubles as the audit of whether they still are.

# Dry run: report what WOULD change, touch nothing
ansible-playbook -i inventory.yml site.yml --check --diff

# Apply to one group only
ansible-playbook -i inventory.yml site.yml --limit webservers

# Roll it out a few machines at a time instead of all at once
ansible-playbook -i inventory.yml site.yml --forks 5

# Encrypt a file of secrets so it can live in the repository
ansible-vault encrypt group_vars/all/vault.yml

Comparison

Ansible vs Terraform, Puppet, Chef and Salt

The most common confusion is Ansible versus Terraform, and it is a false choice — they do different halves of the job. Terraform creates infrastructure: the servers, networks and cloud resources. Ansible configures what runs on them once they exist. Plenty of setups use both, in that order.

Puppet and Chef are the closer comparisons, and the real difference is architecture rather than capability.

The pull model that Puppet and Chef use has a genuine advantage: agents keep re-applying the configuration on a schedule, so a machine that drifts gets corrected without anyone running anything. Ansible only enforces state when you run it, which means drift between runs is possible unless you schedule the playbook in CI.

What you trade for that is the agent, the certificate infrastructure and the central server. For most organisations below a very large fleet, that trade lands in Ansible's favour — which is why it is usually the easiest configuration management tool to actually get adopted.

The honest part

What Ansible is bad at

It is not the answer to everything, and pretending otherwise is how teams end up with an unmaintainable pile of YAML.

• Speed at scale — It connects over SSH to each host. Across thousands of machines that is slow compared to agent-based tools, though forks and pipelining help a lot.
• Complex logic — YAML is a description language. Once a playbook is full of nested conditionals and loops, that logic wanted to be a real program.
• Continuous enforcement — It only fixes drift when you run it. If you need constant convergence, schedule it in CI or use a pull-based tool.
• Provisioning cloud resources — It can, through modules, but Terraform tracks infrastructure state properly and is the better tool for that half.
• Windows-first estates — Windows is supported over WinRM or SSH, but the module ecosystem and the community knowledge are strongest on Linux.

Free or paid

ansible-core versus the commercial platform

This trips up buyers, because "Ansible" refers to two different things. ansible-core is the free, open-source command-line tool released under the GPL. It is complete: everything on this page works with it, and most organisations never need anything else.

Red Hat Ansible Automation Platform is the paid product built around it. What you pay for is not automation capability but the operational layer: a web UI and API for running jobs, role-based access control, scheduling, credential management, audit logging and certified content with vendor support. AWX is the open-source upstream of that web interface, if you want the capability without the support contract.

Our advice is boring: start with ansible-core in a repository with CI. Add the platform when you genuinely need multiple teams running jobs with governed access and an audit trail — not before, because it is a real operational commitment of its own.

Doing it properly

Secrets, testing and the parts people skip

Ansible is easy to start and easy to do badly. Three habits separate a codebase that lasts from a folder of YAML nobody wants to touch.

• Encrypt secrets in the repo — ansible-vault encrypts variable files in place, so credentials can be version-controlled safely instead of living in someone's shell history.
• Lint and test — ansible-lint catches bad practice mechanically; Molecule spins roles up in containers and verifies they actually converge.
• Run it from CI, not laptops — A pipeline gives you a log of who applied what and when, and it removes the "works on my machine" class of problem entirely.
• Factor into roles early — The moment two playbooks share tasks, that shared part is a role. Copy-paste is how playbook sprawl starts.
• Check mode before production — --check --diff on a live host tells you exactly what would change. Make it a habit and surprises mostly stop happening.