Pulling Strings With Puppet - James Turnbull [39]
In Listing 4-15, we've defined a class called mysql in which we've configured sample package and service resources.
So when importing a module, for example, the mysgl module, Puppet will look in all of the module paths for a directory called mysgl. It will then check the manifests directory in the root of the mysgl directory for the init. pp file and load the file and process its contents.
Puppet also allows some clever namespace manipulation to make using modules easier. By creating a module, we also create a namespace; for example, the mysgl module would create a namespace called mysgl. Using this namespace, we can easily define and refer to additional classes in our module. For example, let's say we want to add a new class to our mysgl module called server. To do this, we would define a class called mysgl::server and store it in a file called server. pp in the manifests directory of our mysql module. We can then use this module by simply including it like so:
Puppet will recognize this namespace and find and load the class in the correct module directory and file.
This namespace magic also extends to templates and files. To make use of this, we can create two additional directories underneath the module root, called templates and files. These directories should contain any templates or files that are included in the module, respectively. Your templates can then be referenced by specifying the name of the module and the name of the template like so:
Puppet will then automatically look in the correct module path for the templates directory and load the required template.
Files contained in your module can also be served out using Puppet's file server functionality. Each module automatically creates its own file serving module and loads any files stored in the files directory of your module. For example, in our mysql module, files can be served using the source attribute by employing the following structure:
This will retrieve a file called my. cnf from the files directory of the mysql module.
In your fileserver.conf configuration file, there is also special file module mount called [modules] that can be defined. This mount allows you to control access to files contained in modules. This file module is defined without a path statement and restricts access to files contained in all modules. Currently, more granular controls, for example, on a per module basis, are not available.
Caution - Modules automatically create their own file server modules, so you don't need to update your fileserver. conf file. But in your fileserver. conf file, you cannot have another file server module defined that has the same name as one of your configuration modules.
You can read more about modules and module organization at http://www.reductivelabs.com/trac/puppet/wiki/PuppetModules and http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation.
MySQL Module
Let's look at an example of our first module, mysgl. We're going to locate it in the /etc/puppet/modules directory and structure it like so:
We've included the required init. pp file and one other file, the my. cnf configuration file, in our module. We're going to put most of our module's logic in the init. pp file, and you can see that in Listing 4-16.
In Listing 4-16, you can see our mysgl module. It contains three resources. The first is a package resource that installs the three packages used for MySQL on our node. The second resource is a file type resource that retrieves the my. cnf configuration file from the master server. You'll note we've excluded the name of the master server from the source attribute, instead specifying puppet: ///, which tells Puppet to insert the name of the server itself. The file resource also uses the require attribute to tell Puppet that the mysql-libs package must be loaded