Puppet Classes, Resource Types, and Providers

This chapter will cover how classes and defined types provide structure and a way to group resources, allowing code to be modular and reusable. You will learn about the components that make up resources; types, providers, and the attributes applied to them. You will be shown how to use Puppet commands to understand the current state of the system and by looking at three of the most common resource types – packages, files, and services. You will see how to find out the attributes that are available to a resource and how to declare a state.

Using these three resource types, you will see how a simple installation of a package, configuration file, and service can be quickly used to start up an application with Puppet code, such as Apache or Grafana. The other core resource types will then be discussed, highlighting the best practices and approaches. A number of metaparameters (attributes that can be applied to any resource) will be...

Technical requirements

Provision a standard sized Puppet server with a Windows client and a Linux client by downloading the params.json file from https://github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/tree/main/ch03 using the following command:

bolt --verbose plan run pecdm::provision –params @params.json

Classes and defined types

As discussed in Chapter 1, Puppet code is stored in manifest files ending with .pp . It is possible to just write resources into a single manifest file and then, using the apply command, puppet apply example.pp, enforce the code locally. It can also be done without the manifest file using the execute flag with the Puppet code in the field of the command, such as puppet apply -e 'Package { 'vscode': }'.

Note

puppet apply can also be run against a directory of manifests and it will parse every file in order, descending a directory structure. In Chapter 11, node definitions will allow us to utilize this.

While both of these approaches are useful for testing and learning purposes, they have a clear limitation in terms of lacking any structure, which will result in both having to run a lot of large static commands or files and having no way to pass data. Classes are named sections of code that provide this structure, offering a way...

Resources, types, and providers

Resources are the fundamental basic unit of the Puppet language; every stateful item we wish to describe is a resource. Resources must be unique in terms of what they manage since Puppet has no way of managing or prioritizing conflict between resources. It will simply call out that a clash exists and fail to compile a catalog.

Each resource will have a type, which is a description of what we are configuring, such as a file or a registry setting; parameters, which are variables containing the settings we can customize for the resource; and a provider, which is the underlying implementation allowing Puppet to be OS independent. This provider is often a default based on the OS but can be added as an attribute if required. So, a resource declaration has the following syntax:

• Opens with the type name, such as file, with no quotes and in lowercase
• A curly brace ({)
• The title of the resource in quotes
• A colon (:)
• A list of attribute...

Metaparameters and advanced resources

This section will start by looking at metaparameters, which are attributes that work on any resource type. For the lab work, we covered before, required, notify, and subscribe, which were used to create dependencies between resources. To follow this, there are several other useful attributes with a range of effects on resources. To see the full documentation of metaparameters on types and providers, the meta flag can be added to the describe command: puppet describe <file type> --meta.

audit

The audit metaparameter allows us to monitor unmanaged Puppet parameters; this could either be an array list of attributes or all for monitoring all undeclared attributes. In the following example, we declare this:

file {'/var/tmp/example'
  mode => 0770,
  audit  => [owner,group]
}

This creates a /opt/puppetlabs/puppet/cache/state/state.yaml file on Puppet Enterprise or /var/lib/puppet/state/state...

Anti-patterns

In this section, we will talk about some resource features you will find documented and useable with Puppet but that this book strongly recommends you do not use and make it part of your best practices to avoid. The resource features we highlight here are powerful but make resource declarations harder to read and require more translation and calculations required to see the state we are attempting to get the server into.

Abstract resource types

An abstract resource type is used for declaring a resource when we do not want to predefine a type and may decide which resource we will use based on the client. In this simple example, a variable is set to the type and the resource is then declared using the Resource[<TYPE>] { <RESOURCE BODY>} syntax:

$selectedtype = exec
resource[$mytype] { "/bin/echo 'don't use this' > /tmp/badidea": creates => /tmp/badidea , }

A simple translation of this statement would be as follows:

...

Summary

In this chapter, you learned about declaring resources and the syntax and styling checks that can be performed to develop consistent code. Classes were shown to be a way to group resources and allow us to call classes and apply these groups of resources to servers. Defined types were then shown as a way to create repeatable patterns of Puppet code, which can vary by parameters.

We showed how to explore and use types and providers and saw some of the most commonly used core types and how to use them well. The file, package, and service types were shown to provide a great foundation for installing, configuring, and starting an application. It was seen how Puppet resources can relate to each other to ensure an order and how to then apply these resources written locally to servers for testing.

The chapter covered the core resource metaparameters to understand how to use various features of resources – tagging to allow filtered runs of resources; auditing to monitor...