In Puppet, a module can be defined as a collection of resources, classes, files, definition, and templates. Puppet supports easy re-distribution of modules, which is very helpful in modularity of code as one can write a specified generic module and can use it multiple times with very few simple code changes. For example, this will enable default site configuration under /etc/puppet, with modules shipped by Puppet proper in /etc/share/puppet.

Module Configuration

In any Puppet module, we have two partitions which help in defining the structure of code and controlling the denominates.

The search path of modules is configured using colon-separated list of directories in the puppetmasterd or masterd, the later section of Puppet’s master configuration file with the modulepath parameter.

[puppetmasterd]

…

modulepath = /var/lib/puppet/modules:/data/puppet/modules

The search path can be added at the runtime by setting the PUPPETLAB environment variable which must also be colon-separated list of variables.

Access control settings for the file server modules in fileserver.conf, the path configuration for that module is always ignored, and specifying a path will produce a warning.

Modules Source

Puppet supports a different location for storing modules. Any module can be stored in different file system of any particular machine. However, all the paths where modules are stored must be specified in configuration variable known as modulepath which is in general, a path variable where Puppet scans for all module directories and loads them up when it is booting up.

A reasonable default path can be configured as −

/etc/puppet/modules:/usr/share/puppet:/var/lib/modules.

Alternatively, the /etc/puppet directory could be established as a special anonymous module, which is always searched first.

Module Naming

Puppet follows the same naming standards of a particular module wherein the module name must be normal words, matching [-\\w+] (letter, word, number, underscore and dashes) and not containing the namespace separator: : or /. While it might be allowed regarding module hierarchies, for new modules it cannot be nested.

Module Internal Organization

When the user creates a new module in Puppet, it follows the same structure and contains manifest, distributed file, plugins, and templates arranged in a specific directory structure as shown in the following code.

MODULE_PATH/

downcased_module_name/

files/

manifests/

init.pp

lib/

puppet/

parser/

functions

provider/

type/

facter/

templates/

README

Whenever a module is created, it contains init.pp manifest file at the specified fix location inside manifests directory. This manifest file is a default file which executes first in any particular module and contains a collection of all the classes associated with that particular module. Additional .pp file can be added directly under the manifests folder. If we are adding additional .pp files, they should be named after the class.

One of the key feature achieved by using modules is code sharing. A module by nature should be self-contained which means one should be able to include any module from anywhere and drop it onto the module path, which gets loaded when Puppet boots up. With the help of modules, one gets modularity in Puppet infrastructure coding.

Example

Consider an autofs module that installs a fixed auto.homes map and generates the auto.master from templates.

class autofs {

package { autofs: ensure => latest }

service { autofs: ensure => running }

file { “/etc/auto.homes”:

source => “puppet://$servername/modules/autofs/auto.homes”

}

file { “/etc/auto.master”:

content => template(“autofs/auto.master.erb”)

}

The file system will have the following files.

MODULE_PATH/

autofs/

manifests/

init.pp

files/

auto.homes

templates/

auto.master.erb

Module Lookup

Puppet follows a pre-defined structure wherein it contains multiple directories and subdirectories in a defined structure. These directories contain different kind of files which are required by a module to perform certain actions. A little behind-the-scenes magic makes sure that the right file is associated with the right context. All module searches are within the modulepath, a colon-separated list of directories.

For file references on the fileserver, a similar reference is used so that a reference to puppet: //$servername/modules/autofs/auto.homes resolves to the file autofs/files/auto.homes in the module’s path.

To make a module usable with both the command line client and a puppet master, one can use a URL of the from puppet:///path. i.e. a URL without an explicit server name. Such URL is treated slightly different by Puppet and puppetd. Puppet searches for serverless URL in the local file system.

Template files are searched in a manner similar to manifest and files: a mention of template (“autofs/auto.master.erb”) will make the puppetmaster first look for a file in $templatedir/autofs/auto.master.erb and then autofs/templates/auto.master.erb on the module path. With Puppet versions of everything under the Puppet, it is available to use. This is called module auto loading. Puppet will attempt to auto-load classes and definitions from the module.

So, this brings us to the end of blog. This Tecklearn ‘Concept of Module in Puppet’ blog helps you with commonly asked questions if you are looking out for a job in DevOps. If you wish to learn Puppet and build a career in DevOps domain, then check out our interactive, Continuous Deployment: Configuration Management using Puppet Training, that comes with 24*7 support to guide you throughout your learning period. Please find the link for course details:

https://www.tecklearn.com/course/continuous-deployment-configuration-management-using-puppet/

Continuous Deployment: Configuration Management using Puppet Training

About the Course

Tecklearn has specially designed this Continuous Deployment: Configuration Management using Puppet Training Course to advance your skills for a successful career in this domain. The course will cover different components of Git and GitHub and how they are used in software development operations. The course consists of Configuration Management using Puppet, Puppet Components, important concepts like Puppet Lifecycle, Puppet Language and Puppet Installation. You will get an in-depth knowledge of these concepts and will be able to work on related demos. Upon completion of this online training, you will hold a solid understanding and hands-on experience with Puppet.

Why Should you take Configuration Management using Puppet Training?

Average salary of Puppet Professional is $90k – Payscale.com
Uber, Salesforce, PayPal, Booking.com, MIT, Starbucks. & many other MNC’s worldwide use Puppet across industries.
According to Grand View Research, the DevOps market size is estimated to be worth $12.85 billion by 2025. DevOps professionals are highly paid and in-demand throughout industries including retail, eCommerce, finance, and technology.

What you will Learn in this Course?

Introduction to DevOps

What is Software Development
Software Development Life Cycle
Why DevOps?
What is DevOps?
DevOps Lifecycle
DevOps Tools
Benefits of DevOps
How DevOps is related to Agile Delivery
DevOps Implementation

Continuous Deployment: Configuration Management using Puppet

Need of Configuration Management
What is Puppet
Puppet Architecture
Puppet Components
Puppet Lifecycle
Setting up Master Slave using Puppet
Puppet Manifests
Puppet Modules
Applying configuration using Puppet
Puppet File Server
Hands On

451