Puppet was started by creator and founder Luke Kanies, who was working as a sysadmin and consultant. He was unable to find the tooling he wanted to use and that his customers could rely on, so he created Puppet as a Ruby-based open source configuration management language in 2005. The success of this open source project resulted in the release of a commercial offering, Puppet Enterprise, in February 2011. But as the demands increased and Puppet needed to reform and expand as both a company and an open source project, Luke stood down, stating that the challenges of growing Puppet to enterprise-scale were far from what I love to do most, and far from my core skills. We need to scale, and we need to execute.

The new leadership that followed took a direction that saw the company develop its professional services, and focus more effort on developer tooling and education while expanding its product range both organically and via acquisitions, striking a difficult balance between the open source community and its enterprise customer demands. Puppet was acquired by Perforce Software on May 17, 2022, following the Chef (2020) and Ansible (2015) acquisitions, as the last of the standalone configuration management start-ups. Luke summed up the change that has taken place in the industry: DevOps teams are different now. Companies are looking for a complete solution, rather than wanting to integrate individual best-of-breed vendors.

This history has seen Puppet move from a tool that left it to the developer to decided how best to use it to solve problems to, today, a tool with patterns and solutions that users can just consume to standardize their automation and deployment. This has allowed users to focus on their solutions and not the underlying technology.

DevOps itself has become a frustrating term in the IT industry; the definition given by formal sources differs hugely from how companies actually use it, and references to it can be used as a cynical buzzword or sales gimmick. The focus of this book is on DevOps engineering, as used particularly by large companies and has been well researched and discussed in studies such as the Puppet-run State of DevOps Report. DevOps engineering is normally delivered as part of projects such as digital transformations, cloud-first migrations, and various other modernization projects. What is typically seen in these projects is a desire to automate self-service deployment, compliance, and remove toil. This approach follows the DevOps goal of breaking down the silos between developers and ops teams by allowing better communication and establishing shared goals. What is noticeable is that the system administrator role in which Luke worked originally has effectively been replaced by roles such as DevOps engineers.

Puppet will be used as part of a DevOps toolchain, and Figure 1.1 shows an example set of tools and their relative functions. It is typical for Puppet to start its role at the end of a provisioning pipeline, as infrastructure is stood up in a platform and needs to be configured and enforced:

Figure 1.1 – A DevOps toolset

This book will focus not just on a technological understanding but also on how to use the maturity of the Puppet language, tooling, and platform with opinionated patterns. These approaches have been developed through years of customer engagements for Puppet and the communities’ own implementations to allow users to reduce their effort in finding the right approach, focus on their solutions, and deliver immediate benefit and return to their customers.

The first important thing to understand is how Puppet differs from normal scripting or coding languages. Puppet is declarative, meaning you describe the state you want the system to be in. For example, you could describe that your system should have a user called username with UID 1234, a configuration file should not exist, and a kernel setting should be at a particular value. In comparison to most languages where you have to describe the process to get to the state, Puppet’s approach brings us closer to how customers request services. They don’t want to know how it’s done, just that it will meet their requirements. These resource definitions can be saved in your version control system. Often, this approach is described as being part of Infrastructure as Code.

Puppet is idempotent, meaning that it will only make the changes required to get into the declared state. Meanwhile, most procedural languages will run steps every time and, typically, require various checks such as if statements to be added to make checks to avoid duplication. This is particularly powerful as what is called enforcement can be run with the Puppet language, ensuring the state you declared has been reached, and is capable of detecting whether a change happened because of you updating the state you wished the machine to be in or whether it was a change that happened on the machine itself moving away from the desired state. This can greatly assist with audits and avoid any configuration drifts in an estate and ensure change is managed and deliberate.

Puppet is OS-independent; the language is focused on the state, not the underlying implementation of how particular OSes install a package or add a user. This gives us a universal language that is independent of any underlying implementations, allowing for less duplication of code, avoiding the need to use layers of case/if statements to detect differences, and allowing multiple language implementations such as PowerShell for Windows and Bash for Unix-based systems. Additionally, it makes it easier to recover after failures in applying code. If in a procedural language, a step fails, it might not be safe to run the script in full again depending on how well the check steps have been coded. In contrast, Puppet code is able to resume only performing the steps it needs to reach the correct state.

A simple example of Puppet code to create a user would look like this:

user { 'david'
  uid => '123'
}

In contrast, a shell script might have a section like this:

if ! getent passwd david; then
  useradd -u 123 david
elif ! $(uid david) == 123; then
  usermod -u 123 david
fi

In the preceding shell example, we have to check whether a user exists, and if not, create one. If it does exist, then does it have the right UID? If not, we change it. This script only covers OSes that can use useradd and usermod. To achieve compatibility with multiple OSes, we would need a test to detect the OS type and produce a section of code like this for every OS or group of OSes and their required commands. Often, it would be more practical to write in multiple languages and scripts to cover a broader base of OS flavors, that is, if we wanted to cover both Unix and Windows, for example.

This compares to the Puppet declaration, which will work on multiple OSes without change as Puppet will detect the required commands and perform all the necessary state checks as part of that.

This example is all just for a single resource with a single attribute. You can quickly see how the shell script example will not scale as it becomes increasingly complex with almost endless checks and options.