Modules & the Forge

Reusable, shareable units.

Intermediate12 min · lesson 8 of 12

A module is Puppet’s unit of packaging and reuse: a directory with a standard layout — manifests/, templates/, files/, data/ (Hiera), lib/ (custom facts/types) — containing everything for one piece of functionality. Your own code lives in modules, and you consume community modules from the Puppet Forge, the public registry, installed with the puppet module tool or a Puppetfile.

Puppetfile

forge 'https://forge.puppet.com'
mod 'puppetlabs-stdlib',  '9.4.1'      # pin versions
mod 'puppetlabs-apache',  '11.1.0'
mod 'puppetlabs-firewall','8.1.0'
# r10k or the module tool installs the exact set

Structure and quality

The standard layout matters because tooling relies on it — autoloading finds nginx::vhost at modules/nginx/manifests/vhost.pp by convention. Quality modules ship metadata (supported OSes, dependencies), documentation, and tests. Puppet Development Kit (pdk) scaffolds and validates modules, and puppet-lint enforces style. As always, treat a Forge module as a dependency that runs privileged code on your nodes.

terminal

$ pdk new module acme_web        # scaffold a module with the standard layout
$ pdk validate                   # lint + syntax + metadata checks
$ puppet module install puppetlabs-apache --version 11.1.0

Forge modules run as root — pin and vet them

A module from the Forge executes with full privilege during catalog apply, so an unpinned or unvetted module is a supply-chain risk like any dependency. Pin versions in the Puppetfile, review what a module does (especially exec resources and custom providers) before adopting it, and prefer Puppet-approved/partner modules. The pull model applies these everywhere automatically.

Templates (EPP/ERB)Hiera & encrypted data