Write component modules with intent and reusability

Component modules are designed to be focused on a single component, shared, collaborated on, and improved.

Version and installation information

Puppet version: Any
Installation type: All

Solution

Let’s start with some module fundamentals. You’ll keep nearly all of your Puppet code for a specific component in a module for that component. The component module should be designed as a reusable building block that can be easily shared.

Note: Keep your site-specific data out of your component modules. You should think of a component module as something you would want to share with others. Customization is done on another abstraction layer, the profile layer.

A module should manage one and only one component, and manage that component entirely. A module should reference other component modules when the module needs to perform an action outside of the scope of the component being managed. For example, the puppetlabs-puppetdb module would manage the package, file, and service to configure puppetdb, but it would not manage the firewall rules. The puppetlabs-puppetdb module would instead leverage the functionality of the puppetlabs-firewall module to make the iptables changes, and the puppetlabs-postgresql to manage the postgresql component.

Many common components already have a module available, make sure to check out The Puppet Forge before writing your own module. In most cases, pull requests are welcome if you need to update the module to support a newer OS or add in missing component functionality. The Puppet Community is strong and constantly contributing back to the module base. We hope that you do too.

Helpful reading to get started

• Welcome to Puppet Modules

• Puppet Development Kit (PDK)

• Module fundamentals

• Beginner’s guide to writing modules

• Module cheat sheet

• The modulepath

• Documenting modules

• Plug-ins in modules

• The Puppet Forge

• Publishing Modules

• Puppet Code

  • Classes
  • Defined types