Lesson 33.34 · Ansible: Configuration as Code · 10 min read

Ansible next to the other tools: who owns what

Q: When would you use Ansible, and when would you not?

I use Ansible for Layer 2, configuration.: the operating system of servers that already exist, packages, users, files, services, and for ordered changes such as rolling restarts. It fits Long-lived servers, Bootstrapping new machines, Building images, and Day-2 operations as code. It keeps no state of its own; the host is the state. I would not use it to own what another tool owns: Layer 1, provisioning. belongs to a tool that keeps a state of the resources it created, and the runtime of applications to an orchestrator. The rule is that every setting has exactly one owner, otherwise tools fight and cause drift.

In plain words

In a house, the electrician owns the wiring, the plumber owns the pipes and the decorator owns the paint. If the decorator also rewires a socket, the electrician later finds something they did not do, "fixes" it, and the two keep undoing each other's work.

Servers have the same layers: the machine itself, the operating system, the application and how it keeps running. Ansible is the right owner for the operating system layer on long-lived servers, and for careful ordered changes. The rule for the whole platform is simple: every setting has exactly one owner, so tools never fight.

The problem

Ansible can do almost anything: there are collections that create cloud VMs, manage DNS, drive network switches, deploy applications and talk to orchestrators. That is exactly the danger. When two tools both believe they own the same thing - the size of a VM, the version of an app, a firewall rule - they fight: each run "fixes" what the other just did, and nobody knows which one is the truth. The last lesson of the chapter is not a new command. It is the map of who should own what, and where Ansible earns its place.

What you need to know already: the whole chapter, and the first lesson's three approaches (scripts, golden images, configuration management).

Four layers, four owners

Think of a running service as layers, each changing at its own speed:

layer                         examples                                  changes
1  resources                  VMs, disks, networks, DNS, load balancers  rarely, by request
2  the operating system       packages, users, sshd, sysctl, agents      weekly (patches)
3  the application release    version 1.4.2, its config, its migrations  daily
4  the runtime                how many copies run, where, restarts       all the time

Each layer wants a tool built for its rhythm:

Layer 1, provisioning. A tool that creates and destroys resources from a declarative description and keeps a record (a state) of what it created, so it can change or delete exactly that. It answers "does this VM exist, with this size?".
Layer 2, configuration. This chapter. Ansible converges an existing machine to a described state: packages, files, users, services. It keeps no state of its own - the host is the state, which is why it compares before it changes.
Layer 3, release. Something that knows the version and rolls it out safely: an Ansible rolling playbook on a VM fleet, or the deployment machinery of an orchestrator.
Layer 4, runtime. A scheduler that keeps N copies alive and restarts them; for a plain VM, systemd (Restart=always, chapter 2) is that scheduler.

Later (Ch 12, 15): Terraform owns layer 1 (cloud resources, with a state file); Kubernetes owns layers 3 and 4 for containers (Deployments roll out releases, controllers keep replicas running).

Mutable and immutable

Ansible manages mutable infrastructure: the server lives for years and is changed in place - patched, reconfigured, upgraded. The risk is drift: changes made by hand, or by a run that half-failed, that make two "identical" servers different. Ansible fights drift by being re-run (often, on a schedule, with --check --diff to see the drift first).

Immutable infrastructure never changes a running server: a new version is a new image, new servers replace the old ones, a rollback is the previous image. There is nothing to drift. Ansible still has a job there - it is a common way to build the image (install, configure, harden once, then snapshot), run by an image builder.

Most real estates are both: immutable for the stateless web tier, mutable for databases, bastion hosts, the box that runs the build agents, and that one legacy app.

Later (Ch 10): container images are the immutable approach for applications; a Dockerfile is the image's recipe instead of a playbook.

Where Ansible earns its place

Long-lived servers that cannot be replaced cheaply: databases, message brokers, the monitoring server. Patching, users and keys, config, rolling restarts.
Bootstrapping: the first minutes of a new machine - users, SSH hardening, the monitoring agent, joining it to whatever runs it next.
Building images: the same roles that configure a server configure the image.
Day-2 operations as code: rotate a certificate on 40 hosts, drain-restart-enable a fleet, collect a fact from everywhere ("which hosts still run kernel 6.x?"). A runbook step you can review and rerun.
Things without an API of their own: network devices, appliances, old systems reachable only by SSH.

And where it does not:

Owning resources another tool owns. If the provisioning tool created the load balancer, Ansible must not resize it - the next provisioning run would undo it, or worse, the two would disagree silently.
A scheduler for what an orchestrator already runs. Rolling out an application with Ansible while an orchestrator also deploys it means two owners for "which version runs".
Hand edits after Ansible. A file Ansible templates belongs to the template; the next run overwrites any hand edit. Put # {{ ansible_managed }} at the top and change the template instead.

The one rule behind all of it: every setting has exactly one owner, and everybody knows which.

Quick check

$ ansible-galaxy collection list amazon.aws

Does the ansible package ship modules that create cloud resources?

yes: collections such as amazon.aws are installed with it
no: Ansible only configures servers that already exist
only after ansible-galaxy collection install

Answer

yes: collections such as amazon.aws are installed with it - The ansible package bundles about 90 collections, cloud ones included. Being able to create resources does not make Ansible the right owner for them.

Running Ansible in a team

Running playbooks from a laptop works for one engineer and stops working for a team: whose vault password, whose version of the repo, where is the log? Teams move the runs to one place:

A job runner that checks out the repository at a reviewed commit and runs ansible-lint, then ansible-playbook --check --diff, then the real run - with the vault password injected from the runner's secret store and the log kept.
AWX (open source) or Red Hat Ansible Automation Platform: a web service that runs playbooks with stored credentials, schedules, role-based access ("support may run restart-app.yml on prod, not edit it") and a history of every run.
ansible-pull on a timer, for pull-style fleets: each host applies the latest commit to itself.

In an interview: "Ansible configures servers that exist - packages, users, files, services - and is great for long-lived VMs, bootstrapping, image builds and day-2 operations like rolling restarts. A provisioning tool owns creating the resources and keeps state; an orchestrator owns running the applications. The rule is one owner per setting: if two tools manage the same thing, they fight and drift."

The fleet goes away

This lesson ends the chapter's hands-on work: once every lab is done, opening it hands the lab fleet back (lb-1, web-1, web-2, db-1 are deleted), so the box stays small. Any lab you redo later builds the hosts it needs again.

What you can now do

Split a service into resources, OS, release and runtime, and name the right kind of tool for each.
Explain mutable vs immutable infrastructure, drift, and Ansible's role in each.
Say where Ansible is the right tool and where it would be a second owner.
Describe how teams run Ansible: a job runner, AWX / Automation Platform, ansible-pull.

Why it helps

Platform teams spend real effort deciding which tool owns what, and real outages come from two tools managing the same setting. This lesson gives you the layers to reason with (resources, operating system, release, runtime) and the mutable versus immutable trade-off, so you can explain where Ansible fits and where it should stop.

It is also how you answer the very common interview question "when would you use Ansible?", and how you run Ansible in a team: from a shared runner with logs, not from someone's laptop.

Commands in this lesson

ansible-galaxy

FAQ

What is the difference between mutable and immutable infrastructure?

Mutable servers live long and are changed in place: patched, reconfigured, upgraded. Their risk is drift. Immutable servers are never changed: a new version is a new image and new servers replace the old ones, so there is nothing to drift. Ansible manages mutable servers and can also build the images for immutable ones.

Where is Ansible the right tool?

Long-lived servers that cannot be replaced cheaply, such as databases and bastion hosts; bootstrapping new machines (users, SSH hardening, agents); building images; and day-2 operations as code: rotating a certificate on many hosts, rolling restarts, patching. Also devices with no API of their own, reached over SSH.

What happens when two tools manage the same thing?

They fight. Each run of one tool changes the setting back to its own value, and each run of the other changes it again. Nobody can tell which value is the truth, and the change history becomes noise. The fix is to choose one owner per setting and remove it from the other tool.

What is ansible-pull for?

It inverts the model: each host clones the playbook repository and applies it to itself, usually from a timer. It suits large fleets where a central control node cannot reach every host, or hosts that come and go. The usual push model stays simpler when you want a clear moment and a log of each change.

Why run Ansible from a shared runner instead of a laptop?

A shared runner, such as AWX or Red Hat Ansible Automation Platform, keeps the credentials, runs the same versions for everyone, enforces who may run what where, and keeps a log of every run. A laptop run leaves no shared history, and the laptop may hold the only copy of a key.

In an interview Junior

When would you use Ansible, and when would you not?

I use Ansible for Layer 2, configuration.: the operating system of servers that already exist, packages, users, files, services, and for ordered changes such as rolling restarts. It fits Long-lived servers, Bootstrapping new machines, Building images, and Day-2 operations as code. It keeps no state of its own; the host is the state. I would not use it to own what another tool owns: Layer 1, provisioning. belongs to a tool that keeps a state of the resources it created, and the runtime of applications to an orchestrator. The rule is that every setting has exactly one owner, otherwise tools fight and cause drift.

Also asked: What is configuration drift, and how do you detect it? · What is the difference between mutable and immutable infrastructure? · How would you run Ansible for a team rather than from your laptop?

Practise this lesson in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.