Introduction👨✈
When we deal with Puppet or when we talk about the Puppet run, in particular, we come across various terms such as server, agent, node, catalog, etc. But the question arises of how these terms play their part in a Puppet run. The answer to this question falls under Puppet's internals; for that, we need to understand the life cycle of Puppet run. Cool! Are you ready❓
Fine! So let us learn about the life cycle of Puppet run.💫
Also See, Types of Agents in Artificial Intelligence.
Life Cycle of Puppet Run✅
In a Puppet run, the agent node sends facts to the primary server and requests a catalog. Then the primary server compiles and returns the agent's catalog, and finally, the agent applies the catalog.
Let us learn about the details of Puppet's internals, including how agents and primary servers communicate via host-verified HTTPS and the process of catalog compilation.
We will discuss the following.
⚡Agent - server HTTPS communications - It is a communication between the Puppet agent and the primary server through mutually authenticated HTTPS.
⚡Catalog compilation - Puppet compiles catalog using agent-provided data, external data, and manifests and modules sources of configuration information.
⚡Static catalogs - A static catalog includes file metadata in its section and associates it with the catalog's file resources.
Agent-server HTTPS Communications💬
The primary server and Puppet agent communicate via mutually authenticated HTTPS using the client certificates. Access to each endpoint is controlled by settings in the 'auth.conf' file.
Constant HTTP and HTTPS connections and Keep-Alive📌
➼Puppet reuses connections when it acts as an HTTPS client by sending "Connection: Keep-Alive" in HTTP requests. This reduces TLS(transport layer security) overhead, which improves performance for runs with several HTTPS requests.
➼You can configure the duration of "Keep-Alive" using the "http_keepalive_timeout" setting, but it should be shorter than the maximum allowed"keepalive" limit by the web server (of the primary server).
➼Puppet caches HTTP connections and verifies the HTTPS connections. But when you specify a custom HTTP connection class, the Puppet does not cache the connection.
➼The Puppet always requests a connection to be kept open, but the server has a choice to close the connection. It can close it by sending "Connection: close" in the HTTP response. If that takes place, then the Puppet does not cache the connection. It starts a new connection for its subsequent request.
Agent-side checks and HTTPS requests📌
During a single Puppet run, the agent-side checks and HTTPS requests process deals with the following.
1️⃣Check for keys and certificates.
2️⃣Request a node object and switch environments.
➼Make a GET request to /puppet/v3/node/<XYZ NAME>. Read the environment from the node object if the request is successful. Using the environment from the agent's config file if the node object had no environment set or the request was unsuccessful.
3️⃣Fetch plugins
➼If the pluginsync is enabled on the agent, fetch plugins from a file server mount point that scans the lib directory of every module.
4️⃣Request catalog while submitting facts.
➼Make a POST request to /puppet/v3/catalog/<XYZ NAME>, where the post data is all the node's facts encoded as JSON. Receive a compiled catalog in return.
5️⃣Make file source requests while applying the catalog.
➼The file resources can specify the file contents as either a source or content attribute. Source attributes only put references into the catalog, which might require additional HTTPS requests. Content attributes go into the catalog, and the agent does not need additional data.
6️⃣If the report is enabled on the agent, submit the report.
➼Make a PUT request to /puppet/v3/report/<XYZ NAME>. The PUT's content should be a Puppet report object in YAML format.
Catalog Compilation📋
The agent uses a document when configuring a node called a catalog which it downloads from the primary server. The catalog describes its desired state per resource under management and can specify ordered dependency information.
The "puppet apply" command compiles the catalog on its node and then applies it. It plays the role of both agent and primary server. To compile a catalog for testing on the primary server. You need to run "puppet catalog compile" on the "puppetserver" with access to your modules, environments, manifests, and Hiera data.
Using three sources of configuration information, Puppet compiles a catalog. Agent-server deployments use these sources and stand-alone puppet apply nodes.
1️⃣Agent-provided data - When an agent requests a catalog, it sends four pieces of information to the primary server.
🔥The node's name.
🔥The node's certificate.
🔥The node's facts.
🔥The node's requested environment.
2️⃣External data - Puppet uses two main kinds of external data during catalog compilation.
🔥Data from an external node classifier (ENC) or another node terminus.
🔥Data from other sources can be invoked by modules' main manifest, classes, or defined types.
3️⃣Manifests and modules, including associated templates and file sources.
Catalog Compilation Process📌
The catalog compilation process begins after the catalog request has been received.
1️⃣Retrieve the node object.
2️⃣Set variables from the node object, certificate, and facts.
3️⃣Evaluate the main manifest.
4️⃣Load and evaluate classes from modules.
5️⃣Evaluate classes from the node object.
Static Catalogs✨
A static catalog has additional metadata that identifies the desired state of resources of the node's file, with source attributes pointing to "puppet:///" locations. This metadata can refer to a particular version of the file rather than the latest version. For the catalog, it can confirm that the agent is applying the suitable version of the resource of the file. Since most of the metadata is given in the catalog, Puppet agents make fewer requests to the primary server.
When to use static catalogs🤔
➼When a Puppet manifest depends on a file. And if the file's contents change more frequently than the Puppet agent receiving new catalogs.
➼When a primary server compiles a non-static catalog, the catalog does not specify a particular version of its file resources.
➼ Whenever a Puppet agent applies a non-static cached catalog containing file resources sourced from "puppet:///" locations, the agent requests file metadata from the primary server, yet nothing changes in the cached catalog. This causes the primary server to perform irrelevant resource-intensive checksum calculations for each such file resource.
👉Static catalogs avoid these problems by including metadata that refers to a particular resource file version. This prevents a newer version from not being correctly applied and avoids having the agent request the metadata on each Puppet run. This catalog type is termed static, as it contains all the information that an agent requires to determine whether the node configuration matched the instructions and the static state of file resources when the catalog was compiled.
Static catalog features⚡
➼A static catalog includes file metadata in its section and associates metadata with the catalog's file resources.
➼With static catalogs enabled. The primary server generates metadata for each file resource sourced from a "puppet:///" location. Then adds it to the static catalog and adds a code_id to the catalog that associates such file resources with the version of their files as they exist at compilation time.
Why do we need to configure the "static_file_content endpoint and code_id❓
If the Puppet Server's static catalog settings are not configured. Then the code_id parameter defaults to the null value. And the agent always uses the file_content API endpoint, which returns the latest content.
Enabling or disabling static catalogs📌
By default, the global "static_catalogs" setting is enabled. However, the default configuration does not include the code-content-command and code-id-command scripts or settings needed to produce static catalogs.
Under the given circumstances, the Puppet server does not produce static catalogs for an agent.
📌If the "static_catalogs" setting is false in the environment.conf file. For the environment under which the agent requests a catalog, the Puppet server's puppet.conf file and the agent's puppet.conf file.
📌If the Server's code-content-command and code-id-command settings and scripts are not configured. Or if the code-id-command returns an empty string.
Note ➼ Even when configured to produce static catalogs. The Puppet server does not inline metadata for all types of file resources.
We hope you understand the article about the life cycle of Puppet run.
34+ registered 
