In Puppet parlance, a module is a collection of manifests (including classes and definitions), templates, and files which, taken together, describe a recipe for configuring something via Puppet. Puppet has a number of facilities which make modules incredibly useful and labor-saving.
Modules have a standard internal organization which is described in detail on the ModuleOrganisation wiki page. A trivial module can be as simple as a manifests directory containing only a single manifest: init.pp. However, as modules grow more complex, you’ll want to break up your manifests and add templates in a templates directory, files in a files directory, and a README file which explains how to make use of your module.
I’m in the process of polishing up several modules, including LDAP, Kerberos, memcached, and ntp modules. In some ways, I’m duplicating work; several implementations of these modules are available. However, Puppet modules are still evolving, and I wanted to try my hand at module writing. Also, the existing modules did not work quite right for us. Some of them fail to properly isolate site-specific information from the recipe, for example. Others had complex interdependencies that I didn’t like.
There are several techniques that I think will evolve as “best practices” for Puppet module design. These are:
- Keep site-specific customization out of your modules.
- Your module should implement a minimal working configuration “out of the box”.
- Use variables to make it easier to patch your module for use on other platforms.
- Break a module up into sensible classes and defined types to make it easy to customize via inheritance.
- Use init.pp for module-wide variables and/or common functionality, but break all other classes/defines into separate files.
Let’s take a look at each of these in detail:
Keep site-specific customization out of your modules.
Modules are, at heart, meant to be shared with others. Try to write your modules so they are as site-neutral as they can be. Use variables that can be set in a higher-level scope like site.pp to control how the module works, instead of baking your site’s settings into the module. For example, in my LDAP module I do this:
class ldap::common {
case $ldap_base_dn {
"": { $ldap_base_dn = "dc=example,dc=com"
warning("ldap_base_dn not set, using default $ldap_base_dn")
}
}
case $ldap_admin_dn {
"": { $ldap_admin_dn = "cn=admin,$ldap_base_dn"
warning("ldap_admin_dn not set, using default $ldap_admin_dn")
}
}
case $ldap_admin_password {
"": { fail("ldap_admin_password not set!")
}
}Then, in site.pp, I set the variables appropriately:
# Site Variables
$ldap_server = "ash001.example.com"
$ldap_admin_password = "testing"
$ldap_base_dn = "dc=example,dc=com"
Your module should implement a minimal working configuration “out of the box”.
This principle is also tied in with the fact that modules were meant to be shared. When someone is looking for a module, they are going to want something that works with little-to-no configuration, because this will give them confidence that the module will work once it is fully configured. Just like full-blown pieces of software, if a module doesn’t have an easy initial setup, people will get confused as to whether or not it even works. My LDAP module provides a ldap::master class which implements a very basic configuration: the slapd package is installed, a working configuration file is set up (without SSL or any of the other goodies), and the service is started. If the user sets just one variable, $ldap_admin_password in their init.pp and includes ldap::master on a node, they will be able to verify that LDAP is up and running with an example configuration. Even better, if they set the other variables, this configuration will be customized to their site with little effort on their part. It might be better to add in all the bells and whistles (SSL at a minimum), but I’m not sure yet where I stand on that.
Use variables to make it easier to patch your module for use on other platforms.
Currently, in the init.pp of my LDAP module, I set variables like this:
$ldappackage = "slapd"
$ldapservice = "slapd"
$ldapdir = "/etc/ldap"
$ldaputilpackage = "ldap-utils"
$ldapclientpackage = "libnss-ldap"
and use them like this:
package {
$ldappackage: ensure => installed;
}
file { "$ldapdir/slapd.conf":
content => template("ldap/slapd.conf.erb"),
require => Package[$ldappackage],
notify => Service["$ldapservice"],
}
service { $ldapservice:
require => [ Package[$ldappackage], File["$ldapdir/slapd.conf"] ],
ensure => running,
enable => true,
}These variables are set up for Debian now, because that is the distribution I’ve standardized on. If later I (or someone I’ve shared the module with) wants to add support for another distribution, they can set up case statements, and not have to modify the rest of the module!
case $operatingsystem {
debian: {
$ldappackage = "slapd"
$ldapservice = "slapd"
$ldapdir = "/etc/ldap"
$ldaputilpackage = "ldap-utils"
$ldapclientpackage = "libnss-ldap"
}
centos: {
$ldappackage = "openldap"
$ldapservice = "slapd"
$ldapdir = "/etc/openldap"
$ldaputilpackage = "openldap-utils"
$ldapclientpackage = "libnss-ldap"
}
}I have not tested this, as I don’t use CentOS, so don’t use these!
Break a module up into sensible classes and defined types to make it easy to customize via inheritance.
Since you’ve pulled all the site-specific customization out of your package, and you are providing a minimal working configuration, people are going to want to do other things with your module that are appropriate to their site. If you have everything lumped into one big “ldap” class, this is going to be difficult for them. I break thinks up into ldap::common for things common to all the other classes, ldap::client for things needed to query the LDAP servers, ldap::master for the primary LDAP server, and later I’ll provide ldap::slave for replication slaves.
Use init.pp for module-wide variables and/or common functionality, but break all other classes/defines into separate files.
This is for your sanity as well as the sanity of those who might want to modify your module. I started with everything in one big init.pp file and it rapidly went out of control. Puppet does some awesome automagical lookups that you can take advantage of. For example, my ldap::master class is defined in a file called master.pp; when someone tries to load ldap::master, Puppet automatically searches for a .pp file named “master” in the “ldap” module!
So far, this is all the wisdom I have to impart on the subject. I’ll be sure to post links here when these modules are ready for prime-time.