Adding a Puppet Task to an existing module using PDK
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 does 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 CM 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 CM setup and I was very proud of my module (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:
- Install my module
- Install a special puppetclassify gem
- Run a complex puppet apply from the command line with a lot of parameters
- Do a Puppet run
- 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 the 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 by 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 travis-ci.org 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
- a Puppet linter,
- a metadata linter,
- a syntax checker
- Rubocop (for any ruby code)
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 init.sh. I updated the init.sh 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) the user was 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 1 parameter for specifying the git url.
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 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 success Task run looks like:
Summary
I was able to add a Puppet Task module to my existing module with about 2 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 re-evaluate 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.
