Modules, Manifests and Classes in Puppet | DevOps | VisualPath

Modules

/etc/puppet/environments/Production/modules
Modules are how Puppet finds the classes and defined types it can use automatically loads any class or defined type stored in its modules.
It is a directory where we find all the manifest files, templates and files that are required to prepare the catalog for the nodes.
Creating Modules
By running the command below, we can create the file structure for the module.
Puppet module generate USERNAME MODULE-NAME --environment ENVIRONMENT-NAME
Module Layout
On disk, a module is simply a directory tree with a specific, predictable structure:
• MODULE-NAME
• manifests
• files
• templates
• lib
• facts.d
• tests
• spec
Example
This example module, named “my_module,” shows the standard module layout in more detail:
• my_module — This outermost directory’s name matches the name of the module.
• manifests/ — Contains all of the manifests in the module.
->init.pp — Contains a class definition. This class’s name must match the module’s name.
->other_class.pp — Contains a class named my_module::other_class.
->my_defined_type.pp — Contains a defined type named my_module::my_defined_type.
->implementation/ — This directory’s name affects the class names beneath it.
1.foo.pp— Contains a class named my_module::implementation::foo.
2.bar.pp — Contains a class named my_module::implementation::bar.
•files/ — Contains static files, which managed nodes can download.
->service.conf — This file’s source => URL would be puppet:///modules/my_module/service.conf. Its contents can also be accessed with the file function, like content => file('my_module/service.conf').
• lib/ — Contains plugins, like custom facts, and custom resource types. These will be used by both the Puppet master server and the Puppet agent service, and they’ll be synced to all agent nodes whenever they request their configurations. See“Using Plugins” for more details.
•facts.d/ — Contains external facts, which are an alternative to Ruby-based custom facts. These will be synced to all agent nodes so they can submit values for those facts to the Puppet master. (Requires Factor 2.0.1 or later.)
•templates/ — Contains templates, which the module’s manifests can use. See“Templates” for more details. ->component.erb — A manifest can render this template with template('my_module/component.erb'). ->component.epp — A manifest can render this template with epp('my_module/component.epp'). (The epp function is only available with the future parser enabled.)
•tests/ — Contains examples showing how to declare the module’s classes and defined types. ->init.pp ->other_class.pp — Each class or defined type should have an example in the tests directory.
•spec/ — Contains spec tests for any plugins in the lib directory.

Manifests

Manifest is a collection of resources which are coupled inside the function or classes to configure any target system. They contain a set of Ruby code to configure a system.
Writing Manifest files
Puppet programs are called manifests. Manifests are composed of puppet code and their filenames use the .pp extension.

Classes

Classes are named blocks of Puppet code, which are stored in modules for later use and are not applied until they are invoked by name. They can be added to a node’s catalog by declaring them in your manifests.
Defining a class makes it available by name, but doesn't automatically evaluate the code inside it. Before we can use a class, we must define it, which is done with the class keyword, a name, curly braces, and a block of code:
This manifest does nothing.
Declaring a class evaluates the code in the class, and applies all of its resources.
This one actually does something.
We declare the classes in the main manifest file /etc/puppet/manifests/site.pp
Include Function:
It is used for declaration of one or more classes, which results in evaluating all the resources present inside those classes and finally add them to a catalog. The way it works is, include function accepts a class name, list of classes or a comma-separated list of class names. While defining classes, we should place puppet code in the manifest files which are made of
“ Resources ”
Resources are the fundamental unit for modeling system configurations. Each resource describes some aspect of a system, like a service that must be running or a package that must be installed. The block of Puppet code that describes a resource is called a resource declaration.
Simplified syntax
Resource declarations have a lot of features, but beginners can accomplish a lot with just a subset of these. For more advanced syntax (including expressions that declare multiple resources at once), see resources (Advanced).
# A resource declaration:
file { '/etc/passwd':
ensure =>file,
owner =>'root',
group =>'root',
mode =>'0600',
}  After  

The form of a resource declaration is:

• The resource type, which is a word with no quotes.
• An opening curly brace ({).
• The title, which is a string.
• A colon (:).
• Optionally, any number of attribute and value pairs, each of which consists of:
• An attribute name, which is a lowercase word with no quotes.
• A => (called an arrow, “fat comma,” or “hash rocket”).
• A value, which can have any data type.
• A trailing comma.
• A closing curly brace (}).

Validating the syntax of the manifest file(s)

$puppet parser validate [manifest] [manifest ...]
DESCRIPTION
This action validates Puppet DSL syntax without compiling a catalog or syncing any resources. If no manifest files are provided, it will validate the default site manifest.
When validating multiple issues per file are reported up to the settings of max_error, and max_warnings. The processing stops after having reported issues for the first encountered file with errors.
EXAMPLES
To validate the default site manifest at
/etc/puppet/environments/production/modules/sample_module/manifests/init.pp:
$ puppet parser validate init.pp 
To validate two arbitrary manifest files
$ puppet parser validate init.pp vhost.pp  

Applying modules on Puppet agent

After validating the puppet code, we need the apply that module on the node. To achieve that we have to run the command 
$puppet agent --test  
The puppet agent is configured to run at a specific interval. The default is 30 minutes. You can change how often agent pulls the catalog by modifying the “run interval” setting. 
Example:
root@puppetagent: puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for puppetagent
Info: Applying configuration version '135555737643'
Finished catalog run in 0.10 seconds  

Configuring the run interval

The Puppet agent service defaults to doing a configuration run every 30 minutes. You can configure this with the run interval setting inpuppet.conf:
 # /etc/puppet/puppet.conf
[agent]
runinterval = 2h  
Disabling and re-enabling Puppet runs
Regardless of how you’re running Puppet agent, you can prevent it from doing any Puppet runs by running 
$sudo puppet agent --disable  
You can re-enable it with
$sudo puppet agent --enable.  

Deep Dive into Puppet Coding

Variables
Syntax 
Assignment 
$content = "some content\n"  
Variable names are prefixed with a $ (dollar sign). Values are assigned to them with the = (equal sign) assignment operator. 
Resolution 
file {'/tmp/testing':
ensure =>file,
content =>$content,
}  
In the above example, A file will be created with the information(of any data type) that is stored in the variable “$content” 
Array
If we want to pass multiple parameters in puppet code, Puppet allows the use of arrays in multiple areas.
Syntax
Arrays are written as comma-separated lists of values surrounded by square brackets. An optional trailing comma is allowed between the final value and the closing square bracket.
[ 'one', 'two', 'three' ]
The values in an array can be any data type.
Example
you can specify the packages in an array … 
$enhancers = [ 'screen', 'strace', 'sudo']
package { $enhancers: 
ensure =>'installed',
}  
For DevOps training contact us at +91 9704455959 / info@visualpath.in
For more information about Visualpath, visit www.visualpath.in and follow the company on Facebook and Twitter.

Comments