I’m pretty excited about this post! I’ve been building up Puppet for vSphere Admins for a few years now but the final integration aspects between Puppet and vSphere/vCenter were always a little clunky and difficult to maintain without specific dedication to those integration components. Thanks to Puppet and VMware, that’s changed now.
Puppet announced version 2.0 of their Puppet Plugin for vRealize Automation this week. There’s a nice video attached, but there’s one problem – it’s centered on vRealize Automation (vRA) and I am working with vRealize Orchestrator (vRO)! vRO is included with all licenses of vCenter, whereas vRA is a separate product that costs extra, and even though vRA requires a vRO engine to perform a lot of its work, it abstracts a lot of the configuration and implementation details away that vRO-only users need to care about. This means that much of the vRA documentation and guides you find, for the Puppet plugin or otherwise, are always missing some of the important details needed to implement the same functionality – and sometimes won’t work at all if it relies on vRA functionality not available to us.
Don’t worry, though, the Puppet plugin DOES work with vRO! We’ll look at a few workflows to install, run, and remove puppet from nodes and then discuss how we can use them within larger customized workflows. You must already have an installed vRealize Orchestrator 7.x instance configured to talk to your vCenter instance. I’m using vRO 7.0.0 with vCenter 6.0. If you’re using a newer version, some of the dialogs I show may look a little different. If you’re still on vRO 6.x, the configuration will look a LOT different (you may have to do some research to find the equivalent functionality) but the workflow examples should be accurate.
Puppet provides a User Guide for use with a reference implementation. I’ll be mostly repeating Part 2 when installing and configuring, but reality tends to diverge from reference so we’ll explore some non-reference details as well.
Today, let’s build on version 1.0 of our Jenkins job. We are running builds against every commit, but when someone opens a pull request, they don’t get automated builds or feedback. If the PR submitter even knows about Jenkins, and has network access and a login, they can look at it to find out how the tests went, but most people aren’t going to have that visibility (especially if your Jenkins server is private, as in this example setup). We need to make sure Jenkins is aware of the pull request and that it updates the PR with the status. Our end goal is for each PR to start a Jenkins build and update the PR with a successful check when done:
To get there, we will install and configure a new plugin and configure our job to use the plugin.
As I’ve worked through setting up Jenkins and Puppet (and remembering my password!), I created a job to automate rspec tests on my puppet controlrepo. I am sure I will go through many iterations of this as I learn more, so we’ll just call this version 1.0. The goal is that when I push a branch to my controlrepo on GitHub, Jenkins automagically runs the test. Today, we will ensure that Jenkins is notified of activity on a GitHub repo, that it spins up a clean test environment without any left over files that may inadvertently assist, and run the tests. What it will NOT do is notify anyone – it won’t work off a Pull Request and provide feedback like Travis CI does, for instance. Hopefully, I will figure that out soon.
The example below is using GitHub. You can certainly make this work with BitBucket, GitLab, Mercurial, and tons of other source control systems and platforms, but you might need some additional Jenkins Plugins. It should be pretty apparent where to change Git/GitHub to the system/platform you chose.
Creating A Job
From the main view of your Jenkins instance, click New Item. Call it whatever you want, choose Freestyle project as the type, and click OK. The next page is going to be where we set up all the parameters for the job. There are tabs across the top AND you can scroll down; you’ll see the same selection items either way. Going from the top to the bottom, the settings that we want:
I’m finally getting back to Jenkins, which I started waaaay back in November (here and here). Unfortunately, I kind of forgot my password. Well, that’s embarrassing! I also want to redo the manifest using maestrodev/rvm which means starting over, so I need to back things up. The manual for Jenkins and the results on Google can be overwhelming sometimes, so I thought I’d share what I learned to hopefully save someone else.
There’s a few ways I found to recover your password. One suggestion is to disable all security, delete your user, re-enable security and allow signups, and then recreate the same user and things should just “work”. Part of the reason you have to do this is that once you disable security, you can’t change the password for your user; only the user can. That’s … frustrating.
Disable security by editing
/var/lib/jenkins/config.xml on my instance. I was able to get away with disabling it by changing
false, though the article suggests removing two other lines. Restart the service with
systemctl restart jenkins or equivalent and now you’re able to get in and recreate some users.
Last week, I discussed how to upgrade your Linux and Windows Puppet Enterprise agents with
puppet_agent. Today, we will look at two different ways to upgrade your Puppet OpenSource agents, first with
puppet_agent and then with
jlambert121/puppet. There are many other modules that you can use to manage puppet, some of which offer similar functionality that you may be able to apply some of these lessons to.
Why are we looking at two different modules today? I use jlambert121’s module to manage my puppetserver already. Unfortunately, it is puppet 4 only and I still had some puppet 3 agents hanging around according to puppetboard. I also have some other modules that are puppet 4 only, like the latest version of
puppetlabs/ntp. I could use
jlambert121/puppet to upgrade my agents that are already on puppet 4, but need something to help get my puppet 3 agents over the hump – that’s where
puppet_agent comes in. We will start with that.
I manage about 15 VMs in my home lab with OpenSource Puppet. Unlike Puppet Enterprise, there’s no Console to help you determine when agents stop checking in or encountering any problems applying their catalog. With only 15 agents it’s not a huge problem, but it always rears its head at the worst time. I decided to deploy Puppetboard at home to get a similar view to PE’s Console. As is always the way, we’re going to deploy that using a puppet module, Vox Pupuli’s puppet/puppetboard. Now, I’ve got Puppetboard running, but it’s served via HTTP and communicates with puppetdb via HTTP, so there’s room to improve. I’m not sure I’ll get to that, since this is on a private network, but something to keep in mind if you’re implementing this in a more sensitive deployment.
Special thanks to Tim Meusel for his assistance with some of the settings!
The first step is to add the module and its dependencies to the
.fixtures.yml. You may have a few of these modules already, but I’ve bumped them to the latest version.
We’ve all found ourselves anxiously awaiting a new module release of our favorite puppet module on the forge. It might be coming down the pipe today, next month, or who knows when, but you’re going to need it as soon as it’s released. The forge fairly recently announced an RSS feed per module. You can see this in your RSS reader, if you use one, or get email notifications with a number of services, a few of which are mentioned in that blog. I have wanted to play with If This, Then That for a while, so I decided to see if I could figure out how to get emails through it.
You’ll need an IFTTT account, at least one puppet module you want to receive alerts on, and of course an email address to receive the alert. Once you sign up for IFTTT, go to My Applets and choose New Applet. On the next page, it’s not obvious but click the +this text and it brings you to a selection page. Click on Feed, then New Feed Item. Now switch over to your target module on the forge and find the rss link. The pattern’s pretty easy, just add /rss to the module’s link.
Now click on +that and select Email, then Send me an email. If you want, adjust the contents of the email – I found the default field setup okay – and then hit Create Action. Click on the slider to the right of Receive notifications when this Applet runs and hit Finish
If you want to change anything, click the gear icon, adjust what you need and hit Save. Repeat for all the modules you want to receive notifications upon update. Here’s what an email will look like:
You can also view, update, and add additional applets using the IFTTT app for your phone or tablet. This might not be very pretty or exciting, but since I just want to get alerts without firing up an RSS reader, it’s good enough for me. Now to start updating my Puppetfile. Enjoy!
Yesterday, I tackled upgrading Linux Puppet Enterprise agents with puppet_agent and said I would give Windows agents a try next. It’s simultaneously extremely easy and really difficult to accomplish this! On the manifest side, it’s as simple as including the class in a profile for Windows agents. On the rspec side, we need to add a lot of custom facts and even mock up some functions. I also encountered an issue with version 1.3.1 that broke my rspec tests. Version 1.3.2 was released in February 2017 to address that.
As usual, let’s start with the rspec test updates. Here’s the starting tests and manifest for an empty
profile::base::windows, where nothing is really managed in the base profile yet.
Happy New Year, everyone! I know that when I last blogged before the holiday, I was getting settled in with Jenkins, but I really needed to relax during the break so I had to hold off on that. I promise, I’ll get back to that soon, but in the meantime I encountered an issue that needed fixed and required a little more than the docs provided.
I ran into an issue recently with Puppet Enterprise agents that weren’t able to purge some resource types properly due to the use of Anchors. This is an issue with Puppet, not the module in question, and it was fixed in Puppet 4.4.0 but affected nodes were running older versions. Of course, rather than upgrade the agents by hand, I decided to automate it. Puppet has an Upgrading PE agents: *nix page that describes how to do this in a few ways. The latter options require manual effort, but the first option, via the module
puppet_agent, can do this automatically for us. I diverged from the instructions a bit because I do my classifying with hiera rather than the PE Classifier and because there’s a missing step! (I’m trying to get that document updated, as well)
The guide says to install the module on the master and add some classification. To do this in a traditional roles and profiles setup using hiera as the classifier and with a monolithic controlrepo, we need to add the module to
.fixtures.yml, then add either a profile for
puppet_agent or add it to a base profile. I chose the latter. Let’s add the module first: