Puppet

Puppet is a configuration management tool that is used to configure and ensure your machines are in a consistent state.

Installation

Installing puppet can be done through your distro's package manager.

CentOS 8

On CentOS 8, install the puppet repository and then the puppet agent. After installation, running puppet may result in a bash: puppet: command not found error message. This is because the puppet agent isn't installed to a standard path, but rather in /opt/puppetlabs. Relaunch your shell to have the new path applied or update your PATH variable if t his happens.

# yum install http://yum.puppetlabs.com/puppet-release-el-8.noarch.rpm
# yum -y install puppet
# puppet --version
6.16.0

Post Installation Checks

Ensure that your host has the proper hostname and FQDN set. This is important especially if the host is to use a central puppet server as the hostname distinguishes the host and specifies what manifests will be executed.

# facter | grep hostname
centos8
# facter | grep fqdn
centos8.steamr.com

If the hostname is incorrect, set the proper hostname by editing /etc/hostname.

Quick Start

Puppet can be used as a standalone tool to apply manifests (.pp files defining a particular configuration state) on a machine or it can be used in conjunction with a puppet master to retrieve manifests from a remote server.

Manifests

Manifests are written in Puppet's Domain Specific Language (DSL). An example manifest:

# cat hosts.pp
file { "/etc/hosts":
	path => "/etc/hosts",
	source => puppet:///linux/hosts,
	mode => '0644',
}

Complex manifests should be grouped together into a class. Classes are logical groupings of manifests and resources. The environment that the puppet manifests run in can be seen by running facter. This command lists all the known facts of the host, any of which can be used within a manifest.

To apply the manifest, run:

## Apply a manifest by running:
# puppet apply hosts.pp

Modules

Modules groups puppet manifests, classes, and related resources such as templates into a neat package. Using a module is done by invoking a specific interface that accepts certain arguments and parameters. As a result, modules are normally used like software packages; it is distributed for easy sharing and reuse.

Searching and Installing Modules

Like software packages, modules can be searched for and installed. Searching for published modules can be done with puppet module search. Modules can be installed with puppet module install. By default, when searching and installing like this, data is pulled from the puppet-labs forge server. Modules are installed in the default location at /etc/puppetlabs/code/environments/production/modules.

For example, to install a specific version of the NTP module by puppetlabs, run puppet module install puppetlabs-ntp --version 7.1.1. This package will be placed in the /etc/puppetlabs/code/environments/production/modules/ntp directory.

Alternatively, you can install modules from a custom repository or from a tarball. In fact, you can even put everything inside the modules directory into a git repository which allows you to git clone a set of modules for stand-alone puppet instances.

For more information on installing modules, see the documentation at: https://puppet.com/docs/puppet/latest/modules_installing.html

Creating custom Puppet modules

Traditionally, you could use puppet module generate, but since around 2019, you need to install and use the pdk package. Create a new module with pdk new module author-modulename.

When a module is loaded, the first file that is read is the init.pp file. The init.pp file should contain a class with the module name. For example:

# find
.
./Gemfile
./Rakefile
./examples
./examples/init.pp
./manifests
./manifests/init.pp
./spec
./spec/classes
./spec/classes/init_spec.rb
./spec/spec_helper.rb
./metadata.json
./files
./files/linux
./files/linux/hosts

# cat manifests/init.pp
class hosts {
        file { "/etc/hosts":
                path => "/etc/hosts",
                source => "puppet:///modules/hosts/linux/hosts",
                mode => '0644',
        }
}

Modules can be built into a tarball with the pdk build command.

Using a module

A manifest can make use of an installed module by just referencing it in the manifest. For example, if the ntp module is installed, your manifest just needs to reference the class and provide any required or optional parameters:

class {'::ntp':
        server   => ['136.159.2.1', '136.159.2.4'],
}

The 3 lines above will set up the NTP service to use the two NTP servers. Apply the manifest using puppet apply manifest.pp, messages should indicate that the chrony.conf configuration file has been changed and the service is started.

# puppet module list
/etc/puppetlabs/code/environments/production/modules
└── thias-ntp (v1.1.9)

# puppet apply manifest.pp
Notice: /Stage[main]/Ntp/File[/etc/chrony.conf]/content: content changed '{md5}97078948a9e2c1b99ab3e38d26a3311d' to '{md5}469a5cf69adf4a68097a63bd72e8a07'
Notice: /Stage[main]/Ntp/Service[chronyd]/ensure: ensure changed 'stopped' to 'running'
Notice: Applied catalog in 41.08 seconds

Working with puppet master

Nodes can talk to a puppet master only after the master has signed the node's certificate. Certificates can be manually accepted by signing it using puppet cert sign node-name. Certificates on the puppet master can be shown by running:

# puppet cert list --all
+ "foreman-test.lab.cs.ucalgary.ca" (SHA256) E9:C0:89:31:96:61:9C:2E:F7:48:24:D5:DD:DF:4D:DC:22:50:1B:1E:91:D4:BE:9F:37:9D:CB:12:9B:C1:80:67
+ "foreman.lab.cs.ucalgary.ca"      (SHA256) 71:8D:78:2B:A6:D2:E4:4D:16:DF:65:AD:DC:16:0F:7A:59:8A:67:AF:D5:FB:63:C7:17:3B:DE:59:EB:D6:FA:C1 (alt names: "DNS:foreman.lab.cs.ucalgary.ca", "DNS:puppet", "DNS:puppet.lab.cs.ucalgary.ca")
+ "leo-linux.lab.cs.ucalgary.ca"    (SHA256) EC:27:E8:AC:FF:2B:4C:E6:6F:36:96:E0:A4:87:41:32:6A:08:05:6A:C0:23:30:0E:4F:DF:98:DD:33:A0:D9:68

"+" sign means the cert has been signed and accepted by the puppet master. Signed certificates are also placed in /etc/puppetlabs/puppet/ssl/ca/signed.

Once a node has been accepted, configs can be pulled by the node by running:

# puppet agent -t

Terminology

There are a few differences in the terminology between puppet and other configuration management tools such as SaltStack.

Nodes

The machines receiving configurations. (eg. Salt Minions)

Facts

Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)

Puppet Master

The server that nodes receive configuration information from. (eg. Salt Master)

Puppet DB

Acts as a puppet data warehouse for information about nodes.

Master of Masters

Multi-levels of puppet masters for larger installations, where a puppet master is controlled by another puppet master.

DSL

The Domain Specific Language used by puppet configs. (eg. Yaml)

Manifest

A file containing specific configuration states a node should be in. (eg. Salt states)

Catalog

A manifest is into a catalog which is used by puppet to apply the desired state. Compilation is triggered by a puppet apply, or when a puppet master needs to update a node. Catalogs help by simplifying/limiting state changes for a particular node.

Class

A class is a grouping of manifests.

Module

A module contains a class as well as supporting files such as templates, files, etc. One can be created by running puppet module generate module-name.

Environment

An environment contains a set of modules/classes/manifests which are isolated from each other and are applied to a set of nodes. These can be promoted to other environments after testing. (eg. Dev, QA, Production environments).

See Also

Augeas - Treats config files as tree values

• https://puppet.com/docs/puppet/5.3/resources_augeas.html

• https://puppet.com/docs/puppet/5.5/file_serving.html
• https://puppet.com/docs/puppet/5.3/modules_fundamentals.html
• https://puppet.com/docs/puppet/5.3/environments_about.html