Puppet Primer IV – The Manifest and The Class

Thus far we’ve covered a lot of ground in the minutia of the varied component in Puppet. We’ve talked about what the Puppet platform is and some foundations upon which it is built. We’ve also talked about the Resource Abstraction Layer, Resources, and the Client Server model.

The thing is, I can list all the various components that get used to apply against a system, and the things that might occur when that happens, but still there are no ties between these base components.

How do I apply resources against a system?
How do I only apply resources against a subset of systems?
What are these artifacts called, and how do they interrelate?

These are only a few of the questions we’ve generated in this series.

The Manifest

Puppet has chosen the idiom of a “manifest” to be the core component which contains code that you would apply against a given system. Why was this term chosen? Let’s look at the definition of the word:

man·i·fest /ˈmanəˌfest/ noun noun: manifest; plural noun: manifests 1. a document giving comprehensive details of a ship and its cargo and other contents, passengers, and crew for the use of customs officers.

So, in this idiomatic reference, we would see a manifest as a list of things. That’s fine, but the disconnect, in my opinion, in the documentation is how to collect those manifests together, and how to get them onto a destination system. The data is there, but it’s spread across the documentation by categories, and it’s not readily clear how they relate. So, let’s break it down from the simplest component to the largest.

The Class

In the world of development, of whatever type, there are certain components we refer to known as constructs. As redundant as it seems, the dictionary tells us that to con-struct‘ something is to build or form it by putting together parts but a con‘-struct” is also something that has been constructed. For instance, “The carpenter constructed a dresser.” This is the first meaning, to build something from parts. “The carpenter’s new dresser was a beautiful construct.”

For our purposes, the aforementioned manifest would be considered a construct in that it is something built of or formed by putting together “parts”, which in our case would be resources and other code elements. Why am I talking about “constructs” and “code elements” under the heading of “Class”?

I need you to understand the components that make up a class before we talk about classes, which is now. Here is Puppet’s explanation:

In the Puppet paradigm, we talk of “classes”. Classes in Puppet are simply “Named blocks of Puppet Code”. ₁ The above video goes into more depth and at a much more rapid rate than I am currently, but I wanted you to hear their explanation.

I, however, will break down the manifest and the contained class which is this “named block of Puppet code”. FIrst, the file that contains the named block of code (the Manifest) and then the code itself. In Puppet parlance, this is the “class” designation, and it looks like so:

Now clearly this is a simplistic example, but it is an example all the same. As you can see, there’s a place in the middle there where other code would go…as much as you like! And there is the important line that names the class “foo”. Why is this important?

In coding, we have many thousands of lines of code. Some are collections of functions and some are collections of procedures. Perhaps we want to reference or include code from one bit of our codebase…maybe we did something super-cool. You can either copy/paste that code verbatim, or you can use a little trick where you just refer to that code. By naming our class, we can refer to the code by name rather than writing it or using the same methods all over again.

It is important to note here that if you have a computer science background, you may have come across the term “class” in some languages or object-oriented programming in general. THIS IS NOT THAT. In fact, it would likely be in your best interest to not try and relate Puppet classes to anything you’ve used in the past. Are there similarities? You bet. Can you apply the same rules and ideas around Puppet classes as other paradigms? Not at all. In short, forget everything you know about classes. 🙂

Manifests (again)

Puppet tells us that resources are declared in manifests. They also tell us that manifests are “Puppet language files that describe how the resources must be configured”₂ and that “manifests are a basic building block of Puppet and are kept in a specific file structure known as a module.” “Module” is a bit far along the learning curve right now, and not something I want to hit just yet. Just settle that we will cover modules and all you should think of a module and what it is right now is that it’s a virtual bucket that holds your code whether they be manifests, scripts, tasks or plans, templates, and more. We will get to all of it.

Tying everything together, we see that resources are individual elements describing the desired state for some aspect of a system. Resources are contained in classes which are a named blocks of Puppet code, and those classes live inside of files on disk known as manifests.

“That’s great, Questy, but how does this help me?”

I’m glad you asked.

Now we have several components that assist us in developing code that will configure our systems. The most important of which is this idea of a class that has a name that you can refer to from anywhere. This entire post (and some of the last one) has been targeting this specific idea.

Next time, we will talk about Desired State Configuration again, but we will add a new concept known as idempotency. This core idea is the power and elegance of Puppet in a nutshell, and we’ll talk about that. Also, we will begin to look at a module and what it is as well as how it works and is used in Puppet.