Introducing Puppet boilerplate modules [Update]

My colleague and I are maintaining a “Puppet boilerplate modules” project (something like puppet module generate on steroids). To keep up with the OSS spirit, we thought it would be a good idea to share it with the community.

The project helps you to create high quality Puppet modules in a fast and comfortable way. Main goals are to boost efficiency and Puppet code quality. Use it if you want to get module skeletons with:

• tidy and easily extendable structure
• good README skeleton, RDoc documentation and license information
• source code which follows the official style guide
• parameterized classes
• an easy way to push your new modules to GitHub or Bitbucket
• module variable debugging functionality (some boilerplates online)

1. Clone the repository:

   $ git clone git://github.com/syn-systems/puppet-boilerplate-modules.git

2. Call the wizard to create the module skeleton for a new module:

   $ ./puppet-boilerplate-modules/newmodule.sh

   Hint: You can provide the answers by using parameters. Use newmodule.sh -h to get a parameter listing and usage instructions.

The puppet-boilerplate-modules-example-content repository is your friend if you need more help. It provides example modules including detailed creation transcripts.¹⁾

• The puppet-boilerplate-modules-example-content repository provides example modules and rendered²⁾ documentation (created with ). It should give you an impression of what to expect from and how to use puppet-boilerplate-modules and if the project might be useful for you.
• Some screenshots of the module wizard (→ newmodule.sh):

• Every boilerplate comes with different manifest files, each encapsulates the Puppet code for a specific job. This ensures a clean module structure. The name of the manifest should say what it does in general, the RDoc block at the top provides more details. Example: the application-002 boilerplate comes with the following files in /manifests:
  • init.pp
    Contains the main module class. It validates the module parameters and coordinates the actions (e.g. by chaining resources).
  • params.pp
    Sets the default values for the parameters of the main module class (→ init.pp) and manages internal module variables. Therefore, many operating system dependent differences like package names are addressed in here.
  • package.pp
    Coordinates all software package management related actions. Normally, there is no need to edit this file.
  • config.pp
    Coordinates all configuration related actions. Many modules won't need this because most there is no need for a special application configuration. If so, just delete the file and the references in init.pp.
  • repo.pp
    Coordinates all package repository related actions. Many modules won't need this because an additional repository is not needed to install the application. If so, just delete the file and the references in init.pp.
• Everything you must edit/check after you generated a module is marked with a FIXME/TODO. E.g. when the package list or some class calls when using the application-002 boilerplate.
• You don't need to use GitHub/Bitbucket. The DVCS repository hosting part of the wizard is completely optional.
• There is always room for improvement. If you're able to add any contributions to make our project better, please let me know or discuss your thoughts right here in the comments.

Update 2012-05-30: I changed the links and text regarding the new puppet example content.