Using standard naming conventions

Choosing appropriate and informative names for your modules and classes will be a big help when it comes to maintaining your code. This is even truer if other people need to read and work on your manifests.

How to do it...

Here are some tips on how to name things in your manifests:

1. Name modules after the software or service they manage, for example, apache or haproxy.
2. Name classes within modules (subclasses) after the function or service they provide to the module, for example, apache::vhosts or rails::dependencies.
3. If a class within a module disables the service provided by that module, name it disabled. For example, a class that disables Apache should be named apache::disabled.

 

4. Create a roles and profiles hierarchy of modules. Each node should have a single role consisting of one or more profiles. Each profile module should configure a single service.
5. The module that manages users should be named user.
6. Within the user module, declare your virtual users within the user::virtual class (for more on virtual users and other resources, see the Using virtual resources recipe in Chapter 5, Users and Virtual Resources).
7. Within the user module, subclasses for particular groups of users should be named after the group, for example, user::sysadmins or user::contractors.
8. When using Puppet to deploy the config files for different services, name the file after the service, but with a suffix indicating what kind of file it is, for example:
   • Apache init script: apache.init
   • Logrotate config snippet for Rails: rails.logrotate
   • Nginx vhost file for mywizzoapp: mywizzoapp.vhost.nginx
   • MySQL config for standalone server: standalone.mysql
   • If you need to deploy a different version of a file depending on the operating system release, for example, you can use a naming convention like the following:

memcached.lucid.conf
memcached.precise.conf

• • You can have Puppet automatically select the appropriate version as follows:

source = > "puppet:///modules/memcached /memcached.${::lsbdistrelease}.conf",

9. If you need to manage, for example, different Ruby versions, name the class after the version it is responsible for; for example, ruby192 or ruby186.

There's more...

Some people prefer to include multiple classes on a node by using a comma-separated list, rather than separate include statements; for example:

node 'server014' inherits 'server' {
 include mail::server, repo::gem, repo::apt, zabbix
}

This is a matter of style, but I prefer to use separate include statements, one on a line, because it makes it easier to copy and move around class inclusions between nodes without having to tidy up the commas and indentation every time.

I mentioned inheritance in a couple of the preceding examples; if you're not sure what this is, don't worry, I'll explain this in detail in the next chapter.