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.
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.
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.
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.
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).
In the next section, you will want to specify an account that has root (or administrative) level access in the Guest OS.
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.
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.
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.
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.
After the request runs, you should see Lifecycle Profile under the Deployments tab.
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.
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.
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.
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.
After provisioning, when visiting the URL for the newly provisioned server, I get the Apache default landing page.
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.
