Deftly Pulling Your Servers’ Strings with Puppet

By Steven J. Vaughan-Nichols

If all you’re doing is running a single server instance, you don’t need DevOps tools such as Puppet. But, if you’re setting up and managing multiple servers, you need Puppet.

Oh, you could run dozens of servers using shell scripts. Lord knows I used to do it that way. Although once I got past sysadmining, say, 30 servers, problems arose. But, why should you bother with a shell script mess like that?

With tools like Puppet, you can automate configuration management. This will not only save you and your crew hours (maybe days?) of time, but it will also let you run hundreds, even thousands of servers, per sysadmin.

Puppet does this by providing configuration management services. Once in place, it uses a client/server approach. Your managed servers, called Puppet agents, talk to and pull down configuration profiles from the Puppet master.

The Puppet master holds the agents’ configuration in its PuppetDB and Hiera data stores. The master runs as a daemon on your master server. The agent also runs on your servers as a daemon. At a user-defined time, the agent pulls down its updated system configuration information from the master.

Puppet’s instructions are written in the domain-specific language: Puppet. This language will remind you of JavaScript Object Notation (JSON), but it’s written in Ruby. (You can also use Ruby within Puppet programs.) However, you don’t need to be a developer to use it. Indeed, Puppet is regarded as being more system-administrator friendly than other DevOps programs such as Chef.

Puppet, the language, is not a shell language such as those used in Windows’ PowerShell or Unix and Linux’s Bash shell. Nor, is it a full-fledged language like PHP. Instead Puppet uses a declarative, model-based approach for IT automation.

Puppet models everything — the node’s current state, the desired end state, and the actions needed to move from one to the other — as data. Each agent “receives a catalog of resources and relationships, compares it to the current system state, and makes changes as needed to bring the system into compliance.”

You use this model to implement the desired configuration, a.k.a. policy, on your Puppet agent servers. The agent then issues your model’s marching orders to Unix, Linux, macOS, and Windows servers. These instructions are kept in files called Puppet modules.

In each module, you set up the following parameters:

  • Define the desired state of the infrastructure’s configuration using the Puppet language.
  • Simulate configuration changes before enforcing them.
  • Enforce the deployed desired state automatically, correcting any configuration drift.
  • Report on the differences between actual and desired states and any changes made enforcing the desired state.

Doesn’t sound much like your run-of-the-mill shell scripting does it? Once you get used to how Puppet does things, you’ll find it simple to deploy. You can use almost any programming editor you like to write Puppet modules. Old faithfuls such as vim and EMACS, and newer IDEs, such as Eclipse or Visual Studio, are all supported.

You don’t have to start from scratch with Puppet. There are many ready-to-run modules that you can either run as-is or use for your servers’ foundation. On Puppet Forge you’ll find almost 5,000 ready-to-run downloadable modules. While most of these are “run at your own risk,” others are supported by Puppet, while still others have been approved by Puppet. There’s also a 1 to 5 rating system for modules, so even if one isn’t approved or supported, you’re not downloading a pig in a poke.

Say, for example, you’re running CentOS or Fedora servers and you want to automate their network setup for your LAN. All you need to do is download, edit, and run Razoredge, a Puppet network module. There are also other ready-to-run Puppet modules by which to manage repositories from various version control systems for such popular programs as Apache, MySQL, and vcsrepo.

Puppet can handle more than just simple jobs. For example, if you want modules for the Docker container management program, the Jenkins continuous integration service, and even the OpenStack infrastructure-as-a-service (IaaS) cloud components, Puppet gives them to you.

Sound good to you? Well, you can, of course, install Puppet on your servers. It’s not that hard.

Before you do that, I’d try a Puppet Enterprise virtual machine (VM). This teaches you how to run Puppet through its paces by using quests on any powerful PC. If that works for you, you can deploy and use open-source Puppet.

If you need more help, you can run Puppet Enterprise 2016.5 on ten nodes for free. Puppet Enterprise comes with three additional features. These are:

  • Role-based Access Control (RBAC). This enables you to delegate tasks to designated administrators and groups. It integrates with directory services such as Active Directory and OpenLDAP.
  • Puppet Server Reporting collects metrics about your Puppet Server’s health and performance. This includes active requests, request duration, execution times and compilation load.
  • Event Inspection uses your Puppet logs to deliver reports on your node, classes and resources changes. This way you can get an easy view of what’s happening on your Docker-managed servers

Puppet Enterprise licenses start at $120 per node, including a standard support package containing bug fixes, a private knowledge base, and up-to-date software patches.

There’s also premium support, which really is premium. This comes with phone support for Priority 1 issues 24 hours a day, seven days a week, and unlimited cases, technical contacts, and free training vouchers. Pricing varies for this offering.

Is it worth it? I think so. I’ve used several DevOps tools, such as Chef, Ansible, Juju, and Salt. Each has its advantages, but Puppet is perhaps the most widely used of all of them and there’s a reason for that: It’s very good.

Try it for yourself. You’ll see what I mean.


Please feel free to share below any comments or insights about your experience with Puppet. And if you found this blog useful, please consider sharing it through social media.


About the blogger: Steven J. Vaughan-Nichols is a veteran IT journalist whose estimable work can be found on a host of channels, including ZDNet.com, PC Magazine, InfoWorld, ComputerWorld, Linux Today and eWEEK. Steven’s IT expertise comes without parallel — he has even been a Jeopardy! clue. And while his views and cloud situations are solely his and don’t necessarily reflect those of Linode, we are grateful for his contributions. He can be followed on Twitter (@sjvn).