1. Home
  2. Training Library
  3. DevOps
  4. Courses
  5. Getting Started with Puppet


Developed with


Installing Puppet
PREVIEW13m 45s
The Basics
12m 11s
Puppet Language Essentials
6m 25s

The course is part of this learning path

Start course
1h 14m

Puppet is an IT automation system. If you need to install, configure, and update servers, then Puppet can help you tremendously. Instead of doing all of these tasks manually, you can tell Puppet to configure your servers for you.

Not only will Puppet free you from the drudgery of repetitive tasks, but you will also gain major benefits, such as consistency, reliability, speed of deployment, ease of recovery, and scalability.

Do you often have slightly different configurations on servers that are supposed to be identical? With Puppet, you’ll no longer have to figure out why something works on one server but doesn’t work on another one because Puppet will configure them in the same way. You’ll also have less downtime because there is less that can go wrong when everything is configured the way it’s supposed to be.

Do you always seem to be adding more servers? Provisioning servers is a breeze when Puppet already knows how to configure them.

This course will get you started on bringing these benefits to your network. It’s a hands-on course with exercises every step of the way to give you experience using Puppet. First, I will show you how to install Puppet on a virtual machine on your own desktop. Then you will use it as a test environment to learn how to write Puppet code to automate server configuration.

Learning Objectives

  • Install Puppet server
  • Use pre-built Puppet modules
  • Use manifests, classes, resources, facts, nodes, and templates
  • Create your own Puppet modules



Puppet refers to systems it manages as nodes. So far we haven't had to specify which nodes we want our Puppet code to run on. That's because we've been using the Puppet apply command which always applies the code you specify on the node where you run the command. It doesn't do any kind of checking to see if this is the right node for this particular code.

For example, in a real network you wouldn't want your web servers to have the same configuration as your application servers, or your database servers. So you would need to have some way to tell the Puppet server which nodes should get which configurations. Puppet refers to this as classification. When you classify a node you're saying which classes should be applied to that node.

For example, you could have a class called web server that contains all of the configurations that should be applied to a web server. Then you would need to tell Puppet which of your nodes are web servers. The easiest way to do this is using node definitions.

I'm going to show you how to do this with the test VM we've been using. We're going to tell the Puppet master which class it should apply to this node. Don't worry about the fact that our Puppet master is on the same server as the node we're classifying. This is just a special case where the Puppet master is managing its own underlying host.

Node definitions go in a special file called site.pp. Which is the main manifest for this Puppet master. It needs to go in the manifest directory for the production environment. This directory is empty to start with, so we'll create the site.pp file.

A node definition is quite simple. You just type node, then the fully qualified name of the node in quotes which is puppet.test.vm in this case, then a curly brace.

Now we just include any classes that should be applied to this node. So we'll say include motd setup.

Then we just put a closing curly brace on the next line and we're done.

Now we'll save the file.

Okay, please note that if we were adding any node other than the one where the Puppet master resides then we would need to perform a couple more steps.

We would have to install the Puppet agent on the node. We would also have to sign the node's SSL certificate on the Puppet server. We won't be covering that process in this course. So we'll just run the server and the agent on the same host.

Let's get back to running Puppet on this node. How do we do a Puppet run that uses the site.pp file? There are three ways to do a Puppet run.

So far we've been using the Puppet apply command to do all of our Puppet runs. This doesn't use the site.pp manifest and it's not how you would run Puppet in production. It's time to learn about other ways to run Puppet.

In a production network you would install the Puppet agent on every host that you want Puppet to manage. By default the Puppet agent runs every 30 minutes to ensure that the hosts configuration matches what the Puppet master says it should be. To start the Puppet agent you use the command Puppet agent. In production you would put the Puppet agent in the startup scripts on each hosts so that it would run at boot time.

We're going to use the Puppet agent but we're going to run it manually to make it easier to see what it's doing. And so that we don't have to wait for the next automated 30-minute run to test our changes. The way to do this is to add the -t option to the Puppet command. Minus t stands for test because you use this option when you want the Puppet agent to run once and then shut down.

Without further ado, let's give it a try.

If you get more lines of output than this then don't worry; that's normal.

Well it ran successfully but it didn't actually apply any changes. That's because the motd file has hello world in it. So Puppet didn't need to change anything. Let's change the contents of the motd file just to make sure Puppet will actually fix it. We'll just remove world. Now we'll run the Puppet agent again. This time it printed some extra lines saying that it defined the content in etc motd file. Let's double check. It did.

Now it might not seem like we really accomplished anything new because we just got Puppet to do exactly the same thing as before. That is put hello world in the motd file. But the difference is that when we used the Puppet apply command before we had to tell it which class to apply. This time with the Puppet agent -t command, we didn't tell it which class to run. It had to figure that out by looking at the node definition for this host.

There's just one more thing before we move on. If you define any nodes in site.pp then you must define them all. That sounds a bit daunting. I mean what if you forget to include one node and now Puppet won't run at all? There's an easy way to make sure that doesn't happen. You just add a default line to site.pp as a catch-all for any nodes that aren't explicitly defined. Here I'll show you.

The only tricky thing is you have to remember to not put quotes around default because it's a special value. If you don't want Puppet to do anything to a node, if it isn't explicitly defined, then you can just leave it blank in between the curly braces.

Of course, since we only have one node in our Puppet network we didn't actually need to add the default node entry. But it's still a good idea just in case we do add more nodes later. That's it for this lesson.

About the Author
Guy Hummel
Azure and Google Cloud Content Lead
Learning Paths

Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).

Covered Topics