Usage of Puppet Code

Introduction👨‍✈‍

When we deal with Puppet, we often define the desired state of the systems we want to manage in our infrastructure. But the question arises of how to define this desired state. The answer to this question is that by using the Puppet code, we can define the desired state of our infrastructure. Cool! Are you ready❓

Fine! So let us learn about the usage of Puppet code.💫

Usage of Puppet Code✅

We can define the desired state of the infrastructure using the Puppet code. It is stored in modules. Modules manage particular tasks in the infrastructure, such as installing and configuring software. Modules contain both data and code.

When we talk about using the Puppet code, we talk about the following.

⚡Classifying nodes - classify nodes using an ENC(external node classifier), an application, or a script that tells Puppet which classes a node should have. It can work in concert with or replace the node definitions in the "site.pp" file, which is the main site manifest.

⚡Using content from Puppet Forge - Puppet Forge is a collection of thousands of modules and how-to guides made by Puppet developers and its community.

⚡Designing system configs - build complete system configurations, which manage all software, configuration, and services.

⚡Separating data - separating data from Puppet code using Hiera. It is a built-in key-value configuration data lookup system.

⚡Use case examples - some common configuration tasks to see how one can use Puppet to manage the infrastructure.

In this article, we will only deal with classifying nodes and using content from Puppet forge.

Node Classifiers☄️

A device the Puppet manages is called a node. You can classify nodes using an ENC(external node classifier), an application, or a script that tells Puppet which classes a node should have. It can work in concert with or replace the node definitions in the site.pp file, which is the main site manifest.

The external_nodes script receives the node's name to classify as its first argument, which is usually the node's fully qualified domain name.

🧷Building an ENC(external node classifier) can be a useful way to extend Puppet depending on the external data sources you will use in your infrastructure.

External Node Classifiers🪝

An ENC is an executable that puppet apply or Puppet server can call; it doesn't have to be written in Ruby. Its only argument is the node's name to be classified and returns a YAML document that describes the node.

You can reference any data source inside the ENC, including PuppetDB. From the Puppet's perspective, the ENC submits a node name and gets a hash of information back.

🧷ENC can co-exist with standard node definitions in the site.pp file; the classes declared in each source are merged.

Merging Classes from Multiple Sources🛟

Each node always gets a node object from the configured node terminus. The node object might contain classes or empty, an environment, and parameters. The node terminus setting, node_terminus, takes effect on Puppet Server when using an agent-server configuration, where the catalog is compiled, and on the node itself when puppet apply. The default node terminus is plain. This node returns an empty node object and leaves node configuration to the main manifest. The exec terminus calls an ENC script to find what goes in the node object. Also, each node might get a node definition from the main manifest.

When compiling a node's catalog, Puppet includes the following.

📌Resources or classes in the site manifest outside any node definitions.

📌Classes present in the node object it received from the node terminus.

📌Resources or classes in the site manifest outside any node definitions.

📌Resources or classes in the most specific node definition in the site.pp file that matches the current node (if the site.pp contains any node definitions). The following notes apply.

🔥If site.pp file contains at least one node definition; it should have a node definition that matches the current node; if it cannot find a match, the compilation fails.

🔥If no matching node definition is found with the node's name, then the Puppet makes one last try with a default node name; most users include the statement node default {} in their site.pp. This behavior is not mimicked when calling an ENC.

🔥If the node name resembles a dot-separated, totally qualified domain name, Puppet makes various attempts by removing the right-most part of the name every time to match a node definition. Thus, Puppet would first try agent47.example.xyz, then agent47.example, then agent47. This behavior is not mimicked when calling an ENC, invoked only once with the agent's full node name.

Comparing ENCs and Node Definitions📈

Consider the following when deciding whether to use main manifest node definitions or an ENC (or both).

📌Unlike regular node definitions, where if an exactly matching definition isn't found, a node can match a less specific definition (depending on the Puppet's strict_hostname_checking setting), an ENC is called only once, with the node's full name.

📌The YAML returned by an ENC is not an exact equivalent of a node definition in the site.pp file — it cannot declare relationships, individual resources, or do conditional logic. An ENC can only assign top-scope variables, declare classes, and set an environment. So, an ENC is most effective if you have done an excellent job separating your configurations into modules and classes.

📌By overriding whatever environment the node requested, the ENCs can set an environment for a node.

Connect an ENC🔗

Configure two given settings to have Puppet Server connect to an ENC.

In the primary server's puppet.conf file.

1️⃣Set the node_terminus setting to exec.

2️⃣Set the external_nodes setting to the path to the ENC executable.

Results for example➼

[server]
  node_terminus = exec
  external_nodes = /pathTotheENCexecutable/puppet_node_classifier

ENC Output Format🔖

An ENC must return either a YAML hash to standard out or nothing. The hash should contain at least one of the parameters or classes, or it can contain both. Optionally it can also contain an environment key.

When functioning normally, the ENCs exit with an exit code of 0, and if you want the Puppet to behave as though the requested node wasn't found, it can exit with a non-zero exit code.

If an ENC exits with a non-zero exit code or returns nothing, the catalog compilation fails with an error "could not find node", and the node cannot retrieve configurations.

Parameters🚥

If present, the value of the parameters key should be a hash of valid variable names and associated values, which are exposed to the compiler as top-scope variables. Each value can be a number, string, hash, or array.

parameters:
    ntp_servers:
        - 0.pool.ntp.org
        - ntp.something.com
    mail_server: mail.something.com
    iburst: true

Classes📙

If present, the value of classes should be either a hash whose keys are class names or an array of class names. That is, the following are equivalent.

classes:
  common:
  puppet:
  dns:
  ntp:

 

classes:
  - common
  - puppet
  - dns
  - ntp

Use the hash key syntax if you specify parameterized classes, not the array syntax. The value for the parameterized class is a hash of the values and parameters of the class. Each value can be a number, string, hash, or array. Put string values in quotation marks as YAML parsers sometimes treat a few unquoted strings (such as on) as Booleans. Non-parameterized classes can have empty values.

classes:
    common:
    puppet:
    ntp:
        ntpserver: 0.pool.ntp.org
    aptsetup:
        additional_apt_repos:
            - deb xyzrepo.something.com/ubuntu lucid production
            - deb xyzrepo.something.com/ubuntu lucid vendor

Environment🌏

If present, the value of the environment should be a string representing the desired environment for this node. This is the only environment the node uses in its requests for catalogs and files.

environment: production

Complete Example🦾

---
parameters:
    ntp_servers:
        - 0.pool.ntp.org
        - ntp.something.com
    mail_server: mail.something.com
    iburst: true
environment: production
classes:
    common:
    puppet:
    ntp:
        ntpserver: 0.pool.ntp.org
    aptsetup:
        additional_apt_repos:
            - deb xyzrepo.something.com/ubuntu lucid production
            - deb xyzrepo.something.com/ubuntu lucid vendor

Using Content From Puppet Forge🚀

Suppose you are new to Puppet or want to save time. You can use the pre-built and tested modules on Puppet Forge. This repository is a collection of thousands of modules and how-to guides made by Puppet developers and its community.

Modules manage a particular technology in the infrastructure and serve as the basic building blocks of Puppet's desired state management. On Puppet Forge, a module manages almost any part of the infrastructure. Whether you want to patch operating systems or manage packages, a module is already set up for you.

Note ⚠️- You can see each module's README for instructions related to installation, code examples, and usage.

When you use an existing module from the Forge, you will notice that most of the Puppet code is already written for you. You need to install the module and its dependencies and write a little amount of code (called a profile) to tie things together.

We hope you understand the article about the usage of Puppet code.