Managing packages

Another key resource type in Puppet is the package. A major part of configuring servers by hand involves installing packages, so we will also be using packages a lot in Puppet manifests. Although every operating system has its own package format, and different formats vary quite a lot in their capabilities, Puppet represents all these possibilities with a single package type. If you specify in your Puppet manifest that a given package should be installed, Puppet will use the appropriate package manager commands to install it on whatever platform it's running on.

As you've seen, all resource declarations in Puppet follow this form:

RESOURCE_TYPE { TITLE:
  ATTRIBUTE => VALUE,
  ...
}

package resources are no different. The RESOURCE_TYPE is package, and the only attribute you usually need to specify is ensure, and the only value it usually needs to take is installed:

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

Try this example:

sudo puppet apply /examples/package.pp
Notice: Compiled catalog for ubuntu-xenial in environment production in 0.52 seconds
Notice: /Stage[main]/Main/Package[cowsay]/ensure: created
Notice: Applied catalog in 29.53 seconds

Let's see whether cowsay is installed:

cowsay Puppet rules!
 _______________
< Puppet rules! >
 ---------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Now that's a useful package!

How Puppet applies the manifest

The title of the package resource is cowsay, so Puppet knows that we're talking about a package named cowsay.

The ensure attribute governs the installation state of packages: unsurprisingly, installed tells Puppet that the package should be installed.

As we saw in the earlier example, Puppet processes this manifest by examining each resource in turn and checking its attributes on the server against those specified in the manifest. In this case, Puppet will look for the cowsay package to see whether it's installed. It is not, but the manifest says it should be, so Puppet carries out all the necessary actions to make reality match the manifest, which here means installing the package.

Tip

It's still early on in the book, but you can already do a great deal with Puppet! If you can install packages and manage the contents of files, you can get a very long way towards setting up any kind of server configuration you might need. If you were to stop reading right here (which would be a shame, but we're all busy people), you would still be able to use Puppet to automate a large part of the configuration work you will encounter. But Puppet can do much more.

Exercise

Create a manifest that uses the package resource to install any software you find useful for managing servers. Here are some suggestions: tmux, sysdig, atop, htop, and dstat.

Querying resources with the puppet resource

If you want to see what version of a package Puppet thinks you have installed, you can use the puppet resource tool:

puppet resource package openssl
package { 'openssl':
  ensure => '1.0.2g-1ubuntu4.8',
}

puppet resource TYPE TITLE will output a Puppet manifest representing the current state of the named resource on the system. If you leave out TITLE, you'll get a manifest for all the resources of the type TYPE. For example, if you run puppet resource package, you'll see the Puppet code for all the packages installed on the system.

Tip

puppet resource even has an interactive configuration feature. To use it, run the following command:

puppet resource -e package openssl

If you run this, Puppet will generate a manifest for the current state of the resource, and open it in an editor. If you now make changes and save it, Puppet will apply that manifest to make changes to the system. This is a fun little feature, but it would be rather time-consuming to do your entire configuration this way.