What Ansible Is & Why It's Different From Terraform

Ansible

Chapter 1 · What Ansible Is & Why It's Different From Terraform

tf1-1 named Ansible directly, back at the start of the Terraform course: "still on this site's own bucket list." cloud1-11 named the real lesson behind configuration drift as "fix the config, not just the console," without yet having the tool to act on it. This course is both of those promises, paid off.

Two Different Jobs — Provisioning vs. Configuration Management

tf1-1 already drew this line precisely: Terraform provisions infrastructure — it creates the VM, the network, the database instance. It has no concept of "log in and install a package." Ansible configures infrastructure that already exists — installing software, editing config files, restarting services, on machines Terraform (or something else) has already brought into being. A real pipeline commonly runs Terraform first, to create the servers, then Ansible, to configure them — complementary tools, not competing ones, exactly as tf1-1 already put it.

Agentless — Ansible's Own Defining Architectural Choice

Older configuration management tools — Puppet, Chef — work by installing a persistent agent on every managed node: a daemon that runs continuously, periodically checking in with a central server. Ansible takes a deliberately different approach: it's agentless. It connects over plain SSH (or WinRM for Windows), pushes a small amount of code to the target, runs it, and cleans up — nothing persistent left running on the managed host afterward. A new server can be managed the moment it has SSH access; there's no separate bootstrap step to install an agent first.

	Architecture	Getting a new host managed
Ansible	Agentless — connects over SSH, runs, disconnects	Just needs SSH access + Python
Puppet / Chef	Agent-based — a persistent daemon runs on every node	Requires installing and registering the agent first

Push, Not Pull — A Real Contrast With Kubernetes and Prometheus

obs1-3 described Prometheus's own pull model — the monitoring system reaches out on its own schedule. Ansible is the reverse: push-based. A human, or a CI pipeline, explicitly runs a playbook against a set of target hosts, at a moment they choose. Ansible doesn't sit in the background continuously reconciling state the way k8s1-2's own reconciliation loop does — nothing changes on a managed host until a playbook is actually run against it. This is a genuine, important architectural difference between tools that all get grouped loosely under "infrastructure as code" — one worth keeping in mind now, since ansible1-4 revisits it directly once idempotency is on the table.

"Fix the Config, Not Just the Console" — Delivering on cloud1-11's Own Lesson

cloud1-11 named the real discipline behind avoiding configuration drift: change the source-controlled configuration, not the live server directly through a console or an ad-hoc SSH session that leaves no record and gets silently overwritten the next time anything reapplies the "real" config. Ansible is the concrete tool built to apply exactly that discipline to server configuration specifically — the piece Terraform, by its own design, never touches once a server already exists.

Where This Course Is Headed

Inventory, playbooks and modules, variables and Jinja2 templates, real idempotency testing, roles, Vault for secrets, dynamic inventory, and testing with Molecule — building, chapter by chapter, toward a genuine capstone: turning ws1's own hand-run Debian web-server hardening course (HTTPS, UFW, fail2ban, SSH hardening, Apache security headers) into one real, idempotent, version-controlled playbook. The exact discipline this chapter just named, made concrete against content already on this site.

Ansible ships "batteries included"

A huge library of built-in modules covers practically every common task out of the box — package management, service control, file operations, user management, and modules for every major cloud provider's own API. Custom scripting is the exception, not the starting point.

Agentless doesn't mean effortless

"No agent to install" doesn't mean "zero setup" — it means a different, usually smaller kind of setup. SSH key management, a working network path to every target, and a Python interpreter available on the managed host are all real prerequisites Ansible still depends on, even without a persistent daemon of its own.

Hands-On Exercises

Exercise 1

A team already uses Terraform to provision their servers. Explain, in your own words, what Ansible would add to their pipeline that Terraform structurally cannot do on its own.

📄 View solution

Exercise 2

Explain why a newly provisioned server can be managed by Ansible the moment it has SSH access, but would need an extra setup step before Puppet or Chef could manage it.

📄 View solution

Exercise 3

Explain, using cloud1-11's own "fix the config, not just the console" lesson, why manually SSHing into a server to fix a problem is a worse long-term practice than fixing the same problem in an Ansible playbook, even though both approaches solve the immediate issue.

📄 View solution

Chapter 1 Quick Reference

Terraform provisions infrastructure; Ansible configures infrastructure that already exists — complementary, not competing
Agentless — Ansible connects over SSH, runs, and leaves nothing persistent behind, unlike agent-based tools like Puppet/Chef
Push, not pull — a playbook only changes anything when it's explicitly run, unlike Kubernetes' own continuous reconciliation loop or Prometheus's own scheduled scraping
Ansible is the concrete tool behind cloud1-11's own "fix the config, not just the console" discipline
This course builds toward a capstone automating ws1's own hand-run Debian hardening course into a real playbook
Agentless still has real prerequisites — SSH access, network reachability, a Python interpreter on the target