by Tomas Nevar (tomas@lisenet.com)
- Install and configure Puppet.
- Install Puppet servers.
- Install Puppet nodes.
- Register Puppet nodes to a Puppet server.
- Create and maintain Puppet manifests.
- Create new Puppet manifests.
- Debug existing Puppet manifests.
- Create Puppet modules.
- Create reusable modules.
- Create modules with classes, name spaces, variables, and conditionals.
- Create modules that install software on target nodes and deploy configuration files.
- Use facter to obtain system information.
- Create custom facts.
- Use facts to change Puppet behavior.
- Create Git repositories.
- Create and perform simple management of a Git repository.
- Add files to a Git repository.
- Apply changes and commit changed files to a Git repository.
- Implement Puppet in a Red Hat Satellite 6 environment.
- Create a Puppet repository on Red Hat Satellite.
- Install, configure, and deploy Puppet modules using Red Hat Satellite.
- Register Puppet clients to a Red Hat Satellite server.
A Puppet run starts with the Puppet agent gathering facts on the Puppet node. The facts are sent over HTTPS to the Puppet master.
The Puppet master compiles a catalog and sends the catalog back to the Puppet node. The Puppet node applies the catalog and sends a report to the Puppet master.
Install a Puppet agent:
$ sudo yum -y install puppet
Show available subcommands (output truncated):
$ puppet help
> agent The puppet agent daemon
> apply Apply Puppet manifests locally
> cert Manage certificates and requests
> describe Display help about resource types
> doc Generate Puppet references
> facts Retrieve and store facts
> generate Generates Puppet code from Ruby definitions
> man Display Puppet manual pages
> module Creates, installs and searches for modules on the Forge
> node View and manage node definitions
> parser Interact directly with the parser
> resource The resource abstraction layer shell
Puppet resource titles can contain any characters, but they are case-sensitive.
List available resource types:
$ puppet resource --types
> exec
> file
> group
> notify
> package
> service
> user
Listing Puppet resource types only provides the names of resources. To see the details, use the puppet describe command:
$ puppet describe exec
$ puppet describe service
Getting information about a specific resource type:
$ puppet resource <type> <name>
$ puppet resource service sshd
service { 'sshd':
ensure => 'running',
enable => 'true',
}
Note that file resources create files owned by root with default permissions of 0644. Directories have default permissions of 0755 when they are created. We can define different default values for a resource:
File {
ensure => 'file',
owner => 'tomcat',
group => 'tomcat',
mode => '600',
}
If an attribute block ends with a semicolon ; rather than a comma , then another title, colon and attribute block can be specified. Puppet will treat this as multiple resources of a single type.
To apply a standalone Puppet manifest to the local system:
$ puppet apply manifest.pp
Do a dry-run (a basic smoke test). This will ensure that a manifest can be properly compiled from your code:
$ puppet apply --noop manifest.pp
IMPORTANT! Validate the syntax of a manifest:
$ puppet parser validate manifest.pp
To save time, create an alias and add to ~/.bashrc:
alias ppv='puppet parser validate'
Modules are self-contained bundles of code and data. You can write your own modules, or you can download pre-built modules from Forge. Module names should only contain lowercase letters, numbers, and underscores, and should begin with a lowercase letter.
A module is simply a directory tree with a specific structure:
<MODULE NAME>
manifests
files
templates
lib
facts.d
tests
spec
Each manifest in a module's manifests folder should contain one class or defined type. Also, every module includes a JSON-formatted metadata.json information file.
Show available subcommands:
$ puppet module --help
> build Build a module release package
> changes Show modified files of an installed module
> generate Generate boilerplate for a new module
> install Install a module from the Forge or a release archive
> list List installed modules
> search Search the Puppet Forge for a module
> uninstall Uninstall a puppet module
> upgrade Upgrade a puppet module
Create a template directory structure for writing a module:
$ puppet module generate <author-modulename>
Build a Puppet module. The module will be built and packaged in the pkg directory in the module's working directory:
$ puppet module build <author-modulename>
Install a module from a release archive (requires root privileges):
# puppet module install <author-modulename>/pkg/<author-modulename>.tgz
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. The include command is used in a manifest to use a class.
Example of a simple class definition:
class webserver {
package { 'httpd':
ensure => 'present',
}
}
Example of a simple class with parameters:
class webserver ($version = 'latest') {
package {'httpd':
ensure => $version, # Using the class parameter from above
}
}
Note that every Puppet module should have a smoke test defined in tests/init.pp that includes the main class defined by the module.
About relationships and ordering. By default, Puppet applies resources in the order they're declared in their manifest. Puppet uses four metaparameters to establish relationships:
- before - applies a resource before the target resource.
- require - applies a resource after the target resource.
- notify - applies a resource before the target resource. The target resource refreshes if the notifying resource changes.
- subscribe - applies a resource after the target resource. The subscribing resource refreshes if the target resource changes.
The service will be started after the package has been installed:
service { 'vsftpd':
ensure => 'running',
enable => true,
require => Package['vsftpd'],
}
package { 'vsftpd':
ensure => 'installed',
}
You can create relationships between two resources or groups of resources using the -> and ~> operators.
-> (ordering arrow; a hyphen and a greater-than sign) - explained below
~> (notifying arrow; a tilde and a greater-than sign) - explained below
-> Applies the resource on the left before the resource on the right
~> Applies the resource on the left first. If the left-hand resource
changes, the right-hand resource will refresh.
The service will be refreshed if the config file changes:
package { 'vsftpd':
ensure => present,
} ->
file { '/etc/vsftpd/vsftpd.conf':
ensure => file,
mode => '0600',
source => 'puppet:///modules/vsftpd/vsftpd.conf',
} ~>
service { 'vsftpd':
ensure => running,
enable => true,
}
Puppet supports two templating languages: EPP and ERB. ERB works with all Puppet versions.
You can put template files in the templates directory of a module. EPP files should have the .epp extension, and ERB files should have the .erb extension. Here is example below:
file {'/eth/hosts':
ensure => 'file',
owner => 'root',
group => 'root',
mode => '644',
# loads /etc/puppet/modules/homelab/templates/hosts.erb
content => template('homelab/hosts.erb'),
}
Example content of the hosts.erb template file:
127.0.0.1 localhost
::1 localhost
<%= @ipaddress %> <%= @fqdn %>
Puppet uses Ruby's standard regular expression implementation to match patterns. Regular expressions are written as patterns bordered by forward slashes.
==operator checks for exact string matches.=~operator is used to evaluate whether a string matches regex.!~operator performs the opposite (does not match regex).
Examples:
if $operatingsystemmajrelease == '7' {
notify { "This is a RHEL 7 server": }
}
if $fqdn =~ /^web[1-3].hl.local$/ {
notify { "This is a web server": }
}
The first thing the Puppet agent does when it begins a Puppet run is to identify system facts about the node it is running on.
Display all facts about the system:
$ facter
Display a single structured fact:
$ facter os
Display a single fact nested within a structured fact:
$ facter os.family
$ facter os.release.major
Some commonly used facts (from my experience):
$ facter architecture
$ facter fqdn
$ facter id
$ facter ipaddess
$ facter osfamily
$ facter operatingsystem
$ facter operatingsystemmajrelease
$ facter is_virtual
Facter has the capability to provide additional custom facts. Additional system key=value pairs can be defined either in a text file, YAML or JSON files in /etc/facter/facts.d.
Note that custom scripts can also provide Facter with dynamic facts that are collected on the fly. These scripts must be executable!
Create a custom system fact:
# mkdir -p /etc/facter/facts.d
# echo "server_group=tomcat" > /etc/facter/facts.d/server_group.txt
$ facter | grep server_group
server_group => tomcat
Install a Puppet master:
# yum install -y puppet-server
# systemctl enable puppetmaster
# systemctl start puppetmaster
# firewall-cmd --permanent --add-port=8140/tcp
# firewall-cmd --reload
Configure Puppet agent to use the Puppet master:
# vim /etc/puppet/puppet.conf
[agent]
server = puppet-master.example.com
runinterval = 1800
# systemctl enable puppet
# systemctl start puppet
The Puppet agent will generate a host certificate and send a certificate-signing request to the Puppet master. We need to sign the client certificate on the Puppet master:
# puppet cert list
# puppet cert sign puppet-agent.example.com
Register Puppet clients to a Red Hat Satellite server. These are copied from my homelab Katello server:
# wget http://katello.hl.local/pub/katello-ca-consumer-latest.noarch.rpm
# yum install -y katello-ca-consumer-latest.noarch.rpm
# subscription-manager register --org=lisenet --activationkey="el7-key"
# yum install -y katello-agent
Create a Puppet repository on Red Hat Satellite. These are copied from my homelab Katello server:
# hammer product create \
--name "puppet_stuff" \
--description "Puppet modules"
# hammer repository create \
--name "puppet_repo" \
--content-type "puppet" \
--product "puppet_stuff"
# hammer repository upload-content \
--name "puppet_repo" \
--product "puppet_stuff" \
--organization "Lisenet" \
--path /root/lisenet-lisenet_firewall-1.0.0.tar.gz
# hammer content-view create \
--name "puppet_modules" \
--description "Content view for Puppet modules"
# hammer content-view puppet-module add \
--content-view "puppet_modules" \
--name "lisenet_firewall"
# hammer content-view publish \
--name "puppet_modules" \
--description "Publishing Puppet modules"
# hammer content-view version promote \
--content-view "puppet_modules" \
--version "1.0" \
--to-lifecycle-environment "stable"
# hammer activation-key create \
--name "el7-key" \
--description "Key to use with EL7" \
--lifecycle-environment "stable" \
--content-view "puppet_modules" \
--unlimited-hosts
# hammer activation-key add-subscription \
--name "el7-key" \
--quantity "1" \
--subscription-id "1"
Show available git subcommands (output truncated):
$ git --help
> add Add file contents to the index
> branch List, create, or delete branches
> checkout Checkout a branch or paths to the working tree
> clone Clone a repository into a new directory
> commit Record changes to the repository
> diff Show changes between commits, commit and working tree, etc
> init Create an empty Git repository or reinitialize an existing one
> log Show commit logs
> mv Move or rename a file, a directory, or a symlink
> pull Fetch from and merge with another repository or a local branch
> push Update remote refs along with associated objects
> reset Reset current HEAD to the specified state
> rm Remove files from the working tree and from the index
> show Show various types of objects
> status Show the working tree status
Set the name you want attached to your commit transactions:
$ git config --global user.name <username>
Set the email you want attached to your commit transactions:
$ git config --global user.email <email>
Set the default push action if no refspec is explicitly given:
$ git config --global push.default simple
List all configured global values:
$ git config --global --list
Create a new local repository:
$ git init <repository-name>
Clone an existing repository:
$ git clone <repository-url>
Add all current changes to the next commit:
$ git add ./
Show all new or modified files to be commited:
$ git status
Show all commits:
$ git log
Show all existing branches:
$ git branch -av
Switch to the specified branch and update the working directory:
$ git checkout <branch-name>
Delete the specified branch:
$ git branch -d <branch-name>
Show all currently configured remotes:
$ git remote -v
Prepare file for the next commit:
$ git add <file>
Commit a specific file adding a message:
$ git commit -m "My commit message" <file>
Upload changes made locally to the remote repository:
$ git push <remote> <branch>
Delete the file from the working directory and stage the deletion:
$ git rm <file>
Remove the file from the staging area (the opposite of git add):
$ git reset <file>
Revert the file to its original state:
$ git checkout -- <file>
Shows content differences:
$ git diff
Fetch changes made by other users from the repository:
$ git pull
``