15. When to use Ansible — and when not to

Ansible occupies a strange position in 2026. It is simultaneously the default answer in most organisations that have one, and widely believed to have been superseded. Both are true of different halves of the industry, and this chapter is about which half you are in.

The one question

Can you throw the machine away and build a new one?

If yes, do that. Immutable infrastructure — build an image, deploy it, never modify it, replace it to change it — eliminates drift completely rather than reducing it, and the Docker guide’s criticism that chapter 1 conceded is exactly right.

If no, you need configuration management, and Ansible is the best of them.

Most estates contain both kinds of machine, which is why most estates have both kinds of tool.

Where Ansible is clearly right

Machines that must persist. Database servers on real hardware. Storage nodes. Machines with local state that cannot be recreated in ninety seconds. The Kubernetes nodes themselves — somebody configures those, and it is not Kubernetes.

Network devices. Switches, routers, firewalls, load balancers. There is no container to build; the device runs what it runs. Ansible’s network_cli connection and the vendor collections manage Cisco, Juniper, Arista and dozens more from the same playbooks as your Linux fleet. For many network teams this is the entire reason Ansible is in the building, and no container-based approach addresses it at all.

Building the images everyone else deploys. Packer calls Ansible as a provisioner; the immutable-infrastructure workflow that replaces configuration management is very often implemented with configuration management. There is no contradiction here — running Ansible once at build time gives you both reproducibility and a readable description of what the image contains.

Anything with an SSH connection and nothing else. Air-gapped sites. Edge locations. A customer’s datacentre. Embedded systems. Hardware in a factory. Ansible’s requirements are so low that it works where nothing else is permitted to be installed.

Ad-hoc operations across a fleet. “Restart this service on the forty machines that have it.” “Tell me the kernel version everywhere.” This is genuinely useful, takes one line, and is far better than a shell loop because of host selection, parallelism, and a readable report at the end.

Orchestration across machines. The rolling deployment from chapter 11 — drain, update, verify, restore — is something Puppet and Chef structurally cannot express, because an agent waking on a timer has no way to coordinate with another machine.

Windows and Linux from one place. Few tools do both properly. Ansible does.

Where something else wins

Immutable images and containers

Use them wherever you can rebuild.

A container image is byte-identical every time it runs. There is no drift, because there is nothing to drift — the filesystem is replaced, not modified. Deployment is “start the new one, stop the old one”, and rollback is the same operation in reverse.

   ANSIBLE                        IMMUTABLE IMAGE

   converge toward a state        replace wholesale
   drift is reduced               drift is impossible
   rollback = run the old         rollback = deploy the
     playbook and hope              previous image
   "what is on this machine?"     "which image tag is it?"
     is a real question             is the whole answer
   minutes to converge            seconds to replace
   works on anything with SSH     needs a platform to run on

For stateless applications this is not close. If your workload can run in a container, run it in a container, and let Ansible’s role shrink to configuring the hosts that run the platform — which is still a real job.

Terraform

Different job, constantly confused. Terraform creates the machine, the network, the load balancer, the database instance. Ansible configures what is inside.

Terraform’s chapter 15 makes the same division from the other side and reaches the same conclusion, which is a reasonable sign it is right: Terraform for infrastructure, Ansible for configuration, and if you can, an image built beforehand so that neither has to do much. Ansible’s cloud modules work and lack a plan, a dependency graph, and real state tracking — Terraform’s state chapter explains what you are giving up.

Puppet and Chef

Use Puppet where continuous enforcement matters more than orchestration.

The pull model — an agent that wakes every thirty minutes and re-applies the catalogue — is genuinely better at one thing: a machine that drifts is corrected without anyone running anything. Ansible only enforces state when you run it, and a machine somebody edited at 3 a.m. stays edited until the next scheduled run.

   PULL (Puppet, Chef)            PUSH (Ansible)

   continuous enforcement         enforcement when you run
   scales to tens of thousands    control node is the limit
   agent must be installed        nothing to install
   a DSL to learn                 YAML
   no orchestration               ordering across machines
   reporting built in             build it yourself

Very large fleets favour pull, because a push model funnels everything through one control node, and a hundred thousand machines is a lot of SSH connections. AWX and Ansible Automation Platform address this with distributed execution nodes, and at that scale you are operating a platform rather than running a tool.

Salt

Use Salt if you need real-time execution across a very large fleet.

Its message bus makes fleet-wide commands return in seconds rather than minutes, and it does both push and pull. It is less widely known, which is a real cost in hiring and in finding answers, and its community is smaller. Technically it is a serious alternative and it is frequently dismissed without evaluation.

A shell script

Use a shell script for something genuinely one-off on one machine.

Ansible has a floor of effort — an inventory, a playbook, YAML syntax, a mental model. For “run this command on this server once”, ssh host 'command' is correct and reaching for Ansible is ceremony.

The line is repetition and audience. The moment it runs more than once, or on more than one machine, or by someone other than you, the playbook wins — because it is idempotent, reviewable, and self-documenting in a way a script is not.

Kubernetes

If the workload is already on Kubernetes, its own tools own the configuration. Deployments, ConfigMaps, operators and Argo CD do this job with continuous reconciliation, which is closer to Puppet’s model than to Ansible’s. Using Ansible to kubectl apply things is a step backwards from GitOps.

Ansible’s remaining role in a Kubernetes estate is real but bounded: configuring the nodes, bootstrapping the cluster, and managing the things around it that are not in it.

The comparison

	Ansible	Puppet/Chef	Terraform	Images
Model	push	pull	push	replace
Agent	none	required	none	n/a
Language	YAML	DSL	HCL	Dockerfile/Packer
Enforcement	when run	continuous	when run	at build
Orchestration	yes	no	limited	n/a
Creates infrastructure	poorly	no	yes	no
Configures machines	yes	yes	no	at build
Network devices	yes	limited	some	no
Windows	yes	yes	n/a	limited
Drift	reduced	corrected	in state	impossible
Very large fleets	control node limit	excellent	n/a	excellent
Learning curve	low	high	moderate	moderate

The decision

Ansible is right when you can say yes to most of these:

□ The machines persist — you cannot just rebuild them
□ You need ordering across machines, not just per-machine
  state
□ You want nothing installed on the targets
□ Network devices, Windows, or odd hardware are in scope
□ The fleet is hundreds or low thousands, not a hundred
  thousand
□ Running it on a schedule (or from CI on merge) is
  acceptable enforcement
□ Somebody other than its author has to read it

Three or more unchecked, look hard at the alternative. Persistent machines and cross-machine ordering are the two that matter most; without either, an image or a platform is probably the better answer.

The closing position

Ansible is the best available tool for making machines that must persist look the way you decided they should look, and for doing things to many machines in a specific order. For that, twelve years on, nothing has replaced it — and the reason is the same as it was in 2012: the requirement is SSH and Python, and everything already has both.

It has genuinely lost ground, and the ground it lost was fairly lost. Stateless applications belong in images. Cloud infrastructure belongs in Terraform. Kubernetes workloads belong to Kubernetes. Each of those took a slice of what configuration management used to do, and each is better at its slice.

What is left is not small: the machines underneath all of that, the network they sit on, the images they are built from, and every environment where a container platform is not available or not permitted.

The mistake is not choosing Ansible. The mistake is using it to simulate the things that replaced it — a playbook that builds a machine from bare metal to running application in four hundred tasks, run on every deploy, is an image build performed badly and slowly. Build the image with it once, and deploy the image.

And the second mistake, smaller but more common: writing programs in it. Chapters 7 and 8 warned about this from two directions. Ansible is a declarative tool with an escape hatch into procedural logic, and the escape hatch is there for the ten percent of cases that need it. A playbook with nested includes, recursive loops and forty conditionals has stopped being configuration and become a program in a language with no debugger, no types, and no tests. When you reach that point, write a module — or a program.

What to take from this chapter

• The question is: can you throw the machine away? If yes, use images. If no, use Ansible. Most estates have both kinds of machine.
• Ansible is clearly right for persistent machines, network devices, image building, air-gapped and edge environments, ad-hoc fleet operations, cross-machine orchestration, and mixed Windows/Linux estates.
• Immutable images beat it wherever you can rebuild — drift becomes impossible rather than merely reduced.
• Terraform creates, Ansible configures. Both guides reach this conclusion independently.
• Puppet’s pull model genuinely wins on continuous enforcement and very large fleets; Ansible wins on orchestration, which pull cannot express at all.
• Salt is a serious alternative for real-time execution at large scale, and is usually dismissed without evaluation.
• A shell script is right for one-off, one-machine work. The line is repetition and audience.
• On Kubernetes, its own tools and Argo CD own configuration. Ansible’s remaining job there is the nodes.
• Do not use Ansible to simulate an image build. Build the image with it once.
• Do not write programs in it. When you need loops inside conditionals inside includes, write a module.

One chapter left: the reference card.