It’s time to get started installing Jenkins for use with Puppet. I’ll be installing this in my home lab on a VM called jenkins (so inventive, I know) as an all-in-one server for simplicity. I don’t know Jenkins very well, so I don’t know what I should be doing for masters and build servers, but my home lab needs are small anyway. I gave it two cores and 1 GB of RAM, which I think is on the low end for Jenkins. My initial exploration led me to believe I’ll need to install Jenkins as well as RVM since my base OS image is CentOS 7 (Ruby 2.0.0) and the current Puppet 4 AIO build is against Ruby 2.1.

I’m using Puppet and the rtyler/Jenkins module to set up Jenkins since I don’t know anything about its innards. Down below, you’ll see that I installed RVM by hand, after which it occurred to me that there’s a perfectly cromulent maestrodev/RVM module that I’ve used in the past – something I may change out later, but I already wrote my manifest, so I’m going to share it anyway!

I used Jenkins jobs to experiment a lot with this setup, such as enabling RVM on a job and seeing what errors showed up in the log, but I’m going to hold off on showing that magic until the next article. I will still explain where portions of the manifest came from, just without the actual errors.

Before we go any further, make sure you have the Jenkins module and its dependencies added to your Puppetfile, .fixtures.yml, and wherever else you might need to track it.

First, we need a Jenkins role. This is pretty simple – though again, maybe a refactor that separates RVM would require an additional profile::rvm or similar:

class role::jenkins {
include profile::base # All roles should have the base profile
include profile::jenkins
}

Easy, peasy. The profile is a little more detailed, especially with RVM entwined. Let me show it, then explain it:

We start with an optional parameter for plugins. I believe you can manage plugins through Jenkins itself if you don’t want Puppet to manage it; I’m not sure what happens if you do both. Next, we include the Jenkins module. We’ll set some parameters through Hiera in a bit. We have a Sudo configuration for the Jenkins user so it can run YUM installs via Sudo without a password or TTY. I’m not sure how necessary that actually is since that was primarily to install RVM, which ended up being done elsewhere in the end.

If the $plugins parameter has any values, we iterate through it and install the listed plugins. You can find a list of plugin IDs here, or look for the Plugin ID field on a plugin page. For example, the Puppet Enterprise Pipeline Plugin is called puppet-enterprise-pipeline.

Next up is the list of packages that RVM relies on CentOS 7. Not only is RVM entwined with Jenkins, but it’s tied to the OS in use. Another reason to migrate to the RVM plugin. Finally, we have a firewall rule to allow inbound port tcp/8080. If you plan to hook this up to GitHub or another external system, make sure you allow this through NAT/firewall policies on your edge, as well.

Finally, here’s my Jenkins Hiera data. I’ve split the plugins into those my research suggested I will need versus the indirect dependencies of those plugins. I don’t actually know what plugins I will end up using, so the split will allow me to remove individuals later and then test the dependencies. Dependency tracking remains the worst.