learning puppet 3— Classes and Modules

Classes are Puppet's way of separating out chunks of code, and modules are Puppet's way of organizing classes so that you can refer to them by name.

Classes

Classes are named blocks of Puppet code, which can be created in one place and invoked elsewhere.

• Defining a class makes it available by name, but doesn’t automatically evaluate the code inside it.
• Declaring a class evaluates the code in the class, and applies all of its resources.

you can declare class in tow ways:

include ClassName or class{'ClassName': }

Modules

To help you split up your manifests into an easier to understand structure, Puppet uses modules and the module autoloader.

It works like this:

• Modules are just directories with files, arranged in a specific, predictable structure. The manifest files within a module have to obey certain naming restrictions.
• Puppet looks for modules in a specific place (or list of places). This set of directories is known as the modulepath, which is a configurable setting.
• If a class is defined in a module, you can declare that class by name in any manifest. Puppet will automatically find and load the manifest that contains the class definition.

The Other Subdirectories:

We've seen two of the subdirectories in a module, but there are several more available:

• manifests/ — Contains all of the manifests in the module.
• files/ — Contains static files, which managed nodes can download.
• templates/ — Contains templates, which can be referenced from the module’s manifests. More on templates later.
• lib/ — Contains plugins, like custom facts and custom resource types.
• tests/ or examples/ — Contains example manifests showing how to declare the module’s classes and defined types.
• spec/ — Contains test files written with rspec-puppet.

Organizing and Referencing Manifests --the relationship between manifests and its class name

Each manifest in a module should contain exactly one class or defined type. (More on defined types later.)

Each manifest’s filename must map to the name of the class or defined type it contains. The init.pp file, which we used above, is special — it always contains a class (or defined type) with the same name as the module. Every other file must contain a class (or defined type) named as follows:

<MODULE NAME>::<FILENAME>

…or, if the file is inside a subdirectory of manifests/, it should be named:

<MODULE NAME>::<SUBDIRECTORY NAME>::<FILENAME>

So for example, if we had an apache module that contained a mod_passenger class:

• File on disk: apache/manifests/mod_passenger.pp
• Name of class in file: apache::mod_passenger

You can see more detail about this mapping at the namespaces and autoloading page of the Puppet reference manual.

Class Parameters

Example:

class echo_class ($to_echo = "default value") {
         notify {"What are we echoing? ${to_echo}.":}
}

class {'echo_class':
         to_echo => 'Custom value',
}

the $to_echo is a class parameter, and you can assign value to it just like set the class's atribute value.

Inheritance

Classes can be derived from other classes using the inherits keyword. This allows you to make special-case classes that extend the functionality of a more general “base” class.

You should only use class inheritance when you need to override resource attributes in the base class. This is because you can instantiate a base class by including it inside another class’s definition, and assigning a direct parent scope is rarely necessary since you can use qualified variable names to read any class’s internal data.

Additionally, many of the traditional use cases for inheritance (notably the “anti-class” pattern, where you override a service resource’s ensure attribute to disable it) can be accomplished just as easily with class parameters. It is also possible to use resource collectors to override resource attributes.

class base::freebsd inherits base::unix {
     File['/etc/passwd'] {
     group => 'wheel'
     }
     File['/etc/shadow'] {
     group => 'wheel'
     }
}

the base class base::unix has resource ”file“ named '/etc/passwd' and '/etc/shadow'；