How It Works

Define

First, you define the desired state of compute, storage and networking devices using a simple but powerful declarative configuration language. (Or choose from thousands of pre-built, tested modules on the Puppet Forge).

Simulate

Next, you can test configuration changes before taking them live, so you know exactly what will happen when a change is made.

Enforce

Report

With Puppet Enterprise, you don't have to manually sift through log files to figure out what's going on. You get reports that detail the exact configuration of your systems, including when changes were made.

As a result, you get machines that do what you want them to do (and stay that way), without running manual scripts a thousand times over.

Benefits

Preview Puppet

Explore how Puppet works in seven simple screens.

Resources

Resources are the fundamental units for modeling system configurations with Puppet. Each resource describes some aspect of a system, like a service that must be running or a package that must be installed.

Let’s say, for example, you want to see the current configuration of the root user. To see this in puppet code, type:

puppet resource user root

Puppet is describing the current state of the root user in it’s own domain specific language, or DSL. The first line is telling us the resource type, in this case user, and that the title of this user resource is root. Then Puppet is displaying a list of attributes that describe the configuration of the root user.

Puppet Enterprise ships with a number of different resource types, such as users, files, packages, and services. Each resource type has it’s own list of attributes, and Puppet is built to be able to recognize the operating system you are running on and know where to go to retrieve or enforce the state of any of those attributes across your infrastructure.

Manifests

Resources are defined using the Puppet DSL. Let’s take a look at an example user resource:

cat guest.pp

This code is declaring the desired state of the ‘guest’ user. As you can see, the Puppet DSL should be thought of as a configuration language, not a programming language.

Right now, the guest user doesn’t exist on this system. I can verify that by running:

puppet resource user guest

Puppet interrogated the system and shows that the guest user does not exist. You can use the puppet apply tool to manage the guest user using the Puppet code. You can apply this puppet code now, but first, let’s check that it will do what you expect. Puppet can be run in simulation mode to make sure the code is going to do what is expected.

puppet apply guest.pp --noop

By adding this --noop flag, you’re telling Puppet to compare the current state of the system to the desired state specified in the Puppet code, and describe what it would do to enforce that state on this system. Here it’s telling you that the guest user is currently absent and that it should be present, which is what you wanted! Let’s go ahead and enforce this state on this system by removing the noop flag.

puppet apply guest.pp

Great! Puppet has now created the guest user, so if you run:

puppet resource user guest

You can see that the user has been created!

One of the advantages of expressing what you want the system to be, rather than how to do it, is that Puppet can be run over and over with the exact same result each time. To show this, we can apply the Puppet code again:

puppet apply guest.pp

Nothing happened! Since the system is already in the state we described it should be, Puppet didn't need to make any changes.

This allows Puppet to be run often, every 30 minutes by default, with confidence that if any system's configuration is ever not correct, Puppet will correct it automatically.

Each time Puppet runs, it will report back what, if anything, was changed on the node. Now you can download Puppet Enterprise and start managing your systems!