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:
Name modules after the software or service they manage, for example,
apacheorhaproxy.Name classes within modules (subclasses) after the function or service they provide to the module, for example,
apache::vhostsorrails::dependencies.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 namedapache::disabled.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.
The module that manages users should be named
user.Within the user module, declare your virtual users within the class
user::virtual(for more on virtual users and other resources, see the Using virtual resources recipe in Chapter 5, Users and Virtual Resources).Within the user module, subclasses for particular groups of users should be named after the group, for example,
user::sysadminsoruser::contractors.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.initLogrotate config snippet for Rails:
rails.logrotateNginx vhost file for mywizzoapp:
mywizzoapp.vhost.nginxMySQL 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",If you need to manage, for example, different Ruby versions, name the class after the version it is responsible for, for example,
ruby192orruby186.
There's more…
Puppet community maintains a set of best practice guidelines for your Puppet infrastructure, which includes some hints on naming conventions:
http://docs.puppetlabs.com/guides/best_practices.html
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.