Published on 31 May 2018 by

Editor’s note: This post was originally published on Medium. We are republishing it with Abir’s permission.

Screenshot of pe_code_manager_easy_setup module

About a year ago I created a module named pe_code_manager_easy_setup for automating the Puppet Enterprise (PE) Code Manager (CM) setup. It lets you do the following things:

  • create a user for doing deploys
  • configure the PE Master node group
  • generate a ssh public key
  • generate a webhook URL

It was meant to be a “once and done” module. Once you’ve got Code Manager set up you won’t need to set it up again unless you need to make changes, and it tends to be one of the first things you do after installing PE.

While my module simplified the Code Manager setup and I was very proud of it (it’s been downloaded over 4,000 times!), I recognized that even my module had a complicated setup. You had to do the following from the command line:

  1. Install my module
  2. Install a special puppetclassify gem
  3. Run a complex puppet apply from the command line with a lot of parameters
  4. Do a Puppet run
  5. Grab the SSH key and the webhook URL after the module finished, and put them into your version control (VCS).

When I created the module there was no such thing as Puppet Tasks or Puppet Development Kit (PDK). Once Puppet Tasks was released I was eager to write my first Puppet task, and I realized I could easily add a Puppet task to my existing module.

Using PDK

PDK is a “package of development and testing tools to help you create great Puppet modules.” In other words, PDK makes your life easier when writing Puppet modules. Plus, when you upload a module created with the PDK to the Puppet Forge you get a nifty pdk badge.

pdk convert

Any time I create a new module from scratch these days I use pdk new module to get started. It asks me a few questions and then generates scaffolding for my module. However, I used pdk convert this time. pdk convert lets you convert an existing module to a standardized PDK module with an infrastructure for testing it. This allowed me to use PDK tools for creating classes, defined types, and tasks in my module, as well as validating and unit testing it. pdk convert also generates a series of files including Travis CI and GitLab CI configuration files.

Adding CI to my module

Since my module was posted on GitHub in a public repo I decided to set up Travis CI. PDK generated a .travis.yml file so all I needed to do was log into and turn on Travis for my repo. The next time I checked in some changes to my module, a build ran through Travis CI. By default, the PDK-generated .travis.yml runs the module code through

Rubocop uncovered a few issues with my Ruby code, and the linters and syntax checker helped me clean up some Puppet code. This benefit alone was worth making my Puppet code PDK-compliant.

Creating the task

Once I got my build passing in Travis CI I was ready to add a task to my module. To do this, I just opened up my terminal, went into the directory containing my module, and ran:

pdk new task init

This generated a tasks folder in the root of my module and 2 files: init.json and****. I updated the with a simple bash script to automate the setup steps I mentioned before.

One of the nice side effects of adding the task to my module was that it gave me the opportunity to simplify the functionality. For example, my module asked the user what version control system (VCS) they were using. I realized that this step wasn’t necessary so I didn’t make it a parameter for my task. I realized that I only really needed one parameter: the Git URL. So I updated the task metadata to have one parameter for specifying the Git URL.

Screenshot of running a task

Outside of fixing some of the Ruby warnings and syntax issues I made no other changes to my original module code to make it work with the task.

Displaying results in the PE console

The PE console will show the output of a Puppet task. I thought this would be a great place to show the progress of the task, but also display useful information to the user. Earlier in this article, I mentioned that once the module finished, I still needed to log into the Puppet master and get some information put into their VCS (Step #5). I realized that I could just display this information in the task output. This way I didn’t need the user to log back into the Puppet master. Here’s what the output of a successful task run looks like:

Screenshot of what a successful task run looks like


I was able to add a Puppet Task module to my existing module with about two hours of effort. Thanks to PDK, I was also able to make my module better by adding a CI. I was also able to take a moment to reevaluate my module and make things simpler. After I updated the module with a task, the downloads have almost doubled month over month. I highly recommend adding Puppet Tasks to your existing Puppet module and using PDK to make your module even better.

Abir Majumdar is a sales engineer at Puppet.

Share via:
Posted in:

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.