
Puppet Cookbook - Third Edition
By :

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.
Here are some tips on how to name things in your manifests:
apache
or haproxy
.apache::vhosts
or rails::dependencies
.disabled
. For example, a class that disables Apache should be named apache::disabled
.user
.user::virtual
(for more on virtual users and other resources, see the Using virtual resources recipe in Chapter 5, Users and Virtual Resources).user::sysadmins
or user::contractors
.apache.init
rails.logrotate
mywizzoapp.vhost.nginx
standalone.mysql
memcached.lucid.conf memcached.precise.conf
source = > "puppet:///modules/memcached /memcached.${::lsbdistrelease}.conf",
ruby192
or ruby186
.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.
Change the font size
Change margin width
Change background colour