Introduction to Puppet

1. What is Puppet?

Puppet is an open-source configuration management and automation tool used to manage servers and infrastructure automatically. It helps system administrators and DevOps engineers define how systems should be configured and maintained using code instead of manual work.

Puppet follows the concept of Infrastructure as Code (IaC), meaning you describe the desired state of your systems in configuration files, and Puppet ensures that the systems always remain in that state.

Instead of logging in to each server and manually installing packages, editing configuration files, or starting services, Puppet can automatically perform these tasks across hundreds or thousands of servers.

Puppet uses a declarative language (Puppet DSL) where you describe what the system should look like, and Puppet takes care of how to make it happen.

Example:
If you want Apache installed and running on a server, you simply declare that requirement in Puppet code.

Example Puppet Manifest:


package { 'httpd':
  ensure => installed,
}

service { 'httpd':
  ensure => running,
  enable => true,
}

This code tells Puppet:

Install Apache (httpd)
Ensure the service is running
Enable it to start on boot

If the package is missing, Puppet installs it.
If the service is stopped, Puppet starts it.

2. Problems Before Configuration Management Tools

Before tools like Puppet existed, system administrators usually:

Logged in manually to each server
Installed software individually
Edited configuration files manually
Maintained documentation separately
Fixed configuration drift manually

Example scenario:

A company has 200 Linux servers.

If Apache needs to be installed:

Admin logs into every server
Runs installation commands
Configures Apache
Starts the service

Problems:

Time consuming
Human errors
Inconsistent configurations
Difficult to maintain
Hard to audit changes

Configuration drift occurs when servers become different from each other over time.

Puppet solves this problem by enforcing a standard configuration automatically.

3. What Puppet Can Automate

Puppet can automate many system administration tasks including:

Server Configuration

Configure operating system settings such as:

Users and groups
File permissions
System services
Cron jobs
Network settings

Example:
Create a user on all servers automatically.

Software Installation

Puppet can install and manage packages on Linux systems.

Example packages:

Apache
Nginx
MySQL
Docker
Monitoring tools

Instead of manually running yum install or zypper install, Puppet installs packages automatically.

Infrastructure Management

Puppet manages large environments with many servers.

Typical infrastructure components:

Web servers
Database servers
Application servers
Monitoring servers
Load balancers

With Puppet, infrastructure can be managed from a central server.

Compliance and Security

Organizations must follow security policies and compliance standards.

Examples:

Password policies
SSH configuration
Firewall rules
Package versions

Puppet ensures every system follows the same compliance rules.

If someone changes a configuration manually, Puppet will automatically revert it to the correct state.

4. Why Puppet is Used

Puppet provides several advantages in modern infrastructure management.

Infrastructure as Code (IaC)

Infrastructure as Code means infrastructure is defined using configuration files stored as code.

Benefits:

Version control using Git
Easy rollback
Change tracking
Reproducible environments

Example workflow:

Write Puppet code
Store in Git repository
Deploy automatically

This makes infrastructure predictable and repeatable.

Automated Configuration

Puppet automatically applies configurations to servers.

Instead of doing manual tasks repeatedly, Puppet handles them automatically.

Example automation tasks:

Install packages
Manage configuration files
Start services
Create users
Set permissions

Administrators only write the configuration once.

Consistency Across Environments

Organizations typically have multiple environments:

Development
Testing
Staging
Production

Without automation, configurations may differ between environments.

Puppet ensures that all environments follow the same configuration rules, reducing deployment issues.

Example:
Apache configuration in development will be identical to production.

Reduced Manual Errors

Manual configuration often leads to mistakes such as:

Wrong configuration values
Missing packages
Incorrect permissions
Stopped services

Automation reduces these risks.

Puppet ensures systems always match the desired configuration state.

Scalability

Puppet can manage thousands of servers from a single Puppet server.

Administrators can deploy changes to all servers simultaneously.

Example:
Install a security patch on 500 servers at once.

Faster Deployment

New servers can be configured automatically.

Example workflow:

Create a new server
Install Puppet agent
Puppet automatically configures the system

Within minutes, the server becomes ready for production.

Audit and Reporting

Puppet keeps logs and reports about system configuration changes.

Administrators can see:

Which servers applied configurations
What changes were made
Whether configurations succeeded or failed

This is important for security audits and compliance.

Real-World Example

Consider a company running:

50 Web Servers
20 Database Servers
30 Application Servers

Without Puppet:

Each server configured manually
Difficult to maintain consistency

With Puppet:

Write configuration once
Apply to all servers automatically
Maintain identical configuration across the infrastructure

Puppet Architecture

After understanding what Puppet is and why it is used, the next important topic is Puppet Architecture. Architecture explains how Puppet works internally and how different components interact with each other.

Puppet typically follows a client-server architecture where a central server controls configuration and multiple agents receive and apply the configuration.

1. Puppet Architecture Overview

In a typical Puppet setup, there are three main components:

Puppet Server (Master)
Puppet Agent
Puppet Repository (Manifests and Modules)

Workflow:


Administrator writes Puppet code → Puppet Server stores configuration
Agent requests configuration → Server sends configuration
Agent applies configuration on the system

Basic flow diagram:


Admin → Puppet Server → Puppet Agent → Managed Node

2. Puppet Server (Master)

The Puppet Server is the central component responsible for managing configurations and distributing them to agents.

It performs the following tasks:

Stores Puppet configuration files
Compiles manifests into catalogs
Authenticates agents
Sends configuration to agents
Maintains certificate authority (CA)

Location of Puppet server configuration:


/etc/puppetlabs/

Main directories:


/etc/puppetlabs/code/
/etc/puppetlabs/puppet/
/opt/puppetlabs/server/

Important directory for Puppet code:


/etc/puppetlabs/code/environments/production/

Inside this directory you will find:


manifests/
modules/

Responsibilities of Puppet Server

The Puppet server performs several important operations.

Configuration Storage

Stores all configuration files written by administrators.

Example:


site.pp
modules/

Catalog Compilation

Puppet server converts manifests into a catalog.

A catalog is a compiled document describing:

Which packages must be installed
Which services must run
Which files must exist

The catalog is then sent to the Puppet agent.

Certificate Management

Puppet uses SSL certificates to authenticate agents securely.

When a new agent connects:

Agent sends a certificate request.
Puppet server signs the certificate.
Secure communication begins.

Commands used on server:

List pending certificates


puppetserver ca list

Sign certificate


puppetserver ca sign --certname agent1.example.com

3. Puppet Agent

The Puppet Agent runs on every server that needs to be managed by Puppet.

Examples of agent nodes:

Web servers
Database servers
Application servers
Monitoring servers

Each agent performs these tasks:

Connects to Puppet server
Requests configuration
Applies configuration
Sends reports back

Agent configuration file:


/etc/puppetlabs/puppet/puppet.conf

Example configuration:


[main]
server = puppet.example.com
environment = production

Agent Workflow

When the Puppet agent runs:

Agent sends request to Puppet server
Server verifies certificate
Server compiles catalog
Catalog sent to agent
Agent applies configuration

Command to run agent manually:


puppet agent -t

Default interval:

Puppet agent runs every 30 minutes automatically.

4. Puppet Manifests

A Manifest is a file that defines the desired configuration of a system.

Manifest files use the extension:

.pp

Example:


site.pp
apache.pp
users.pp

Location:


/etc/puppetlabs/code/environments/production/manifests/

Example Manifest

Install Apache and start service:


node 'agent1.example.com' {

  package { 'httpd':
    ensure => installed,
  }

  service { 'httpd':
    ensure => running,
    enable => true,
  }

}

This manifest tells Puppet:

Install Apache
Start Apache
Enable service on boot

5. Puppet Modules

Modules help organize Puppet code into reusable components.

Instead of writing everything in one file, Puppet code is divided into modules.

Example module structure:


modules/
   apache/
      manifests/
         init.pp
      files/
      templates/

Purpose of each directory:

Directory	Purpose
manifests	Puppet configuration files
files	Static files
templates	Dynamic configuration templates

Example module manifest:


class apache {

  package { 'httpd':
    ensure => installed,
  }

  service { 'httpd':
    ensure => running,
    enable => true,
  }

}

Include module in site manifest:


include apache

6. Puppet Catalog

A Catalog is a compiled configuration generated by the Puppet server.

It contains the final instructions for the agent.

Example catalog tasks:

Install package
Create file
Start service
Set permissions

The Puppet agent reads the catalog and ensures the system matches the desired state.

7. Puppet Facts

Facts are system information collected by Puppet agents.

Examples of facts:

Operating system
IP address
Memory
CPU information
Hostname

Command to view facts:


puppet facts

Example output:


os.family => RedHat
ipaddress => 192.168.1.15
memory.system.total => 8GB

Facts help Puppet apply configurations conditionally.

Example:


if $facts['os']['family'] == 'RedHat' {
  package { 'httpd':
    ensure => installed,
  }
}

8. Puppet Run Cycle

Puppet follows a run cycle.

Steps:

Agent sends request to server
Server authenticates agent
Server compiles catalog
Catalog sent to agent
Agent applies configuration
Agent sends report

Diagram:


Agent → Request → Puppet Server
Server → Compile Catalog
Server → Send Catalog → Agent
Agent → Apply Configuration
Agent → Send Report

9. Push vs Pull Model

Puppet mainly uses a Pull Model.

Pull Model

Agent requests configuration from server.


Agent → Server → Configuration

Advantages:

Secure
Scalable
Agents control update timing

Install Puppet Master and Agent on Rocky Linux 8

Step 1: Update System
Start the setup from an updated Linux system.

# dnf -y update

As Kernel updates are sometimes installed when upgrade is done, it is a good practice to reboot your machine.

# reboot

Step 2: Add Puppet Yum repository

We’ll install Puppet packages from the project official YUM repository. I’ll add EPEL repository and Puppet repository.

# dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
# dnf -y install https://yum.puppetlabs.com/puppet-release-el-8.noarch.rpm

Step 3: Install Puppet Master on CentOS 8 .
The package installed on Puppet Master/Server machine is different from the one installed on the Managed Nodes(Agent). The package required on Puppet Master nodes is puppetserver. Install this package by running the command below:

# dnf -y install puppetserver

Note: Required dependencies such as Java will be installed automatically.

Step 4 : Puppet Configuration
Puppet Server does not require any configuration. You can just start the Puppet server service. It will use the default settings. If you want to change puppet master hostname, follow the below procedure.
Advanced Configurations (optional) Here, I am going to modify the Puppet Master settings for our requirement.

# vi /etc/puppetlabs/puppet/puppet.conf
[master]
dns_alt_names = pup01
[main]
certname = pup01
server = pup01
environment = production
runinterval = 1h

Step 5: Memory Allocation:

By default, Puppet Server is configured to use 2GB of RAM. However, if we want to experiment with Puppet Server on a VM, we can safely allocate as little as 512MB of memory. To change the Puppet Server memory allocation, we can edit the init config file, /etc/default/puppetserver:

# vi /etc/sysconfig/puppetserver
Change the value.
From:
JAVA_ARGS="-Xms2g -Xmx2g -Djruby.logger.class=com.puppetlabs.jruby_utils.jruby.Slf4jLogger"

To: For 512MB, use below settings.
JAVA_ARGS="-Xms512m -Xmx512m -Djruby.logger.class=com.puppetlabs.jruby_utils.jruby.Slf4jLogger"

Step 6: Generate intermediate signing CA for Puppet Server.

# /opt/puppetlabs/bin/puppetserver ca setup

Step 8: Start and Enable the Puppet Server service:
# systemctl start puppetserver
# systemctl enable puppetserver
# systemctl status puppetserver

Step 9: Check the puppet version installed:

# puppetserver --version
puppetserver version: 7.9.5

Step 10: Install Puppet Agent

Install the puppet agent on your client using the below command.

# dnf -y update
# sed -i 's/enforcing/disabled/g' /etc/selinux/config

As Kernel updates are sometimes installed when upgrade is done, it is a good practice to reboot your machine.

# sudo reboot

Step 11: Add puppet yum repository on client and install puppet-agent

We’ll install Puppet packages from the project official YUM repository. I’ll add EPEL repository and Puppet repository.

# dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
# dnf -y install https://yum.puppetlabs.com/puppet-release-el-8.noarch.rpm
# dnf install -y puppet-agent

Puppet agent also uses some of the default settings to connect to the master node. However, we need to edit the puppet configuration file and set puppet master information.

Set server value as per your master node name. In my case, the server is pup01, and certname is my client hostname web01, db01 & lamp01.

# vi /etc/puppetlabs/puppet/puppet.conf
[main]
certname = web01
server = pup01
environment = production
runinterval = 1h

You can change the value of runinterval depends on the requirement. You can set the value in seconds (10 or 10s), minutes (10m) and hours (1h). This setting controls how long the agent should wait between the two catalog requests.

Start puppet agent on the node and make it start automatically on system boot.

# /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true
Output:
Notice: /Service[puppet]/ensure: ensure changed 'stopped' to 'running'
service { 'puppet':
ensure => 'running',
enable => 'true',
}

Step 12: Sign Agent Node Certificate on Master Server
In an agent/master deployment, an admin must approve a certificate request coming from each node so that they can fetch the configurations. Agent nodes will request certificates for the first time if they attempt to run.
Log into the puppet master server and run below command to view outstanding requests.

[root@pup01 ~]# puppetserver ca list
Output:
Requested Certificates:
web01 (SHA256) EF:BE:B3:75:00:CE:ED:99:FA:6E:FB:FB:A1:94:4B:34:B4:EF:01:B0:BE:41:74:0D:3D:2A:73:EA:15:14:FE:69
db01 (SHA256) 78:E8:66:A5:6D:48:27:8C:36:99:28:8A:C0:8E:2C:45:FE:D3:5D:F1:FC:EF:4C:B3:A2:06:AE:84:70:41:77:21
lamp01 (SHA256) 5B:27:6B:CD:DC:4C:64:D0:F0:86:AE:12:A9:FD:F4:3B:83:1F:D4:D3:FF:08:AC:1C:1D:F4:38:A2:2D:6C:B0:7F

Run puppet cert sign command to sign a request.
[root@pup01 ~]#puppetserver ca sign --certname web01
Output:
Successfully signed certificate request for web01

The puppet master can now communicate to the client machine and control the node.
If you have multiple signing requests from nodes, you can sign all the requests in one command.

[root@pup01 ~]# puppetserver ca sign --all
Successfully signed certificate request for db01
Successfully signed certificate request for lamp01
[root@pup01 ~]#

Below script is created to install puppet agent on Centos 8 clients.

[root@db01 ~]# cat puppet-agent-installation.sh
#!/bin/bash
# Purpose: Puppet Agent Installation script on Centos 8.
# Version: 1.0
# Created Date: 8-Aug-2022
# Modified Date: 6-March-2023
# Author : Vallabh Darole

### Install puppet repository ###

dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarc h.rpm
dnf -y install https://yum.puppetlabs.com/puppet-release-el-8.noarch.rpm

### Install puppet agent ###
dnf install -y puppet-agent

### Update the configuration file ###
cat > /etc/puppetlabs/puppet/puppet.conf <<EOF
[main]
certname = `hostname -s`
server = pup01
environment = production
runinterval = 1h
EOF

### Starting and Enabling puppet agent ###
/opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true

sleep 10
### Registering the puppet agent ###
/opt/puppetlabs/bin/puppet agent --test
[root@db01 ~]#

Install Puppet Development Module and configure it.

# rpm -Uvh https://yum.puppet.com/puppet-tools-release-el-8.noarch.rpm
# yum install pdk

Create modules

# cd /etc/puppetlabs/code/environments/production/modules/

[root@pup01 modules]# pdk new module banner
pdk (INFO): Creating new module: banner

We need to create the metadata.json file for this module, so we're going to ask you 4 questions.
If the question is not applicable to this module, accept the default option shown after each question. You can modify any answers at any time by manually updating the metadata.json file.

[Q 1/4] If you have a Puppet Forge username, add it here.
We can use this to upload your module to the Forge when it's complete.
--> host

[Q 2/4] Who wrote this module?
This is used to credit the module's author.
--> vallabh darole

[Q 3/4] What license does this module code fall under?
This should be an identifier from https://spdx.org/licenses/. Common values are "Apache-2.0", "MIT", or "proprietary".
--> Apache-2.0

[Q 4/4] What operating systems does this module support?
Use the up and down keys to move between the choices, space to select and enter to continue.
--> RedHat based Linux, Debian based Linux

Metadata will be generated based on this information, continue? Yes
pdk (INFO): Using the default template-url and template-ref.
pdk (INFO): Module 'banner' generated at path '/etc/puppetlabs/code/environments/production/modules/banner'.
pdk (INFO): In your module directory, add classes with the 'pdk new class' command.

Now you can see banner folder is created

[root@pup01 banner]# tree
.
├── appveyor.yml
├── CHANGELOG.md
├── data
│   └── common.yaml
├── examples
├── files
│   └── issue
├── Gemfile
├── Gemfile.lock
├── hiera.yaml
├── manifests
│   └── init.pp
├── metadata.json
├── Rakefile
├── README.md
├── spec
│   ├── default_facts.yml
│   └── spec_helper.rb
├── tasks
└── templates

7 directories, 13 files
[root@pup01 banner]#

Now let create issue file in files folder

[root@pup01 banner]# cat files/issue
\S
\U on an \m
Today is \d \t

Now let create init.pp file in manifests folder.

[root@pup01 banner]# cat manifests/init.pp
class banner {
file { '/etc/issue': ### Creation of /etc/issue file
ensure => present,
source => 'puppet:///modules/banner/issue',
owner => 'root',
group => 'root',
mode => '0644',
}
}
[root@pup01 banner]#

Once module is completed update the site.pp file

[root@pup01 manifests]# pwd
/etc/puppetlabs/code/environments/production/manifests
[root@pup01 manifests]# cat site.pp
node default {
include host_file
include banner
}
[root@pup01 manifests]#

Build module to package. The generated package will be place in pkg folder inside module directory itself. Packages are portable unit that can be shipped or published to puppet forge for distributed access:

[root@pup01 banner]# pdk build

We need to update the metadata.json file for this module, so we're going to ask you 4 questions.
If the question is not applicable to this module, accept the default option shown after each question. You can modify any answers at any time by manually updating the metadata.json file.

[Q 1/4] Summarize the purpose of this module in a single sentence.
This helps other Puppet users understand what the module does.
-->

[Q 2/4] If there is a source code repository for this module, enter the URL here.
Skip this if no repository exists yet. You can update this later in the metadata.json.
-->

[Q 3/4] If there is a URL where others can learn more about this module, enter it here.
Optional. You can update this later in the metadata.json.
-->

[Q 4/4] If there is a public issue tracker for this module, enter its URL here.
Optional. You can update this later in the metadata.json.
-->

Metadata will be generated based on this information, continue? Yes
pdk (INFO): Building host-banner version 0.1.0
pdk (INFO): Build of host-banner has completed successfully. Built package can be found here: /etc/puppetlabs/code/environments/production/modules/banner/pkg/host-banner-0.1.0.tar.gz
[root@pup01 banner]#

Next, we will install the module by referring the tar.gz file from the last output. Since, here we are installing on same puppet server, so we will remove the existing my_module folder to /tmp:

[root@pup01 banner]# mv /etc/puppetlabs/code/environments/production/modules/banner/pkg/host-banner-0.1.0.tar.gz /tmp/
[root@pup01 banner]# cd ..
[root@pup01 modules]# rm -rf banner/

Install the module again.

[root@pup01 ~]# puppet module install /tmp/host-banner-0.1.0.tar.gz
Notice: Preparing to install into /etc/puppetlabs/code/environments/production/modules ...
Notice: Downloading from https://forgeapi.puppet.com ...
Notice: Installing -- do not interrupt ...
/etc/puppetlabs/code/environments/production/modules
└── host-banner (v0.1.0)
[root@pup01 ~]#

[root@pup01 banner]# tree
.
├── CHANGELOG.md
├── data
│   └── common.yaml
├── examples
├── files
│   └── issue
├── hiera.yaml
├── manifests
│   └── init.pp
├── metadata.json
├── README.md
├── tasks
└── templates

6 directories, 7 files
[root@pup01 banner]#

[root@pup01 ~]# puppet module list

/etc/puppetlabs/code/environments/production/modules

├── ansfile (???)

├── host-banner (v0.1.0)

├── host-bash (v0.1.0)

├── host-host_file (v0.1.0)

├── host-motd (v0.1.0)

└── root-my_module (v0.1.0)

/etc/puppetlabs/code/modules (no modules installed)

/opt/puppetlabs/puppet/modules (no modules installed)

[root@pup01 ~]#

Please find puppet code in below git repository

https://github.com/vdarole/puppet.git

CentOS-Linux4U

Puppet 7 On Rocky Linux 8

Introduction to Puppet

1. What is Puppet?

2. Problems Before Configuration Management Tools

3. What Puppet Can Automate

Server Configuration

Software Installation

Infrastructure Management

Compliance and Security

4. Why Puppet is Used

Infrastructure as Code (IaC)

Automated Configuration

Consistency Across Environments

Reduced Manual Errors

Scalability

Faster Deployment

Audit and Reporting

Real-World Example

Puppet Architecture

1. Puppet Architecture Overview

2. Puppet Server (Master)

Responsibilities of Puppet Server

Configuration Storage

Catalog Compilation

Certificate Management

3. Puppet Agent

Agent Workflow

4. Puppet Manifests

Example Manifest

5. Puppet Modules

6. Puppet Catalog

7. Puppet Facts

8. Puppet Run Cycle

9. Push vs Pull Model

Pull Model

No comments:

Post a Comment