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.

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.

Hands-On Exercises

ansible1-1 established that Ansible is agentless. This chapter makes that concrete — installing it, running your first commands, and writing the smallest playbook that actually does something.

The Control Node — Where Ansible Actually Runs

Ansible itself is installed on exactly one machine — the control node — not on every host it manages. This is ansible1-1's agentless architecture made literal: there's no Ansible software running on a managed host at all, only on the control node that initiates outbound SSH connections. Installation is typically pip install ansible, and works natively on Linux and macOS; on Windows, the control node itself normally runs inside WSL — Ansible can still manage Windows hosts via WinRM, it just doesn't run natively as a control node on Windows.

Ad-Hoc Commands — Ansible Without a Playbook

-m specifies a module to run — ping here is a built-in connectivity-check module, worth distinguishing explicitly from ICMP ping: it confirms Ansible can connect over SSH and that Python is reachable and working on the target, not just that the host responds to a network ping. -a passes arguments to the default command module when no -m is given. Ad-hoc commands are genuinely useful for quick, one-off checks or actions — they don't give you repeatability or a record of what changed, which is exactly what a playbook is for.

Your First Playbook

A playbook is a list of plays; each play targets a group of hosts (from the inventory ansible1-3 covers fully) and contains a list of tasks. Each task calls exactly one module — apt, service — with specific arguments describing the desired state, not a literal command to run. become: true is Ansible's privilege-escalation flag, the equivalent of running with sudo.

Running a Playbook

Each task reports one of three outcomes per host — ok (already in the desired state, nothing to do), changed (something was actually modified), or failed — followed by a PLAY RECAP summarizing every host's own results at the end of the run.

ansible.cfg — Configuring Ansible's Own Defaults

ansible.cfg sets defaults — inventory path, default remote user, SSH behavior — so they don't need to be passed as flags on every single command. host_key_checking = False is a common development-convenience setting, worth flagging directly rather than copying blindly (see the warn-box below).

Hands-On Exercises

ansible1-2 used -i inventory in every command without explaining what that file actually was. This chapter delivers — the inventory is Ansible's own list of hosts, and how it's organized shapes everything else in this course.

What an Inventory Actually Is

A plain-text file listing the hosts Ansible can manage, optionally organized into named groups. Two common formats: INI-style — simple, classic — and YAML, more structured and consistent with every other Ansible file this course writes.

INI-Style Inventory

Bracketed headers define groups; hosts listed underneath belong to that group. The :vars suffix attaches variables to every host in that group at once — http_port here applies to both web1 and web2 without repeating it per host.

YAML-Style Inventory

The exact same inventory, expressed as YAML — more verbose for a trivial case like this one, but it scales far better once groups nest deeply or carry many variables, and it keeps every file in an Ansible project speaking the same syntax.

Groups of Groups — Nested Groups

A group can itself be composed of other groups. production here contains every host in both webservers and dbservers — a play targeting hosts: production reaches all of them at once, without listing each individual group.

Host Variables and Group Variables

Inline :vars works, but group_vars/ and host_vars/ directories are the cleaner, more common approach at any real scale — one YAML file per host or group, automatically loaded by Ansible based on the filename matching the group or host name exactly:

No explicit reference to these files is needed anywhere — Ansible loads group_vars/webservers.yml automatically for any host in the webservers group, purely by matching the filename.

Special Built-In Groups

• all — every host in the inventory, always implicitly available, no matter how groups are defined
• ungrouped — any host not explicitly placed into a named group

Hands-On Exercises

ansible1-2 showed a minimal playbook without explaining what actually makes it safe to run more than once. This chapter is where that gets explained properly — modules as the real unit of work, and idempotency, the principle everything else in this course assumes.

Modules — The Atomic Unit of Work

Every task calls exactly one module — a small, self-contained unit of code Ansible pushes to the target, executes, and receives a structured result back from. ansible1-1's own "batteries included" claim is concrete here: modules exist for package management (apt, yum, dnf), files (copy, template, file), services (service, systemd), users, and practically every major cloud provider's own API. Critically, a module describes desired state — state: present, state: started — not a literal command to execute. That single design choice is the foundation idempotency is built on.

Idempotency — The Central Design Principle

An idempotent operation produces the same end result no matter how many times it's applied. Run a playbook once, and the system converges toward the desired state. Run the exact same playbook again immediately afterward, and nothing should change — every task reports ok, not changed, because the state it describes already exists. Contrast this with a naive imperative script doing echo "some line" >> config_file — run twice, and the line appears twice. Modules like lineinfile/blockinfile exist specifically to make this kind of edit idempotent: they check the file's current content first, and only make a change if the desired line genuinely isn't already there.

Ansible's Idempotency vs. Kubernetes' Continuous Reconciliation

ansible1-1 promised this contrast directly. k8s1-2's own reconciliation loop continuously observes actual state and corrects drift automatically, all the time, without anyone triggering it. Ansible's idempotency is a genuinely different kind of guarantee: a playbook, when run, converges the target toward the desired state — but nothing happens between runs. If something drifts an hour after a playbook finishes, Ansible does nothing about it until that playbook is explicitly run again. Idempotent design makes repeated runs safe and convergent; it does not provide continuous enforcement the way Kubernetes' reconciliation loop does. Neither is universally better — Kubernetes needs continuous self-healing for a live running system; Ansible is typically run on a schedule or on demand, for configuration management specifically.

Task Structure In Depth

name is a human-readable label shown in the run output — always name every task, so a real run's output actually tells you which step did what. loop runs the task once per item in a list, with {{ item }} substituting the current value each time. Other common task-level keywords: when (conditionally skip a task), register (capture a task's own result into a variable for a later task to use), and tags (run only a selected subset of tasks on a given invocation).

A Non-Idempotent Trap — the command/shell Modules

command and shell run arbitrary commands directly — a genuinely useful escape hatch when no dedicated module exists for a specific task. They are not idempotent by default, though: a shell command that unconditionally does something (appends to a file, restarts a service every time) reports changed on every single run, even when nothing meaningful actually needed to change. The fix is explicit: the creates/removes arguments tell Ansible to only run the command if a given file doesn't (or does) already exist, and changed_when: false lets a task explicitly declare its own changed status, restoring honest, idempotent-style reporting even while using this lower-level tool.

Hands-On Exercises

ansible1-3's own warn-box promised this chapter would cover variable precedence properly. It also used {{ item }} and {{ variable | default(...) }} without ever naming what that syntax actually is. Both get resolved here — along with the exact templating mechanism this course's own capstone uses to generate real config files.

Variable Precedence — Resolving Chapter 3's Own Promise

Ansible's real, official precedence order has over twenty distinct levels — more detail than is useful for getting started. The practical version most real playbooks actually need, lowest to highest:

1. Role defaults (defaults/main.yml) — the lowest priority, meant to be overridden
2. Inventory variables (group_vars, host_vars, from ansible1-3)
3. Playbook variables (a play's own vars: block)
4. Task-level variables / set_fact
5. Extra vars (-e on the command line) — always wins, no exceptions

A variable set at a higher level on this list always overrides the same variable set at a lower one. -e on the command line is the deliberate escape hatch for "just this one run, use this value, regardless of everything else" — and it always gets the final word.

Facts — Data Ansible Gathers For You

At the start of a play, Ansible automatically gathers facts about each managed host — operating system, IP addresses, memory, CPU count, hostname — unless explicitly disabled. These are available as {{ ansible_facts.xxx }}, or common ones via a shorthand like {{ ansible_distribution }} and {{ ansible_distribution_version }}.

Facts are what make a single playbook safely reusable across genuinely different hosts — the capstone's own target, Debian specifically, is exactly the kind of thing a when: condition on ansible_os_family would check for.

Jinja2 — Ansible's Templating Language

Every {{ }} used since ansible1-2 — variable substitution in a task's arguments, {{ item }} in a loop — is Jinja2, not special Ansible-only syntax. Jinja2 also supports filters: {{ variable | default('fallback') }} provides a safe fallback value when a variable might not be defined, avoiding an "undefined variable" error outright — exactly the pattern used unexplained in ansible1-4's own exercise solutions.

The template Module — Templating Real Config Files

copy transfers a file byte-for-byte, unchanged. template processes a file through Jinja2 first — substituting variables, evaluating conditionals and loops — then copies the resulting, fully rendered output.

This is exactly the mechanism ansible1-10's own capstone uses to generate real Apache vhost and security-header configuration for ws1's own hardening course — a template file, rendered per-host, replacing what was originally typed by hand.

Conditionals and Loops Inside a Template

{% if %}/{% endif %} and {% for %}/{% endfor %} are Jinja2's own template-level conditionals and loops — distinct from the when: and loop: task keywords, which control whether/how a whole task runs, not what appears inside a rendered file. A list of security headers, each with its own name and value, rendered this way is exactly the shape of content ws1's own security-headers chapter covered by hand — now generated.

Hands-On Exercises

ansible1-5 used notify: restart nginx without explaining it. This chapter closes that gap — and goes further, turning idempotency from something ansible1-4 merely asserted into something you can actually prove, by running a playbook twice and reading the result honestly.

Handlers — Explaining notify:

A handler is a special task that only runs if something notify-ed it, and runs at most once per play, no matter how many tasks notified it. ansible1-5's own template task — notify: restart nginx — only actually triggers this handler when the template task itself reports changed. If the config file was already correct, the task reports ok, and the handler never fires at all. This is ansible1-4's idempotency principle paying off directly: a service restart happens exactly when something genuinely changed, never as a matter of routine.

Why Handlers Run at the End

Handlers run after every regular task in the play has completed, not the moment they're notified. If five separate tasks all notify the same handler during one run, it still only fires once, at the very end — avoiding five redundant restarts when a single one is enough. For the rare case where an action genuinely needs to happen immediately, mid-play, rather than deferred — meta: flush_handlers exists as an explicit escape hatch, worth knowing exists even if it's rarely needed.

changed vs. ok — Reading Ansible's Own Report Honestly

ansible1-2 already showed the report format — each task is ok, changed, or failed per host. Put together with ansible1-4's idempotency principle, this gives a concrete, checkable claim: a healthy second run of an idempotent playbook should report changed=0 in the PLAY RECAP. Not "probably nothing changed" — a specific, verifiable number.

Real Idempotency Testing — Running a Playbook Twice

This is the actual practice, not just a claim to trust: run the playbook once, expect real changes on a fresh host. Run it again, immediately, with nothing else touched. If the second run reports anything other than changed=0, that's a genuine bug somewhere in the playbook — most often ansible1-4's own command/shell trap, a task quietly doing something every single run regardless of whether it needed to.

A Concrete Idempotency Bug, Caught by This Test

Recall ansible1-4's own unfixed example — shell: "systemctl restart myapp", no changed_when. Before the fix, running this idempotency test would show changed=1 on every single run, second run included, no matter how many times it's repeated — the exact symptom that reveals the bug. After the fix (a when:/changed_when: tied to whether the config genuinely changed), a clean second run correctly reports changed=0. The fix from that chapter and the verification practice from this one are the same discipline, applied at two different points.

Hands-On Exercises

Everything so far — tasks, handlers, variables, templates — has lived in one or two files. That works for a small example; it doesn't scale. This chapter is Ansible's real answer: roles, a standard way to package each concern into its own self-contained, reusable unit.

The Problem — One Big Playbook Doesn't Scale

As a playbook grows — more tasks, more handlers, more variables, more templates, all covering genuinely different concerns — it becomes hard to reuse any single piece elsewhere, and hard to find anything in a file that keeps growing. Roles solve this by giving each concern its own directory, structured the same predictable way every time.

The Role Directory Structure

• tasks/main.yml — the role's own task list, loaded automatically by convention, no explicit reference needed anywhere
• handlers/main.yml — handlers scoped to this role, working exactly as ansible1-6 described
• templates/ — .j2 files, referenced by relative filename from the role's own tasks
• defaults/main.yml — deliberately the lowest-precedence variables per ansible1-5's own order, meant to be overridden by whoever uses the role
• vars/main.yml — higher-precedence variables, meant to stay more fixed, internal to the role's own logic
• files/ — static files for a plain copy task
• meta/main.yml — role metadata, including dependencies on other roles

Using a Role in a Playbook

Every task in every listed role runs, in order, before any play-level tasks. For finer control over ordering — interleaving a role's tasks with ordinary tasks at a specific point — include_role does the same job from inside a normal tasks: list:

Ansible Galaxy — A Registry of Shared Roles

ansible-galaxy install <role> pulls a pre-built, community-maintained role from the public Galaxy registry — the same "why reinvent this" idea as tf1-7's own public Terraform Registry. ansible-galaxy init <rolename> scaffolds the entire directory structure above automatically, so the exact folder names never need to be memorized or typed by hand.

DRY Configuration — Why This Actually Matters Here

Without roles, the capstone's own real target — ws1's HTTPS/Let's Encrypt setup, UFW, fail2ban, SSH hardening, and Apache security headers — would all have to live crammed into one sprawling playbook. With roles, each of those concerns becomes its own independently testable, independently reusable unit. This directly foreshadows how ansible1-10's own capstone is actually structured: one role per ws1 concern, not one giant file.

Hands-On Exercises

ansible1-7 gave every concern its own tidy, version-controlled home. But roles and playbooks are naturally full of exactly the values pipelines1-5 and crypto1-11 both already warned about — database passwords, API keys, private keys. This chapter is the mechanism that lets those values live in version control safely, following the rule those earlier chapters already established.

The Problem — Roles and Playbooks Are Full of Secrets

Database passwords, API keys, TLS private keys — all naturally want to live as ordinary Ansible variables, in exactly the same files ansible1-7 just organized. But pipelines1-5's own rule stands regardless of which tool is committing the file: a credential committed to git in plaintext is compromised forever, even if it's later removed, since git history retains it. Ansible Vault is the tool for encrypting exactly these values, so they can live safely in version control alongside everything else — encrypted, not absent.

Encrypting a Whole File

edit never writes the plaintext to disk at any point during the process — it decrypts into memory, opens your editor, and re-encrypts on save. An encrypted file on disk looks genuinely unreadable:

Safe to commit, safe to diff (though the diff itself is meaningless without the password), and structurally no different from any other file in the repository.

Encrypting a Single Variable — encrypt_string

This produces a small, self-contained encrypted block that can be pasted directly into an otherwise-plaintext vars file. Often preferable to encrypting the whole file: the rest of the file — variable names, structure, non-sensitive values — stays readable in a normal diff, with only the genuinely sensitive value itself hidden.

Providing the Vault Password to Run a Playbook

--ask-vault-pass prompts interactively; --vault-password-file points at a file (or an executable script that outputs the password) — the practical option for CI, where nothing can be typed interactively. Running a playbook that references encrypted variables without supplying the password fails cleanly, with a clear error — not a silent, wrong value quietly used instead.

Vault IDs — Multiple Passwords for Multiple Environments

A light touch, worth naming: vault IDs let genuinely different environments use genuinely different vault passwords. Someone who only has the dev password structurally cannot decrypt production secrets — a real, meaningful security boundary between environments, not just a naming convention.

Directly Extending pipelines1-5/crypto1-11's Own Rule

pipelines1-5 named "a committed credential is compromised forever" as the reason never to commit secrets in plaintext; crypto1-11 covered key management practice more broadly. Ansible Vault is the concrete mechanism that lets Ansible-managed secrets follow that exact rule while still living in version control the same way everything else in this course does — ansible1-7's own roles, and the same discipline tf1's own state-file material already applied to Terraform's own sensitive values.

Hands-On Exercises

Two remaining practical topics before the capstone: keeping an inventory accurate automatically, and actually testing a role rather than trusting it by inspection. Both echo themes this course has already built toward — obs1-3/obs1-10's own static-vs-dynamic discovery material, applied here to hosts, and ansible1-6's own manual idempotency-testing habit, automated.

The Problem With Static Inventory at Real Scale

ansible1-3's static INI/YAML inventory is fine for a small, stable set of hosts. It breaks down the exact same way obs1-3's own static Prometheus scrape configuration did: cloud instances autoscale, get replaced, get new IPs — a hand-maintained inventory file quietly goes stale, listing hosts that no longer exist and missing ones that do.

Dynamic Inventory — Querying the Source of Truth Directly

A dynamic inventory is a plugin that queries a live source — a cloud provider's API, a Kubernetes cluster — at run time, generating the inventory on the fly instead of reading a static file. aws_ec2.yml above isn't a host list; it's a plugin configuration:

This generates groups automatically from the cloud provider's own tags — any EC2 instance tagged Role=webserver lands in a role_webserver group automatically, no one maintaining that membership by hand. This is genuinely the same idea as obs1-10's own ServiceMonitor label-matching — declare what to select, let the platform's own live state populate the result — just applied to hosts instead of scrape targets.

Kubernetes as a Dynamic Inventory Source

The kubernetes.core.k8s inventory plugin generates an inventory directly from pods or services running in a cluster, pairing directly with obs1-10's own Kubernetes material — the same "don't hand-maintain a list of things that are inherently ephemeral" lesson, applied one layer further.

Testing Ansible with Molecule

ft1-1's own principle — test behavior, not implementation — applies here too. Molecule is the standard tool for testing Ansible roles: it spins up an isolated test instance (commonly via Docker), applies the role, and runs verification checks, all automatically, with no real staging server required.

molecule init role scaffolds a testable role with its own molecule/ directory — converge.yml applies the role under test, verify.yml checks the result. molecule test runs the full cycle automatically: create a test instance → converge (apply the role) → an idempotence check → verify → destroy.

Molecule's Idempotence Check — Automating Chapter 6's Own Practice

ansible1-6 taught running a playbook twice by hand and checking for changed=0. Molecule's own idempotence step in molecule test does exactly this, automatically — applying the role a second time and failing the test outright if anything reports changed. The same discipline from that chapter, now a real, repeatable, CI-runnable check rather than a manual habit someone has to remember to perform.

Hands-On Exercises

The final chapter. ws1's own web-server hardening course was built entirely by hand — typing commands over SSH, editing files directly. This capstone turns five of its eight chapters into one real, idempotent, version-controlled Ansible project — the exact "fix the config, not just the console" discipline ansible1-1 opened this whole course with, finally made concrete.

The Target — ws1's Own Hardening Course, Automated

Five of ws1's eight chapters, each becoming its own role, per ansible1-7's own DRY principle: HTTPS via Let's Encrypt, firewall via UFW, fail2ban, SSH hardening, and Apache security headers.

Role 1 — firewall (UFW)

Role 2 — ssh_hardening

lineinfile — ansible1-4's own example of a genuinely idempotent edit, checking the file's current content before deciding whether to change anything.

Role 3 — https (Let's Encrypt)

certbot is invoked via command, since no dedicated module covers this exact flow — but the creates argument is ansible1-4's own fix for command/shell's non-idempotency trap, applied for real: the task only actually runs if the certificate doesn't already exist.

Role 4 — fail2ban

ansible1-5's own template module, doing exactly what it was introduced to do — rendering a real config file per host, with ansible1-6's own handler restarting the service only when that file genuinely changed.

Role 5 — security_headers (Apache)

ansible1-5's own {% for %} loop example, no longer a teaching snippet — this is the actual mechanism generating ws1's own Apache security-header configuration, driven by a plain, editable list of headers rather than typed by hand into a config file.

Secrets — Vault-Protecting admin_email and Anything Sensitive

ansible1-8's own encrypt_string, applied to admin_email (and any API token a real deployment might also need) — the rest of the vars file stays fully readable, only the sensitive value itself is hidden.

Verifying Idempotency — Running the Whole Playbook Twice

ansible1-6's own practice, applied to the whole capstone: changed=0 on the second run is the actual proof this playbook is safe to re-run on a schedule, as a real, ongoing defense against configuration drift — not a claim taken on faith.

Hands-On Exercises