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

Installation[edit]

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

Quick Start[edit]

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 DSL, Puppet's Domain Specific Language and looks something like:

# 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.

Modules contains code and resources in a specific directory structure. It provides puppet manifests/classes with a well defined interface (such as what parameters/types it accepts). Modules makes it easy to share and reuse puppet code. Modules can be installed by running puppet module install. Eg. puppet module install puppetlabs-ntp --version 7.1.1. Modules that puppet can see can be found by running puppet module list. Modules can be created using a boilerplate that is 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[edit]

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[edit]

Augeas - Treats config files as tree values