Decision Driven Provisioning with XaaS
To me, the power of vRealize Automation has always been how easy it is to take square pegs and fit them into round holes. Generally this capability comes in the form of leveraging “Anything as a Service”, also known as XaaS. XaaS allows you to take any vRealize Orchestrator workflow, and bind it to a catalog function. This might be a blueprint or an action (day-2 operation).
Leveraging XaaS to deploy Operating System blueprints exposes some very powerful possibilities. We can leverage code to help dictate the characteristics of a provisioned resource. Decision Driven Provisioning leverages simple “if / then” statements to apply specific properties to augment our machine builds. If you aren’t familiar with what Custom Properties, I suggest taking a look at the Custom Properties guide here.
Custom Forms (vRA 7.4) vs XaaS
When we create an XaaS blueprint, we also expose the ability to change the look and feel of the default form (as you’ll see below). This functionality has existed when leveraging XaaS since the early days (remember Advanced Service Designer?) and prior to the most recent release, was the only way to modify the look and feel of a catalog request. In vRealize Automation 7.4, we introduced the Custom Forms Designer. Check out the Custom Form Designer Documentation for more infromation on building and consuming this new service.
There’s a reason I bring this up. A common question we’ve received since the new release is “Since vRA 7.4 has custom forms, why would we use XaaS for provisioning?”. Understand that the Aything as a Service engine and Custom Forms Designer typically address different usecases. If your only reason for leveraging XaaS as to change the look and feel of your catalog request, then absolutely, moving to Custom Forms Designer is a great idea! You’ll still need to do some keyboard work around making sure your integrations are covered through Event Broker Subscriptions and Lifecycle States. Often, the difficulties with these can (at times) be mitigated easier leveraging XaaS for the initial request as opposed to the vanilly blueprint.
In the future we’ll be releasing a lot of content around interesting ways to leverage Custom Form Designer, as it’s an incredible new feature that is really going to open up some interesting doors. For now, back to our XaaS provisioning…
Getting Started
To get started, I’ve uploaded a vRealize Orchestrator code sample to the VMware Code Sample Exchange.
We will use this workflow to bootstrap our XaaS request. This workflow is used to simplify the following tasks:
- Determine the specific Catalog Item tied to a Business Group
- Gets the Provisioning Request
- Gets the Provisioning Request JSON Data
- Requests a Catalog Item using the modified JSON data.
After importing the workflow into vRealize Orchestrator, right click on it and select edit workflow. If we tab over to the “Schema” tab and select the “Scriptable Task”, we can read the comments left in the code sections, which explain to you the steps needed to make this functional.
Required Fields
In the comments of the script task, we see that the following properties are required
- busGroup
- cafeHost
- osCatalogName
Firstly, we need to update the attribute on the “General” tab to specify our café host. Moving forward, we need to provide values for a Business Group (busGroup) and a Blueprint we want to work with (osCatalogName). Our busGroup property is actually setup as an input and it’s just a string so we can type it in or have vRealize Automation provide it for us in the form. In my environment, the business group I’m working with “Humblelab”. For our Blueprint, we will use a Ubuntu Server 16.04 catalog item I already have staged in my lab. We can solve for both of these by modifying the code block as follows:
With these values in place, we can start building actual decision driven logic into our workflow. In our example, we will be applying custom properties based on drop downs and selections made during the provisioning request.
Adding Inputs – Network
First, let’s switch over to our “Inputs” tab and click the “Add Parameter” button. Click the “arg_in_0” entry, and change its name to “Network”. Select the “Presentation” tab on the top, and select our new Network input. The presentation tab is how we define the way a request will be presented to end users when they are making a request. Click the blue half triangle on the right hand side, and select “Predefined Answers”. This creates an empty box, which we need to populate with values. Click on “Not Set” and add 3 values
- Common Server
- Web
- DB
Switch back to the “Schema” tab, ensure our script task is selected, and select the “IN” tab. Click on the “Bind to workflow parameter/attribute” and check the box for Network and click “Select” on the bottom right.
When we bind a parameter in this way, we expose the value it contains to the scripting engine within vRealize Orchestrator. When we return to the “Scripting” tab and scroll down, you’ll see a section I created that references applying properties by dot notation. This is the section where we are going to apply our next set of logic.
Adding Logic – Networking
We’re going to assign a specific logical switch based on what is selected in the network field. In order to determine what Property we need to modify, we will consult the Custom Property reference.
So for my environment, we can apply the following code block:
if (Network == "Common"){
catRequestJSON.Ubuntu1604.data["VirtualMachine.Network0.Name"] = "Common-VLAN"
} else if (Network == "Web"){
catRequestJSON.Ubuntu1604.data["VirtualMachine.Network0.Name"] = "Web-VLAN"
} else if (Network == "DB"){
catRequestJSON.Ubuntu1604.data["VirtualMachine.Network0.Name"] = "DB-VLAN"
}
Notice how we changed the way we apply the properties? Do you know why this is? Because the Custom Property required is “VirtualMachine.Network0.Name”. The Custom Property itself has dot notation in it, which the JavaScript interpreter thinks it needs to step through. This would case our request to fail. To correct this, we put the Custom Property in brackets to “escape” them out. An important item to note is that the above configuration will work if the network is a DHCP network (getting its IP Address automatically…) however if you need to apply a static IP you’ll need to leverage those properties as well.
Adding Inputs – CPU and Memory
Another usecase we can address is presenting CPU and memory fields in the request form to help size our request. Graphically, we can represent these with slide bars instead of the existing blueprint forms which are admittedly not attractive as shown below:
Since CPU and memory are core components of any blueprint, these values are simply exposed via the actual blueprint request. The fields are appropriately named “cpu” and “memory”. We could setup an if/then statement and build a “small” “medium” and “large” option, but for our usecase we will stick with freeform selection.
Since we’re doing this in XaaS, we need to create 2 new inputs for CPU and memory. A great way to create input properties is from within the “IN” tab of the Schema section. When you select the “Bind to workflow parameter/attribute” option (below):
You will see and option to “Create Parameter/attribute in workflow” which will also make it available for binding:
I’ve named the properties in my case “inputCPU” and “inputMemory”, creating them both as “number” types. An example is below:
From a script block perspective, we can drop the following code into our Scriptable Task:
catRequestJSON.Ubuntu1604.data.cpu = inputCPU
catRequestJSON.ubuntu1604.data.memory = inputMemory*1024
Why do we multiply the memory by 1024? Because the provisioning request expects the input to be in megabytes. Setting it up this way will allow us to present a “Gigabytes of Memory” menu item to our end users, which is generally a bit more understandable for people provisioning systems.
Final Example – Datacenter Selection
For our final example, what if we wanted to abstract the datacenter location for our end users?
Let’s create 2 new input named “Environment” as “string” types and modify the “Presentation” tab to options of “Production” and “Development”. Once that is in place, we can then add the following block to our provisioning request:
if (Environment == "Production"){
catRequestJSON.Ubuntu1604.data["Vrm.DataCenter.Location"] = "Sacramento"
catRequestJSON.Ubuntu1604.data["Vrm.DataCenter.Policy"] = "Exact"
} else if (Environment == "Development") {
catRequestJSON.Ubuntu1604.data["Vrm.DataCenter.Location"] = "Los Angeles"
catRequestJSON.Ubuntu1604.data["Vrm.DataCenter.Policy"] = "Exact"
}
It’s important to note that in order to use this example you will need to have setup your vRealize Automation instance to have the above datacenter names as well as have created and associated the appropriate datacenter policies to compute resources/reservations.
This block will evaluate the environment binding, and if it is set as “Production” the machine will deploy to the Sacramento datacenter. If it’s set to “Development”, it will deploy to the Los Angeles datacenter.
With this complete, we can move forward with creating the catalog item.
Creating The Catalog Item
Log into vRealize Automation as an administrative user and select the “Design” tab. Select “New” on the top. You’ll be presented with an Orchestrator workflow search window. If you don’t see your workflow, you’ll need to run a “Data Collection” on vRealize Orchestrator under Infrastructure > Endpoints.
Select the workflow, and then press next on the bottom right. Name your workflow, and add a description as needed.
Select Next when done and we will be presented with a form builder to create the request form.
Building Our Form
For the first 2 fields we will have vRealize Automation fill those fields in automatically, and then hide the field so the user can’t see them.
First we will apply the Business Group settings:
Remember to select “Apply” afterwards to make sure the settings stick.
Next we apply the Requestor settings:
We don’t need to make any changes for Network or Environment, but we do want to switch CPU and Memory to be slide bars.
Starting with CPU, we will adjust it to be a slide bar as shown below:
The constraints tab will be used to set restrictions around how the content is entered or interacted with in the catalog. In the case of CPU we need to apply a minimum CPU value, a maximum CPU value, and the amount it should increment as you increase or decrease,
We then do the same thing for memory, however, with some slight changes to our minimum/maximum/increment values:
Select, next twice, and click through to finish.
Ensure you select your XaaS blueprint in the blueprint list and publish it. Add it to your desired entitlements as you would any other blueprint.
Once entitled, the catalog item will appear in your catalog items list:
Selecting “Request” should present us with the form we just built: We can populate this form with the values we need, and submit
And if we monitor our request in vRealize Orchestrator we should see it process successfully!
And if we look at the log output, we can see that it successfully processed!
Considerations
A few gotchas exist when provisioning with XaaS. First of all, the XaaS request is going to create 2 “requests” each time. The first XaaS request will complete, which is ultimately just the request to CALL the real blueprint. The subsequent request is the one actually provsioning the real deployment. This is a key distinction we need to be aware of. The request will be submitted under the service account that Orchestrator was used to bind with vRealize Automation. This means you will need to do subsequent automation to “reassign” that final deployment to the original requestor. Event Broker Subscriptions (EBS) can accomplish this easily, however this falls out of the scope of this post.
In Closing…
This post is simply an introduction to the world of XaaS for machine provisioning; and we’re barely scratching the surface. Did you know you can trigger workflows to run based on value bindings? Slack notifications on deployments, SRM protection for “Production” classified systems, or other system integrations are all possible with XaaS. Stay tuned for my next installment where we dive into some of these advanced use cases!
