Puppet is two things: a language for expressing the desired state (how your nodes should be configured), and an engine which interprets code written in the Puppet language and applies it to nodes to bring about the desired state.
What does this language look like? It's not exactly a series of instructions, like a shell script or a Ruby program. It's more like a set of declarations about the way things should be. Consider the following example:
package { 'curl':
ensure => installed,
}In English, this code says—The
curl
package should be installed. When you apply this manifest (Puppet programs are called manifests), the tool will do the following:
Check the list of installed packages on the node to see if curl is already installed.
If it is, do nothing.
If not, install it.
Another example:
user { 'bridget':
ensure => present,
}This is Puppet language for the declaration The
bridget
user should be present (the keyword ensure means the desired state of the resource is....). Again, this results in Puppet checking for the existence of the bridget user on the node, and creating it if necessary. This is also a kind of documentation which expresses human-readable statements about the system in a formal way. The code expresses the author's desire that Bridget should always be present.
So you can see that the Puppet program—the Puppet manifest—for your configuration is a set of declarations about what things should exist, and how they should be configured.
You don't give commands such as Do this, then do that. Rather, you describe how things should be, and let Puppet take care of making it happen. These are two quite different kinds of programming. One kind (so-called procedural style) is the traditional model used by languages like C, Python, shell, and so on. Puppet's is called declarative style, because you declare what the end result should be, rather than specify the steps to get there.
This means that you can apply the same Puppet manifest repeatedly to a node and the end result will be the same, no matter how many times you apply the manifest. It's better to think of Puppet manifests as a kind of specification, or declaration, rather than as a program in the traditional sense.
Puppet lets you describe configuration in terms of resources (types of things that can exist, such as users, files, or packages) and their attributes (appropriate properties for the type of resource, such as the home directory for a user, or the owner and permissions for a file). You don't have to get into the details of how resources are created and configured on different platforms. Puppet takes care of it.
The power of this approach is that a given manifest can be applied to different nodes, all running different operating systems, and the results will be the same everywhere.
It's worth noting that there are two different ways to use Puppet. The first way, known as agent/master architecture, uses a special node dedicated to running Puppet, which all other nodes contact to get their configuration.
The other way, known as stand-alone Puppet, does not need a special Puppet master node. Puppet runs on each individual node and does not need to contact a central location to get its configuration. Instead, you use Git, or any other way of copying files to the node, such as SFTP or rsync, to update the Puppet manifests on each node.
Both stand-alone and agent/master architectures are officially supported by Puppet. It's your choice which one you prefer to use. In this book, I will cover only the stand-alone architecture, which is simpler and easier for most organizations, but almost everything in the book will work just the same whether you use agent/master or stand-alone Puppet.