Getting to Know the Puppet Development Kit (PDK)

Back to Listing

20 September 2018


This post is the first in a three-part series on Puppet module development using the Puppet Development Kit (PDK), adapted from a presentation for the St. Louis Puppet Users Group.

The Old Way

If you have been working with Puppet for a while, you’re probably familiar with the old way of creating a new Puppet module:

While this was the recommended way to build a new module, the quality of the various available module skeletons (the template used to create new modules) varied wildly. While you could find better module skeletons on the Puppet Forge, the default skeleton bundled with the Puppet agent was badly out of date with best practices until very recently. You could create your own module skeleton, but that required a lot of knowledge of the tooling. The module skeleton was only used as an initial template, so improving it (or creating your own) didn’t help with any existing modules. Honestly, often it was easier to create everything from scratch.

If you liked the old way, I have bad news for you… puppet module generate was deprecated in Puppet 5.4.0 and was removed in Puppet 6.

Enter PDK

The Puppet Development Kit (PDK) was announced in August of 2017. The goals of PDK were to make it easier to build high-quality Puppet modules that follow best practices, and to use the available Puppet code testing frameworks to avoid deploying bad code to live infrastructure.

PDK is an All-In-One set of tools for developing and testing Puppet modules. PDK includes a bundled version of Ruby plus various gems and utilities required for creating and testing Puppet modules.

PDK packages for various Linux distributions, Windows, and MacOS X can be downloaded from https://puppet.com/download-puppet-development-kit. For Linux users, they’re also available in the same repos that contain the puppet-agent package, so you can probably yum install pdk or apt-get install pdk.

The New Way


Why is this better?

PDK isn’t just generating a module from a skeleton and leaving you to figure out the rest. It is used for the entire lifecycle of a module. In the example above, we start by creating a new module, then fill in classes, defined types, and tasks using PDK. When the templates that are used to create those files are updated, replaced, or customized, some of those changes can be applied to some of the files in the module with pdk update. (More on that in Part 2…)

Testing is fully baked in. Each new class or defined type gets a unit testing skeleton with no extra effort. For example, when you run pdk new class modulename::subclass (as in the above example), PDK creates manifests/subclass.pp (the class code placeholder) and spec/classes/subclass_spec.rb (a barebones unit test). PDK is also used to run smoke tests (pdk validate) and unit tests (pdk test unit). As a bonus, interaction with Ruby tooling (bundle, rake) is generally not required like it was if you did unit tests before PDK, although it is still possible to use those tools if needed.

In addition, the default templates used by PDK include lots of goodies that weren’t in the old module skeleton:

  1. Configuration files for Travis CI, GitLab CI/CD, and AppVeyor
  2. operatingsystem_support and requirements in metadata.json
  3. Git configuration (.gitignore, .gitattributes)
  4. Puppet Strings in generated code

Oh, and did I mention that puppet module generate was deprecated in Puppet 5.4.0 and was removed in Puppet 6?

Converting Existing Modules

What if you have an existing module and want some PDK goodness? That’s (sort of) easy:
$ pdk convert
Ensure that your module is committed into some kind of source control before converting because the process is somewhat destructive. Certain files (metadata.json, specifically) will be updated, and others (Gemfile, Rakefile, .gitignore, etc.) will be overwritten.

In the next installment, we’ll discuss the conversion process in more detail.

Click here to learn more about how Onyx Point, Inc's professional services and development teams can help you.

Steven is a consultant and trainer for Onyx Point, focusing on Puppet, compliance automation, and all things DevOps.

At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles

  • Customer First.
  • Security in All We Do.
  • Pursue Innovation with Integrity.
  • Communicate Openly and Respectfully.
  • Offer Your Talents, and Appreciate the Talents of Others

puppet, pdk, rspec, testing, programming, technical

Share this story

We work with these Technologies + Partners

puppet
gitlab
simp
beaker
redhat
`
AFCEA
GitHub
FOSSFeb