Common misconceptions

Isn’t Puppet dead?

The focus of bleeding-edge technology has moved on to serverless and other Software-as-a-Service (SaaS)/containerized offerings, while at an Infrastructure-as-a-Service (IaaS) level, development in Puppet has reached a much greater level of maturity. 10 years ago, you might have bought this book assuming it was relevant regardless of whether you were going to work with Puppet. Today, you have a Puppet solution to implement or understand.

I need to know Ruby to use Puppet.

Some basic knowledge of Ruby would be an advantage for certain areas of Puppet code. A focus on the good use of the Puppet language to get early returns is what this book will focus on, and the reality is that the majority of Puppet professionals don’t spend much time with Ruby trying to create customizations. Even specialists working for Puppet itself find that it can be some time before they need to write something custom in Ruby.

Puppet won’t work with our change management.

A big fear is the idea of Puppet making changes outside the scope of governance and change management. This often reflects assumptions and a lack of communication with change management teams. Puppet will enforce the state you have described; therefore, changes will only happen if the state described in the code has changed or if it has been changed outside of Puppet’s control. As previously mentioned, as long as it is agreed that Puppet is the way to define particular resources, any change to the state should be seen as outside of governance and, therefore, put back into place. Later chapters will discuss how to release code and environments to ensure that Puppet remains properly access-controlled and, therefore, within governance.

I can’t make manual changes or exceptions.

This could certainly happen if users try to work around Puppet. To avoid this, it’s important to define what Puppet is responsible for, what other tooling or manual processes are responsible for, and how exceptions should be requested and approved in your system. As will be discussed in Chapters 8 and 9, by using parameters in modules and Hiera for exceptions, a controlled method can be used for exceptions, which also keeps a record in code.

I need Puppet Enterprise to use add-ons and integrations.

There is a huge amount of confusion, particularly from industry analysts, who make comparisons about what users get with Puppet Enterprise and how open source might be limited. This book will go into more depth in Chapter 14, but the fundamental difference for Puppet Enterprise is you are paying for support, services, and pre-canned modules, infrastructure, and solutions. If you have the skills, developers, and time, all of these features can be replicated in open source. Ultimately, Enterprise runs on the open source components.

Everyone will need to learn Puppet.

A major focus of this book will be the importance of structuring code to allow for self-service processes. This avoids users who might wish to have small exceptions or integrations having to learn everything as a Puppet developer and only having to understand your offerings.

It will clash with other systems.

The key part is to understand what Puppet will be responsible for and what other systems will be responsible for, and to document this well. Many environments will run multiple configuration management, orchestration, and software management tools. The important thing is to use them to their strengths with clear boundaries.