We've seen the problems that Puppet solves, and how it solves them, by letting you express the way your servers should be configured in code form. Puppet itself is an interpreter that reads those descriptions (written in the Puppet language) and makes configuration changes on a machine so that it conforms to your specification.
What does this language look like? It's not a series of instructions, such as a shell script or a Ruby program. It's more like a set of declarations about the way things should be:
package { 'curl': ensure => installed, }
In English, this code says, "The curl
package should be installed". This snippet of code results in Puppet doing the following:
Checking the list of installed packages to see if
curl
is already installedIf not, installing it
Another example is as follows:
user { 'jen': ensure => present, }
This is Puppet language for the declaration "The jen
user should be present." Again, this results in Puppet checking for the existence of the jen
user on the system, and creating it if necessary.
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. The first (procedural style) is the traditional model used by languages, such as C, Python, shell, and so on. Puppet's is called declarative style because you declare what the end result should be, rather than specifying the steps to get there.
This means that you can apply the same Puppet manifest repeatedly to a machine and the end result will be the same, no matter how many times you run the "program". It's better to think of Puppet manifests as a kind of executable specification rather than as a program in the traditional sense.
This is powerful because the same manifest—"The curl
package should be installed and the jen
user should be present"—can be applied to different machines all running different operating systems.
Puppet lets you describe configuration in terms of resources—what things should exist—and their attributes. You don't have to get into the details of how resources are created and configured on different platforms. Puppet just takes care of it.
Here are some of the kinds of resources you can describe in Puppet:
Packages
Files
Services
Users
Groups
YUM repos
Nagios configuration
Log messages
/etc/hosts
entriesNetwork interfaces
SSH keys
SELinux settings
Kerberos configuration
ZFS attributes
E-mail aliases
Mailing lists
Mounted filesystems
Scheduled jobs
VLANs
Solaris zones
In fact, since you can define custom resources to manage anything that's not covered by the built-in resources, there are no limits. Puppet allows you to automate every possible aspect of system configuration.