How to Create a Custom Script Input Field in vRealize Automation

Mike Bombard
by Mike Bombard

Categories

A couple of months back I went through some training on the AWS platform. One of the use cases from the training that stuck in my mind was the ability to execute in-guest commands at launch using the User Data field. So many possibilities are opened up to end users using this technique! At that time, I went through an exercise to discover what it would look like to execute in-guest commands at launch using the User Data field in vRealize Automation. Shortly thereafter, reality set in, and I realized that, with the amount of work I already had on my plate between maintaining the custom code we had already written and upcoming development initiatives, I would likely never get to attempt to recreate this feature in vRA. So the idea just became another passing possibility.

 

To Code or Not to Code?

One of the many things that the SovLabs Lifecycle Toolkit (LCT) is capable of is the ability to execute scripts surrounding the provisioning of your resources. The scripts can be executed from within a provisioned node or from a separate pre-designated server. However, where the script executions in the LCT really start to become powerful is when you couple the logic in the script definitions with the templatization available as part of the SovLabs Template Engine, which is part of the foundational SovLabs Framework that extends across all of our modules. What I mean by that is that your script definitions do not have to be static. Just like most of our modules, you can use logic based on the request inputs to derive which scripts you are going to run. This provides your end-users with a data-driven approach to automated provisioning. 

In addition, you can take custom properties set during the request and pass them into the scripts as variables to affect the outcome of how your machines are provisioned. Finally, all of this can be done without writing a single line of code in vRealize Orchestrator. Your vSphere administrator, who has been using PowerShell and/or Bash scripts for machine provisioning for the last 5-10 years, doesn’t need to learn Javascript or ever step foot into vRO. The LCT is configured directly from the vRA Catalog, and all of the logic can be performed using the Property Dictionary and Property Groups. 

 

The Possibilities 

After seeing the LCT in action for the first time, I started to wonder what else could be possible with the module. One of the first things that came to mind was the AWS User Data use case mentioned above. What would it look like if a vRA catalog user were able to run custom scripts against each machine in a deployment? They could spin up a farm of Windows servers, and configure roles, features, and local administrators on all of the machines in the deployment. They could then come back and submit another request, but this time they install the Active Directory Roles and Features so that those servers are prepared to be configured as AD Domain Controllers. Maybe your organization already has a system in place using custom logic to address these different types of requests.

What I have found in working with this technology is that, if you build it, you are on the hook to maintain it. The SovLabs solution empowers your organization to achieve all of this without ever having to write a single line of code.

 

How to Set It Up

Let’s take a look to see what it would look like to configure this solution, but before we get started, here is the official documentation for the SovLabs Lifecycle Toolkit. There are five main steps, outlined below, to configure the SovLabs Lifecycle Toolkit to execute in-guest commands at launch using the User Data field in vRealize Automation.

 

Step 1: Create an Event Broker Subscription (EBS) 

The Lifecycle Toolkit lets you take control of exactly where in the provisioning process you want your provisioning steps to take place. When executing custom scripts in my demo environment, I want to be sure the scripts execute prior to the AD machineProvisioned state because I am using the SovLabs Microsoft Active Directory Module to place my machines in a build OU during provisioning to disable UAC. When the AD machineProvisioning state executes, it moves the AD Computer object into the final OU where UAC is re-enabled, which would cause any custom scripts requiring administrative level permissions to fail execution. By creating a custom Event Broker Subscription (EBS) using the SovLabs Manage Lifecycle EBS module, I can see where the default SovLabs EBS take place and then define exactly where in the process I want my scripts to execute. 

How to Create a Custom Script Input Field in vRealize Automation 1

Note that, in the screenshot below, you can see that the AD machineProvisioned EBS executes with a priority of 1500. I could create my new EBS to execute anywhere that has a priority of less than 1500, but I am just going to create them to run before any of the SovLabs machineProvisioned EBS run. So, I submit my EBS with a priority of 900, and a timeout of up to 10 minutes.

How to Create a Custom Script Input Field in vRealize Automation 2How to Create a Custom Script Input Field in vRealize Automation 3

Once the request completes, you can re-launch the “Manage Lifecycle EBS - SovLabs Modules” Catalog Item and see that the newly requested state(s) now show as a state in the Current Machine Provisioned EBS window. 

How to Create a Custom Script Input Field in vRealize Automation 4

Step 2: Create a SovLabs Lifecycle Script Definition 

Now that we have created a custom EBS, we need to create a Lifecycle Script Definition, and associate it with the EBS we just created.

How to Create a Custom Script Input Field in vRealize Automation 5

There are a few fields of note in the first section. A Lifecycle Script Definition is OS specific because of the different interpreters available per OS. Also notice that the “Type” set below is “Provisioned Node”. These script configurations are capable of executing directly from within the Guest OS of a provisioned node, or from a specific host. I selected Provisioned Node below because I want the specified script to execute within the Guest OS of the VMs that I am provisioning. In addition, the SovLabs modules are capable of executing scripts from the Guest OS through either VMware tools or through SSH (for a Linux OS; Windows supports VMware tools, WinRM, WinSSHD, or Cygwin sshd). 

How to Create a Custom Script Input Field in vRealize Automation 6

In the next section, you will want to specify an account that has root (or administrative) level access in the Guest OS. 

How to Create a Custom Script Input Field in vRealize Automation 7

In the final section, you can specify during which EBS state you want your script to run (I chose that 900 EBS state created earlier), and how you would like to evaluate the custom script for errors (if desired). But where the Template Engine really shines is in the script box. Sure, you could insert a static script here (this would also be capable of injecting variables in to your custom script if desired from Custom Properties set on the machine), but where would the fun be in that? Using the SovLabs Template Engine syntax, we are able to take in a Custom Property set on the Virtual Machine during deployment.  That singular custom property can include a one-line script, or a multi-line script input during the request. 

How to Create a Custom Script Input Field in vRealize Automation 8
How to Create a Custom Script Input Field in vRealize Automation 9

 

Step 3: Create a SovLabs Lifecycle Profile

Now that we have the Script defined (with templated values) we can create a Lifecycle Profile to apply to our Blueprint. 

How to Create a Custom Script Input Field in vRealize Automation 10

The Configuration Label section is important because if you want to use the SovLabs Property Toolkit to apply a data-driven approach to deploying your resources you could have multiple Lifecycle Profiles. If you have multiple Lifecycle Profiles, you can use the Property Toolkit and Template Engine to dynamically select the Lifecycle Profile based on inputs selected during the request. 

How to Create a Custom Script Input Field in vRealize Automation 11

The Modules and Scripts tab contains a lot of information, but in this post we are only going to scratch the surface of the capabilities inherent in LCT. In the Machine Provisioned PRE Scripts section, you’ll want to select the Script Configuration created in the earlier step, then you can submit the request. 

How to Create a Custom Script Input Field in vRealize Automation 12

After the request runs, you should see Lifecycle Profile under the Deployments tab.

How to Create a Custom Script Input Field in vRealize Automation 13

You should also have a new Property Group created in the Property Dictionary that includes all of the Custom Properties necessary for running the Lifecycle Profile. 

How to Create a Custom Script Input Field in vRealize Automation 14

Step 4: Apply the SovLabs Lifecycle Profile to your Blueprint 

As with most of the SovLabs modules, all you need to do to activate that module for a specific blueprint is associate the Property Group created for the module to the blueprint that you want it to run for. Navigate to your blueprint and then select the Property Group to associate it with the blueprint. 

How to Create a Custom Script Input Field in vRealize Automation 15
How to Create a Custom Script Input Field in vRealize Automation 16How to Create a Custom Script Input Field in vRealize Automation 17

Step 5: Set up your Custom Properties to allow for the input of a Custom Script

Now that the Lifecycle is applied to the blueprint, we need to create the customLinuxScript1 Custom Property referenced in the Script Definition. 

How to Create a Custom Script Input Field in vRealize Automation 18

Sample Request 

Next, I use the Custom Forms Designer in vRA and allow the user to input a custom script in to the field. Then I submit a request to test that the custom script is working as expected. 

How to Create a Custom Script Input Field in vRealize Automation 19

After provisioning, when visiting the URL for the newly provisioned server, I get the Apache default landing page.

How to Create a Custom Script Input Field in vRealize Automation 20

No Coding Means No Code to Maintain

This use case only scratches the surface of the possibilities available when using the SovLabs Lifecycle Toolkit, the SovLabs Template Engine, and the SovLabs Property Toolkit. Also, note that not once did I have to log in to vRealize Orchestrator or write a single line of code to execute any of this logic. 

The first step in providing reliable self-service automation for your CMP is starting a free trial.

Free Trial
Wave One Wave One
Wave Two Wave Two