Ansible vs Terraform

Ansible and Terraform are framed as competitors constantly, and they are not. They operate at different layers, and the strongest stacks run both: Terraform provisions the infrastructure — the VM, the network, the load balancer — and remembers it in state; Ansible configures what runs inside that infrastructure and keeps no state at all. The two are partners across a boundary, not alternatives to choose between.

Getting that boundary right is the difference between a clean pipeline and one tool bent painfully into the other's job. This topic draws the line precisely, because almost every real argument about "Ansible or Terraform" is actually a question about which layer you are standing on at that moment.

Two Different Questions

Terraform answers a question about existence: what infrastructure should be there? Given that declaration it will create the servers, networks, and load balancers, and — just as importantly — destroy them when you remove them from the config. Bringing infrastructure into being and tearing it down is its entire job.

Ansible answers a question about configuration: how should this machine, which already exists, be set up? Given a host it will install packages, render templates, write files, and restart services. It has no concept of destroying a server, because creating one was never in its remit. The two questions look adjacent but they belong to different tools, and conflating them is the root of most pipeline pain.

State vs No State

Terraform's state file is both its power and its burden. It maps every line of config to a real resource, which is exactly what lets Terraform know that deleting a block means destroying a specific load balancer rather than guessing. That memory has to be stored, locked against concurrent runs, protected, and kept honest with reality — and when it drifts or corrupts, recovery is real work.

Ansible deliberately has no state file, and this is the spine of the whole course: the managed node is the record. Every run gathers the machine's current facts and reconciles them against your declared state, live. The upside is simplicity — nothing to lock, corrupt, or check into git by accident. The limit is the flip side of Terraform's strength: with no memory of what it created, Ansible cannot clean up what it no longer manages. Remove a task and Ansible simply stops touching that thing; it never knew it owned it.

Declarative Graph vs Ordered Tasks

Terraform builds a dependency graph of resources and converges it. You declare that a subnet needs a VPC and an instance needs that subnet, and Terraform works out the order, parallelizing what it can. You describe the end state of the infrastructure; the planner figures out the sequence. There is no natural notion of "do this step, wait, then do that one" — the graph just resolves.

Ansible runs an ordered list of tasks, top to bottom, across the hosts you target. That ordering is exactly why orchestration is natural in Ansible and awkward in Terraform: a rolling deploy is "drain this host, update it, health-check it, then move to the next," and that is a sequence, not a graph. The mismatch runs both ways — forcing a dependency graph into an ordered task list is as painful as forcing an ordered deploy into a convergence engine.

The Handoff

The two tools meet at a clean seam. Terraform builds the fleet and emits outputs — the IP addresses and hostnames of what it just created. Those outputs feed Ansible's inventory, so the machines Terraform stood up are precisely the machines Ansible configures. The canonical pipeline is two commands in order: terraform apply to build, then ansible-playbook to configure.

The clean way to wire that seam is dynamic inventory rather than copied IP addresses. Ansible reads the same cloud (or Terraform's state) that Terraform wrote, so a rebuilt fleet reconfigures itself with no hand-edited host list to drift. A later chapter builds this handoff in full; for now the shape is what matters — Terraform's output is Ansible's input, and the boundary between them is a feature.

# Terraform: stand up the web tier and expose its addresses
output "web_public_ips" {
  value = aws_instance.web[*].public_ip
}

# Ansible: aws_ec2.yml reads the live cloud, no copied IPs
plugin: amazon.aws.aws_ec2
filters:
  tag:Project: larkspur
keyed_groups:
  - key: tags.Role      # a Role=web tag becomes the `web` group

The Terraform block names the addresses it built; the Ansible plugin config asks the same cloud which hosts exist and groups them by tag. Neither side copies anything from the other by hand — the cloud is the shared source of truth, and the fleet can be destroyed and rebuilt without anyone editing an inventory.

When People Force One to Do Both

The anti-pattern this topic exists to prevent has two symmetrical forms. The first is using Terraform's provisioner "remote-exec" or local-exec to configure a box — run a shell script at create time to install software. These run once, are not idempotent, and HashiCorp itself documents them as a last resort; they turn Terraform into a worse Ansible.

The second is driving cloud infrastructure lifecycle from Ansible's cloud modules and expecting Terraform-style cleanup. Ansible can call cloud APIs to create a VM, but with no state it has no idea what to destroy when you delete the task — you get creation without a lifecycle. The rule is simple and it ends the argument: if a thing has a lifecycle to create and destroy, Terraform owns it; if it is software and config on a host that already exists, Ansible owns it.