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 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',
}
## Apply a manifest by running:
# puppet apply hosts.pp
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.
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.
Like software packages, modules can be searched for and installed. Searching for published modules can be done with puppet module list. Modules can be installed with puppet module install. Eg. puppet module install puppetlabs-ntp --version 7.1.1.
To create your own modules, a boilerplate template can be generated with puppet module generate module-name. Modules should start with the organization, a dash, followed by the module name (eg. cpsc-hosts).
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',
}
}
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.5/file_serving.html
- https://puppet.com/docs/puppet/5.3/modules_fundamentals.html
- https://puppet.com/docs/puppet/5.3/environments_about.html