A vRealize Orchestrator/Automation Plugin for using Jenkins via XaaS

After recently doing some work on/with the vRealize Automation plugin for Jenkins, I got to thinking about doing the reverse of what it does and publishing Jenkins projects in vRA using XaaS. So, I’ve put together a vRO package to support this. The plugin will support builds that don’t have any parameters, as well as ones with (simple) parameters.

Part of the thinking here is some folks want to leverage already existing Jenkins projects with the vRA Jenkins plugin, but then also want to be able to do Day 2 operations. Rather than having them log into both interfaces, this provides a way to call the Jenkins project and handle Day 2 ops from the same interface. This set of workflows also supports the use of multiple Jenkins instances through the use of the REST host name as a parameter, while also having an option for a default host to use if one is not specified as a parameter.

The package file containing the workflows is available here. Or if you’re using vRealize Lifecycle Manager you should be able to add it as content and pull it from the GitLab repo ( https://gitlab.com/vcaptain/jenkins-vro).

The rest of this is going to be a walk-through of setting up a target host and a couple of examples using it.

Set Up

There are two workflows for setting up the REST Operations. One (add Jenkins Rest Operations) just creates the operations on an already existing RESTHost. The other (Add a Jenkins REST host and Operations) creates the RESTHost prior to adding the operations.

Once the operations have been added to a host you should see something similar to the image below in the vRO inventory.

Continue reading “A vRealize Orchestrator/Automation Plugin for using Jenkins via XaaS”

A walk through the vRA Terraform provider and multi-machine blueprints

I’ve been playing some with the Terraform provider for vRA that was recently posted on GitHub. If you’re new to terraform like it’s not real clear how to reference the various components of a blueprint, so I wanted to share an example of how to do it in a multi-machine blueprint with some software components.

(I’ll assume you’ve got Terraform and the vRA provider installed/compiled)

So taking a look at the blueprint we can see there are some custom properties lab.bp.prop1 and lab.bp.Prop2.

Continue reading “A walk through the vRA Terraform provider and multi-machine blueprints”

Using the Jenkins vRealize Automation Plugin

Background

Someone at work recently reached out to me because they were trying to make the vRealize Automation(vRA) plugin for Jenkins work with one of our vRA instances. This person was having issues getting it to work. I knew about the plugin because it’s one of the integration points we’ve been thinking about working towards, but not something I’d actually dug into much.

The plugin has some minimal documentation associated with it which was good for dead simple blueprints, but the ones my co-worker was trying use have a number of custom properties associated with them and we were struggling to get it to work. I think I’ve now got an understanding of how to decode the blueprint properties and supply the necessary info to Jenkins to make the blueprint work so I thought I’d share that here for others… It’s worth reading the documentation included on the GitHub page where the plugin source lives (https://github.com/jenkinsci/vmware-vrealize-automation-plugin) as a precursor to this.

The issue is trying to figure out how to build the values to populate the Parameter JSON field as shown below.

The TLDR version

I’ll post a longer version of this showing the process I went through to figure this out but for those who just want to get going here’s the skinny…

When talking about vRA there are 3 levels/types of parameters that one can set.

Request Specific
Blueprint specific
Blueprint component specific

Request specific includes things like the “Description” and “Reason for Request” fields etc. that are part of every IaaS-ish request.

Blueprint specific would include things on the Properties page for the deployment (ex: LT.jenkinsJobNumber below)

Blueprint specific components could be settings on a VM (ex below vSphere_Machine_1) or a software component etc.

Request specific values can be built using the following format:

So to populate the Description field the result would be:

For the blueprint specific properties the format should look like :

So as in the example above where we want to set LT.jenkinsJobNumber to a value of 123 we’d end up with:

For component properties its:

In the blueprint above the VM component is named vSphere_Machine_1. And if we want to set the LT.jenkins value to 456 we’d end up with:

{

So if we wanted to set all three of these values the form in Jenkins would have a “Parameter JSON” field for each of the JSON snippets and look something like:

These appear to be stackable. So if you wanted to set both the “Description” and “Reason for Request” fields on the deployment there would be a Parameter setting for each one of the fields.

Hopefully this will help other folks get this working faster.