published on 6 October 2014

When you go to your local Tesla dealership to order your new P85, you’re going to tell the fleet manager what features you want it to have: dual chargers, XM satellite radio, the mapping system, and those fancy red brake calipers. You’re not going to explain the steps the factory should use to build it, or how they should go about shipping it to the dealer.

That’s the difference between a declarative language and a procedural language: You tell Puppet what you want the system to look like, not the steps to get there. For configuration management especially, this approach makes a lot of sense. You shouldn’t have to think about building a LAMP stack by installing Apache, MySQL and PHP, then tweaking php.ini, then enabling mod_php, and then….well, you get the idea. You should just be able to specify what you need, and have it all fixed up and ready to go.

I’m a Puppet trainer, and some of the people I meet at Puppet trainings have been writing procedural scripts all their professional lives. They feel intuitively that this is how it has to be done. It can take some time to fully realize that Puppet allows you to step back from all that, and simply describe the system: “Be a web server with Apache, MySQL and Wordpress,” and then let Puppet make it happen. But it’s worth taking the time to understand how state modeling works, because Puppet’s declarative language can take away much of the tedium that’s such a big part of many sysadmins’ jobs.

Once people really grasp state modeling, they soon realize that Puppet’s declarative language is quick, concise, and repeatable. You can apply a Puppet manifest to as many machines as you want, and be confident they’ll all be equipped the same way.

If you do configuration management with scripts, you’re responsible for any variations on the original state, for catching errors, for checking versions, and for adapting to differences. If you do configuration management with a declarative language like Puppet, someone has already done all that work for you — and because it’s been used by thousands of people, it’s all tested, multiple times over. You’ll have a reliably configured system that’s periodically verified for compliance, and if anything changes, you’ll know right away.

The benefits of Puppet’s declarative language

The Puppet DSL is tested. Thousands of people use Puppet modules, and they have, in effect, tested them for you. If you write a unique script, it has just one user — you. So you’re the person responsible for checking whether it works, catching and fixing every error.

It’s repeatable. Once you run Puppet, you know the computer will be configured as it should be, in the state you’ve defined. And you can use a manifest to configure as many machines as you need, even on multiple platforms.

Consistency. No matter what state your servers start in, once you run Puppet, they’ll end up exactly as you described. If you update your Puppet Apache module, every Apache machine managed by Puppet will update to the new configuration automatically. Your systems will throw fewer errors, and you’ll swear less.

You save time. It’s much faster to run Puppet than to write a script. If a machine is accidentally configured incorrectly, Puppet will find the change and remediate it (unless you run Puppet in no-op mode, which is certainly an option).

Self-documentation. Puppet manifests are so simple, anyone can read and understand them, including people outside your IT and engineering departments.
Comparison of Puppet's declarative language with a procedural language
Auditability. Many regulatory bodies accept Puppet manifests as proof of compliance. Whether it’s an external or internal audit, it’s great to have proof that you pass. And you can easily validate to your own executives that compliance requirements have been met.

Puppet’s declarative language allows you to communicate the expected, desired state, not only to Puppet, but to the other humans on your team. It’s easy for you to write, and easy for others to read and understand...even your boss.

Ben Ford is a training solutions engineer at Puppet Labs.

Learn more

  • Pace your own Puppet learning with the Puppet Labs Workshop, which offers quick 10- to 15-minute online courses, all for free.
  • Try out the Learning VM, with fun quests that take you through your Puppet learning a step at a time.
  • Check out our options for Puppet training — public and private classes available. You might even get Ben as your teacher!
Share via:

Self documentation is a myth. I've inherited enough code in my career that I ended up ripping out and starting over from scratch because it was totally unreadable.

Ahem... this is exactly the kind of thinking that allowed our industry to coin the term "Big Ball of Mud". Every developer has that innate sense that what has been done before is "less", and my mousetrap will set the world on fire.

Exactly! Instead of instead of reinventing again and again the same old tired shell scripts or in-place sed on config files and hoping they won't break, we just let Puppet do it for us. So much more repeatable.

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.