Dynamic Inventory & Testing with Molecule

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