How Puppet works: Using the configuration management tool

What is a configuration management tool?

A major part of the DevOps process is configuration management. Here, IT admins use a tool, or set of tools, to model existing infrastructure and create configurations to provision onto that infrastructure. These tools enable admins to monitor configurations as they run and remediate any problems that occur within the runtime environment.

The process progresses like so:

1. Build a blueprint of infrastructure that's already there.
2. Define the desired end result.
3. Create the means to achieve this result.
4. Carry out the changes.
5. Ensure that the desired result is achieved.
6. Monitor the system.
7. Make any required changes.

These steps are looped as needed, and feedback is provided to the development and support teams.

What is Puppet?

There are various tools on the market, both open source and commercial systems, that offer these configuration management capabilities. One tool with a strong following is Puppet, which is available as an open source tool, as well as a fully supported commercial version, Puppet Enterprise.

Puppet also provides additional products:

• Puppet Comply provides capabilities to continuously monitor policy as code.
• Puppet Relay provides an event-driven platform that pulls an organization's DevOps environment together into a cohesive whole.

Puppet also provides other standalone software to support enterprises.

How Puppet works

Puppet uses a declarative language that models the infrastructure as a series of resources. "Manifests," consisting of a set of JSON files, pull together these resources and define the desired state of the final platform. Puppet stores manifests on the servers and uses them to create compiled configuration instructions as needed, feeding them to the agents via REST APIs.

A Puppet tool called Facter discovers and reports "facts" about nodes, which are then used to create the manifests and configurations. Facts include built-in details of the overall platform and its nodes obtained directly via Puppet, custom information the user defines and provides, or external details written in another programming language, such as Perl or C -- or even in plain text. These facts become variables available in the Puppet manifest.

With facts and manifests, users can create platform-agnostic configurations and reference different OSes on different machine configurations from a single resource. The Puppet configuration management tool then ensures the desired outcome occurs on each platform.

This overall approach to create a heavily hardware-agnostic environment is known as infrastructure as code. The user needs little to no knowledge of what physically exists in terms of servers, network items or storage. Instead, the user declares what is required, and the configuration management tool converts the requirements into reality. This also encompasses a capability known as idempotency, which creates instructions that ensure the same result is created time after time, no matter where the results are created.

Certain situations may require a manual override, such as a service dependency on an OS patch or device driver. Puppet accommodates this via Hiera, a system that provides storage for site-specific configuration data as external information in a key-value pair lookup table. This system supports JSON, YAML and EYAML files, as well as providing back-end support for other systems, such as PostgreSQL. This lets a user create a manifest that calls specific configuration data through Hiera, and bypasses Facter, to create a highly specific runtime instance.

Nearly all aspects of Puppet code are maintained in modules that contain both code and data. Each module manages specific tasks, such as installing and managing apps across the IT platform. Most of the items to do with Puppet are then saved by the server in PuppetDB, a database that enables fast operations and access to data via APIs for other applications.

Puppet also provides thousands of prebuilt modules, from itself or its large group of third-party and individual developers, through its Puppet Forge repository. Puppet facilitates and maintains the Puppet community, but many of the thousands of people involved are completely independent from the company.

Understanding Puppet architecture

Although Puppet can run in a server-only model with command-line access, most users run it in full client-server mode, where the servers run as masters and the clients run as agents. For high availability, you should use more than one server.

The Puppet agent requests and receives individual catalogs from the server and then enforces that state on the node for which it is responsible. Each agent then maintains reports that are sent back to the server. The server monitors and manages the overall platform; it also provides the data and configuration files that the agents request and receives and manages data coming back from the agents.

Puppet's architecture relies on several key components of the primary server environment:

1. Puppet master. The application that compiles and stores Puppet code and data. Its main purpose is to process the configuration manifests to inventory information, which it then distributes to agents.
2. Puppet agent. The application that runs on every managed node. The role of the agent is to send facts to the master to locally apply the latest catalog.
3. Facts. Variables that make up a node, such as OSes and IP addresses. Puppet compiles facts for the right catalog for each node.
4. Manifests. Composed of Puppet code and tells Puppet how to configure a system. They are written in Puppet's native language and saved with the .pp extension.
5. Templates. Final documents created from the combination of code and data.
6. Files. Static content that can be downloaded.
7. Modules. A single directory structure made up of manifests and data, such as facts, templates and files.

Puppet versions

Puppet offers both an open source version and a commercial version of its software. The basic version of Puppet initially focused on the provision of a GNU GPL for a configuration management tool but changed to an Apache License 2.0 model as of Puppet version 2.7.0 in 2011. Puppet released updates to versions 7.32.1 and version 8.8.1 in July 2024. Both versions have GitHub releases, support for more OSes, and patches for StringIO and OpenSSL vulnerabilities. The version 8.8.1 release makes Puppet compatible with Ruby 3.3.

The commercial version, Puppet Enterprise, adds a collection of capabilities to help automate the delivery and operation of an organization's infrastructure: orchestration, automation, role-based access control, compliance and reporting.

Benefits of using Puppet

Puppet is a good option for managing the processes to package and provision live application instances in the IT operations environment. Puppet can run as a standalone installation, but it also has an open architecture. Enterprises that run Puppet in a development environment can link it to support DevOps processes managed by other systems.

To aid this process, many development tools provide Puppet integrations that enable developers to work directly in their chosen tool. With this option, Puppet functions as the repository for code items and stores them as resources. Puppet has worked with organizations such as Microsoft's Visual Studio team, to enhance these integrations.

As a DevOps tool, Puppet provides a reasonably comprehensive means to extend processes from developers through to operations and help desk staff. It is sufficiently code-agnostic and platform-agnostic and works alongside existing development and operations systems. It has broad support in the market from commercial and community entities. It is among the front-runner tools to provision, automate, monitor, manage and report on workloads in a modern DevOps environment.

Editor's note: To cover more recent Puppet and configuration management concepts, this article has replaced a previous TechTarget IT Operations article from 2009 by Andrew Shafer.

Clive Longbottom is an independent commentator on the impact of technology on organizations. He was a co-founder and service director at Quocirca, as well as an ITC industry analyst for more than 20 years. Trained as a chemical engineer, he worked on anti-cancer drugs, car catalysts and fuel cells before moving to IT.