Don't Panic: Puppet Fundamentals

Puppet manages configuration with a healthy dislike of remembering every command somebody typed last Tuesday. It records the state a machine should have: a package installed, a file present, a service enabled and running. The agent checks later and changes what differs. This replaces a setup-command pile with policy that can notice drift after the setup party has gone home.

The important object is the resource, one manageable thing with a type, title, attributes, and desired values. Resources are not an unstructured shopping list. Their relationships form a catalog, a node-specific graph that says what must exist and what must happen first. A package can precede its configuration file, which can notify a service to restart. The graph is why Puppet can skip a dependent resource after a prerequisite fails while unrelated work continues.

A manifest is source code. The catalog is its result after Puppet combines modules, classification, facts, and Hiera data for one node. This saves many confused afternoons: two nodes can use the same module and still receive different catalogs because their facts or data differ. puppet apply uses the same model locally. In an agent-server deployment, a server compiles and delivers the catalog.

The recurring loop has a formal name, convergence, but its behavior is reassuringly dull. Run unchanged policy twice and the second run should make no unnecessary changes. That is idempotency. If something keeps changing, the machine and policy are having an argument that needs investigation, not a ceremonial restart.

Read Intro for the catalog and agent flow. Use Slides for the graph and safe change path. Keep Cheatsheet nearby for resource types, relationships, facts, and lookup commands. The Practice reference turns the theory into a local catalog that manages temporary files. The Quiz checks whether the graph and loop have landed in the correct compartments. They are stubborn concepts, but useful stubborn concepts.