Puppet Tutorial for Beginners

Introduction to Puppet

With the advancements in DevOps, the use cases and applications of Puppet have also increased. Puppet is one of the earliest configuration management tools and hence has gained a huge community of supporters and users. Puppet is a powerful tool when it comes to deploying, configuring, managing, and maintaining a machine or a system.

Watch this Puppet Tutorial for Beginners video:

In this Puppet tutorial, let’s learn about Puppet, how it works, and everything else we need to know about Puppet.

Now, coming back to Puppet, it is a configuration management technology that is available as both open-source and enterprise versions. It is developed by Puppet Labs and written in Ruby DSL (domain-specific language). Puppet runs on UNIX-like and Windows systems and is used to manage the configuration of those systems. Puppet supports Ruby and its own Puppet declarative language.

Puppet is one of the most popular configuration management tools in the IT world these days. It is being extensively used by Fortune 500 companies as well. Most of the businesses using DevOps methodologies are getting inclined toward using Puppet. There are multiple reasons explaining why it is coming out on top when compared with other configuration management tools such as chef:

• Puppet provides more platform support. For example, the following are the platforms we can manage using Puppet:
  •  Debian/Ubuntu
  •  Microsoft Windows
  •  Red Hat/CentOS/Fedora
  •  MacOS X
• Puppet has better documentation
• Unlike other configuration management tools, Puppet, after deploying a configuration on any system, keeps verifying those configurations in certain intervals. These intervals can be modified as well
• Puppet is being used by some of the major organizations in the industry, namely, Google, Red Hat, etc.
• Puppet helps DevOps professionals and System Administrators work faster and smarter

Become a master of DevOps by joining this online DevOps Training in London!

Puppet follows the client–server architecture where the client is what we call a Puppet agent and the server is what we call a Puppet master. Following are the components of the Puppet architecture:

• Puppet master: Puppet master handles the entire configuration-related information. It runs on a designated server and manages the entire deployments, configuration, etc.
• Puppet agent: Puppet agent runs on the client. Puppet agents are the actual working machines maintained and managed by the Puppet master.
• Config repository: Config repository is where the entire server-related configurations and nodes are stored. They can be pulled at any time as required.
• Facts: They are the global variables containing details related to the machine such as the operating system, network interfaces, etc. They are used to analyze the current status of any node.
• Catalog: All configurations written in Puppet are converted to a compiled format which is called a catalog and then those catalogs are applied in the target system.
• Manifests: Manifests are the files where all the resources, i.e., services, packages, or files that need to be checked and changed, are declared. Manifests have the .pp extension.
• Modules: A module is a collection of manifest files organized in a way that it facilitates the sharing of the files.
• Classes: Puppet, like other programming languages, also has classes to organize the codes better, making it easier to read and understand the code and to reuse some parts of the code.
• Resources: In Puppet codes, the coding block is defined by declaring resources where resources may represent packages, files, users, or commands.
• Nodes: All the servers or clients that are to be managed where Puppet agents are installed are called the nodes.

Knowing the components of the Puppet architecture is all good and fine, but how does it work?

Puppet has a simple yet efficient workflow. The Puppet master contains all the configuration information for different nodes that it controls using manifests.

Sign up for the Best DevOps Course in New York to get a clear understanding of DevOps!

Let’s understand the workflow of Puppet step by step:

• The nodes that the Puppet master controls have Puppet agents installed on them. The agents collect all the configuration information about their particular nodes using facts. Agents then send facts to the Puppet master.
• After gaining all the information, the Puppet master compiles a catalog based on how the nodes should be configured. The Puppet master then sends back the catalog to the agents.
• Each agent uses these catalogs and the information in them to make necessary configuration updates on their nodes and then reports back to the Puppet master.
• The Puppet master can also share the reports with a third-party tool if needed.

As we can see, the Puppet master and the Puppet agents have to communicate with each other in order to let Puppet work seamlessly, but how exactly do they communicate?

The Puppet master communicates with a Puppet agent via HTTPS (HyperText Transfer Protocol Secure) with client verification. The Puppet master provides an HTTP interface. Whenever the Puppet agent has to make a request or submission to the Puppet master, it just makes an HTTPS request to one of the endpoints available in the HTTP interface provided by the Puppet master.

Before getting into the installation part, we need to perform some pre-installation tasks as mentioned below:

1. Decide what type of deployment we are going to use: We can choose from the following types of deployments:

• Master/Agent Puppet: Master/Agent Puppet is the most commonly used as it is more convenient when it comes to updating the configurations.

This setup requires a central server where we can run a central Puppet master server. This master server is basically the host of all our configuration data. On the other nodes, the Puppet agent servers run. The Agent servers pull the configurations from the master. All agents get their own configurations, and they are independent of other agents, hence unable to see how the others are configured in the system. Before installing Puppet, if we decide to go for the master/agent deployment, then first we need to decide which server should act as the Puppet master. Puppet masters are not supported in Windows. Only after installing Puppet on our Puppet master should we move to the installation on any agent nodes. We also need to ensure that the system we are using fulfills the following requirements:

• • Fast processor
  • Lots of RAM
  • Fast disk
  • Reachable at a reliable hostname

• Standalone: In the case of a standalone Puppet, all nodes use the puppet apply command to compile the configurations and apply them. They all use the full set of Puppet modules and manifests, i.e., they all need the same files that are required by the Puppet master unlike in the case of the master/agent Puppet, so there is no Puppet master or Puppet slave in this type of Puppet deployment. This helps in distributing and reducing the load of compilation unlike in the master/agent deployment where all the burden of compilation is concentrated on the Puppet master. This may seem like a benefit and it is in some cases, but mostly it faces issues when working with central reporting and external data sources. In the case of master/agent deployment, Puppet master takes care of the central reporting and external data sources. In the standalone Puppet, every node is aware of how other nodes are configured.

2. Check the OS version and system requirements:

• If our system is running on an OS version with official packages, we will have an easier installation path
• If our system is running on an unsupported OS, it may still run Puppet as long as the Ruby version we are using is supported, given that we will have to follow a more complex installation path.

3. Checking our network configurations: If we are deploying the master/agent Puppet, then this is a must-to-be-done step for us.

• Firewalls: We must ensure that the Puppet master server allows and is able to handle incoming connections on Port 8140. Also, the agent nodes should be able to make the connection to the master on that same port.
• Hostname: Every node should have a unique hostname.
• DNS configuration: Both the forward and reverse DNS should be configured properly.

Note: The default hostname of the Puppet master is Puppet.

4. Checking the timekeeping: The Puppet master should have its system time set accurately because if it isn’t, then the certificate that is to be issued to the Puppet master will be from the past, so it will be treated as expired by the other nodes.

After being done with the pre-installation tasks, let’s start with the installation. We will be using various commands step by step to install Puppet on RHEL.

Step 1: Enabling the Puppet package repository

• Run the following command to enable the repository:

sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

Step 2: Enabling pre-releases (optional)

• Use the following command to enable the pre-releases:

[puppetlabs-devel]name=Puppet Labs Devel <%= @dist.capitalize -%><%= @version -%> - $basearch

baseurl=https://yum.puppetlabs.com/<%= @dist.downcase -%>/<%= @codename -%>/devel/$basearch

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppetlabs

enabled=1

gpgcheck=1

• To disable, just set the value of ‘enabled’ back to 0

Step 3: Upgrading the Puppet master

• To upgrade the Puppet master to the latest version, run the following command:

sudo puppet resource package puppet-server ensure=latest

• Restart the Puppet master after upgrading

Step 4: Installing the agent nodes

• On all the other nodes, run the following command:

sudo yum install puppet

Step 5: Upgrading the Puppet agent

• To upgrade the Puppet agent, use the following command:

sudo puppet resource package puppet ensure=latest

If you have doubts or queries related to DevOps, get them clarified from DevOps experts on our DevOps Community!

Step 1: Creating a Puppet master’s certificate

• Make sure that we have a main name for Puppet services at our site and that DNS resolves it to the Puppet master
• Go to the ‘main’ section of the puppet.conf file of the master and make a list of comma-separated hostnames that the master is allowed to use and set those as the values of ‘dns_alt_names’

dns_alt_names:

dns_alt_names =puppet,puppet.example.com,puppetmaster,puppetmaster.example.com

• To generate the Puppet certificate, use the following command:

sudo puppet master --verbose --no-daemonize

• Press ‘Ctrl+C,’ and it displays the Puppet master version

Step 2: Starting and enabling the Puppet master service

• Use the following command to start and enable the Puppet master service:

systemctl start puppetmastersystemctl enable puppetmaster

Step 3: Configuring the agent node

• In the agent section of the puppet.conf file of the agent node, add the following:

server= puppet.example.com

Step 4: Starting the Puppet agent service

• Use the following command to start the Puppet agent service:

sudo puppet resource service <NAME> ensure=running enable=true

Note: In Windows, to start the agent service, we just need to omit ‘sudo’ from the above command.

Step 5: Generating a signing request for the Puppet agent node

Note: When the agent nodes attempt to run for the first time, they will request for certificates. The admin has to approve the certificates.

• Log in to the Puppet master and run the following command to view the outstanding requests:

sudo puppet cert list

• Now, run the following command to sign all requests:

sudo puppet cert sign --all

step 6: Starting and enabling the Puppet agent

• Use the following command to start and enable the Puppet agent:

systemctl start puppetsystemctl enable puppet

Step 7: Verifying certificates

• To verify if the certificates were signed properly, use the following command:

puppet agent --fingerprint

And with this, our Puppet is all installed, configured, and ready to be used!

Now, what’s next?

Well, next comes turning our infrastructure administration into a codebase, describing all the processes required for the configuration management of a server. How do we do that? Let’s understand it in the next section of this Puppet tutorial.

Interested in becoming a DevOps expert? Enroll in this DevOps Course in Toronto today!

For the process of configuration management using Puppet, we will have to create a set of provisioning scripts or Puppet codes that will configure our systems. Puppet code is primarily composed of manifests.

Puppet manifest files are the files where all the resources, i.e., services, packages, or files that need to be checked and changed, are declared. Puppet manifest files are created on the Puppet master, and they have the .pp extension. They consist of the following components:

• Files: They are the plain text files that are to be imported and placed in the target location.
• Resources: Resources represent the elements that we need to evaluate or change. Resources can be files, packages, etc.
• Node definition: It is a block of code in Puppet where all the information and definition of the client node are defined.
• Templates: Templates are used to create configuration files on nodes and can be reused later.
• Classes: Classes are what we use to group the different types of resources together.

Following is the syntax for writing a basic manifest file:

resourcetype { 'title':argument or attribute1  => value,
argument or attribute2 => value, }

Writing manifest files is the closest to what we might consider as Puppet programming. Manifest files are used to define how resources should be configured. In them, we declare the resources, and they are fundamental for Puppet codes. Manifests are the building blocks of the complex Puppet modules.

Let’s start off by writing the most basic and smallest component of the manifest file, the resource.

file { 'intellipaat_file':ensure => present,
path   => 'intellipaat_file.txt', }

Note: When writing multiple resources, we have to keep in mind that the resources of the same type cannot have the same title. However, we can use the same title for different types of resources as that will not cause any conflicts.

It’s also important to know that in the case of multiple resources, Puppet does not evaluate and execute the resources in the same sequence as they are defined. We have to explicitly define the priority and dependency between these resources.

For example: In the following code block, we have defined two types of resources: the first one is a package and the other is an exec package, which implies that it is a command. When we use a package resource, we need to make sure that it is installed. The before keyword is used to make sure that the package resource is executed before the command.

package { 'curl':ensure => 'installed'
before => Exec['install script']
}
exec { 'install script':
command => '/usr/bin/curl'
}

When the exec package (lowercase) is used for declaring the resources, we use Exec (uppercase) for the already defined resources.

Learn more about DevOps in this DevOps Training in Sydney to get ahead in your career!

Example

Objective: To modify the etc/motd file in all infrastructure servers and to use Puppet automation to add the content of our choice in that file

Note: The /etc/motd file is a file available on the UNIX-like system. It consists of a message as ‘The message of the day’.

Steps to implement the above example:

• Make sure that the file is present
• If present, then make the required changes
• Change the file permissions (optional)

Following is the code block of the manifest file to perform the above-mentioned operations:

file {'/etc/motd':name    => '/etc/motd'
ensure=> present,
owner   => 'root',
group   => 'root',
content => 'The testing content', }
}

In this example, the resource type is a file and the title is /etc/motd. The content that we have added to the file is ‘The testing content’.

Modules are where we keep all our Puppet codes. There is a specific task for each module in our infrastructure, for example, installing and configuring a part of the software. Basically, modules are self-contained collections of the manifest files and data, such as facts, files, and templates, having a specific directory structure. This directory structure allows Puppet to load and find classes, facts, functions, defined types, and tasks.

While naming a module, we need to make sure that the name only consists of lowercase letters.

Modules cannot be nested and that is why module names cannot have namespace separator (::) between them.

Modules are very useful when it comes to organizing the Puppet code. Modules in Puppet provide a means to split the code in multiple manifests. They are reusable which makes it very favorable to use modules. Using modules in Puppet is considered the best practice to organize the manifest files. Using modules provides another benefit as well, i.e., code sharing. Since modules are self-contained, we can just include any model from anywhere and drop it onto the module path.

Keeping it crisp and clear, yes. For writing modules in Puppet, we do need a programming language. Having a basic knowledge of what classes and manifests are and how to write the manifests and the syntax will definitely help, and It is required if we are writing Puppet modules.

Although, for those who do not have basic programming knowledge, there is one more option to use Puppet modules. They can use pre-existing Puppet modules. But, what exactly are these pre-existing Puppet modules?

Moving further in the tutorial, let’s learn more about the pre-existing Puppet modules.

The open-source Puppet and Puppet Enterprise IT automation software have huge communities. The pre-existing Puppet modules are written and developed by the folks in these communities. Anyone can contribute to writing the pre-existing modules. These modules are public and available for anyone to download, install, and use. Currently, there are over 5,000+ pre-existing Puppet modules for anyone to use.

Now that we know what the pre-existing Puppet modules are, let’s see how to download one.

We will download the vim module from the Puppet Forge which will install and configure the vim package. We can download any module by following the same steps.

Before downloading the vim module, for those who are not familiar with the vim package, it is a popular, free, and open-source text editor.

Step 1: Click here or visit the official Puppet Forge website

Clicking on the above-provided link will take us to a web page that looks like the following screenshot:

Step 2: Enter the name of the module that we want to download in the search bar under ‘What do you want to automate?’. In our case, we are looking for the vim module as we can see in the following screenshot:

Step 3: We will find multiple results for our search, but choose the appropriate one. We can click on the individual module to look at the basic introduction of the module to make our choice. In our case, we have chosen the dhoppe vim module

Step 4: To download the module, just click on download latest.tar.gz and we will get the module in tarball

Execute the following command in the master server to install a module from the tarball:

puppet module install /path/dhoppe-vim-1.4.1.tar.gz

Note: The ‘path’ is the path to the directory where we have saved the tarball.

We can also search and install the module from the Puppet module tool using the following command:

puppet module install dhoppe-vim --version 1.4.1

Note: Before executing this command, we have to make sure that we are mentioning the latest version of the module in the command.

Puppet is on its way to becoming a de facto standard for configuration management. More than 75 percent of the Fortune 500 companies are using Puppet these days. With Puppet, System Administrators are now able to do all those tasks that were once considered tedious to do. The tasks such as testing, maintaining, operating, and enforcing changes in the software, regardless of where it runs, don’t make System Admins sweat anymore since this DevOps tool, Puppet, has come to the rescue!

To learn Puppet in detail, check out the DevOps Certification Training offered by Intellipaat and, along with Puppet, learn about other DevOps tools such as Git, Jenkins, Chef, etc.