Introducing Puppet boilerplate modules

Andreas Haerter — Fri, 11 May 2012 02:27:00 +0200

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

Usage

Clone the repository:

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

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.

Example

Some resources to get an impression of what to expect:

An exemplary filezilla module which manages the FileZilla client on a node. It took ~ten minutes to create the whole module. 90% of the time was spent to write the README.
The documentation for the module, created with puppet doc --mode rdoc. Just unzip the archive and open index.html to view it.
Some screenshots of the module wizard (→ newmodule.sh):

Some explanatory notes

Each manifest file 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 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. the package list or some class calls.
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.

This blog post was created on 2012-05-11 at 02:27 by Andreas Haerter. It is tagged with planet-fedora, planet-puppet, puppet.

How to start with Puppet (system config management tool): useful links and resources

Andreas Haerter — Sun, 05 Feb 2012 18:25:00 +0200

Puppet is a¹⁾ powerful open source tool to automate the configuration of and software management on Unix-like²⁾ operating systems. This posting is a distillate of the resources I collected during my Puppet learning phase. I hope it helps to get an overview about what Puppet can do for you and how to use it (plus providing existing Puppet users some new ideas or tips).

Links

Selected slides and presentations (overview, use-cases, experts, tips)

blog.andreas-haerter.com - IT, web and nerdy stuff