Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine – Part 3

In Part 1 and Part 2 of this series, we created three inputs for our vRealize Automation blueprint: Production, WordPress, SOX compliance.  These three inputs correspond to property groups that allow us to associate multiple custom properties to a single input. Using property groups allows us the ability to templatize how each input affects the outcome of a request.  In this article, the Genie that we’ve previously released from the proverbial bottle is about to take form, as we walk through how these three inputs come together to determine the outcome of our request.

Let’s look at how the different input options impact the different modules.

The table doesn’t include everything, but reflects only the impact that the three inputs have on the outcome of the VM request. Microsoft AD wasn’t included in the table because it didn’t display well, but we’ll take a closer look at AD later.  We also aren’t focusing on the impact that other vRealize Automation factors have on the request, including items like business group and placement. It’s important to note that I am using very simple property joins to formulate my results. However, I am a huge fan of using property joins because they promote standardization and are easy to maintain.

The SovLabs Template Engine supports many different operators including if/else logic, case statements, and dozens of others filters that can be used within the language to achieve your desired outcome.

Custom Naming

We won’t go into the full configuration details of the SovLabs Custom Naming module in this article, but we’ll break down the data points above.  If we look at the convention that is defined in our naming standard, taking our three provided input values, we get an outcome of pwps.  Now, if we were to define a location property at our compute resource with a value of “at” and add that to our convention — {{env}}{{app}}{{comp}}{{location}} — we would have an outcome of pwpsat.  Last, we add our unique sequence to the convention and end up with our final hostname pwpsat001.

IPAM

Similar to what we just covered from our naming standard, we’ll be using property joins with the SovLabs IPAM Module to determine which IPAM profile should be associated with the request.  The result will determine the network on which the workload will be placed.  If we use the location property defined at our compute resource we should ultimately end up with a convention that looks like {{env}}{{app}}{{comp}}{{location}} resulting in prodwebsoxat as the name of our IPAM profile.

In order to invoke the SovLabs IPAM profile we define a property and then set its value:

Name: SovLabs_IPAMProfile_niv0           Value: {{env}}{{app}}{{comp}}{{location}}

The Template Engine will substitute ‘prodwebsoxat’ for the value and then produce the desired IPAM Profile name to be assigned, thereby determining the network that the workload will be placed on and acquisition of the IP address from the configured IPAM solution.

vCenter Folder Placement

vCenter Folder placement, although not specifically a module within SovLabs, it is a feature of vRealize Automation.  The VMware.VirtualCenter.Folder property in vRealize Automation uses a static value, limiting its function and usefulness.  The value needs to be defined such that it would look something like this: folder1folder2folder3.  Doing so would require the user to define a property and a different value all over vRealize Automation.  You could potentially leverage overrides, though there is no guarantee you can accomplish all your desired use cases.

When using the VMware.VirtualCenter.Folder property or any non-runtime property in vRealize Automation with the SovLabs Property Toolkit & Template Engine logic, you can turn the value into a dynamic value.  Using the value of {{env}}{{app}}{{comp}} would translate to a folder path of PRODWORDPRESSSOX and vRealize Automation would place the resulting virtual machine into the desire vCenter.

vSphere Tagging

vSphere tagging is a module that, in my opinion, doesn’t get enough attention or credit. Tagging in vSphere can be extremely powerful and valuable. Tags can be used to drive a number of items when it comes to automation, including items like vRealize Operations, vRealize Business, Backup Solutions, and many other third party products that integrate to vCenter and support vSphere Tags on top of the benefits you gain in vCenter itself.

There are a number of ways that users can assign tags to a request in vRealize Automation.  First, you can statically assign the tag at the location that makes the most sense. If I wanted to assign a cost center tag based on the business group, I could simply add the following property (SovLabs_CreateTags_VMW_something_unique_here) and value to each business group.

Property:  SovLabs_CreateTags_VMW_CostCenter

Value: {  “name”: “0123456”, “category”: “Cost Center”, “cardinalitySingle”: false, “tagDescription”: “BusinessGroupName_ cost center”, “categoryDescription”: “Owner Cost Center”  }

However, in my example, I am leveraging the SovLabs Property Toolkit, so the setup is a bit different, which reduces overall complexity and redundancy in the configuration. I’ve defined all my tag properties in a vRealize Automation Property Group and assigned that group to all my vSphere EndPoints so they will always be applied to all vSphere deployments with one slight modification. I am using the SovLabs Template Engine to put property placeholders in place of the “name” and the “tagDescription”:

Property:  SovLabs_CreateTags_VMW_CostCenter

Value: {  “name”: “{{cost_center}}”, “category”: “Cost Center”, “cardinalitySingle”: false, “tagDescription“: “{{bg_name}}_ cost center”, “categoryDescription”: “Owner Cost Center”  }

By defining my tag properties in this manner, I don’t have to include the vSphere tagging syntax everywhere in vRealize Automation. And, I need to define it only once in a single property group.  Then I define the values I want passed in and my tags will always be applied correctly to my vSphere deployments.

OS & Customization Specifications

Here’s another example of using the SovLabs Property Toolkit & Template Engine to determine the value of native vRealize Automation Properties.  Much like with vCenter folders, we are simply using the SovLabs Property Toolkit & Template Engine to meet your business logic and determine what the resulting value should be.

In this example, I’ve created property groups to define my applications and within the property groups I created, I’ve defined which vSphere template & customization specification should be used for that application. Very simple, yet very effective and powerful, without having to ask my requestor what OS they need.

Although this example is very basic, there are many ways to utilize this capability to meet your specific use case. As another example, let’s look at an environment with multiple domains.  To use customization specifications to perform domain joins, we need separate customization specifications for each domain. This task becomes problematic within vRealize Automation because you typically need to create a different blueprint of the different domains.

Using the methodology discussed in the previous parts to this 3 part series, if we include the template and customization specification in our application property group, we can template out the value for CustSpec to something like {{domainCustSpec}}. Doing so allows us to obtain the customization spec via another mechanism, possibly as an additional input or incorporated within another inputs property group or even defined somewhere else within vRealize Automation.

CPU, CPU Cores, & Memory

CPU, CPU Cores, and Memory are also examples of how you can drive native vRealize Automation components using the SovLabs Property Toolkit and Template Engine.  In this example I’m driving the sizing of each deployment based on the chosen application.  Each deployment is defined per application property group and environment to which it is deployed, giving us the ability to relate our inputs and make decisions based on the values of other selections.

VMware released the Custom Forms Designer in vRealize Automation 7.4 and I really like it.  Custom Form designer allows me to assist Customers in creating a front-end request form that dynamically changes to meet their needs based on the requestors selections.  This functionality allows you to create end-to-end fully dynamic requests within vRealize Automation in which Custom Forms handle the dynamic UI and SovLabs handles the dynamic logic on the back-end.   It’s the perfect marriage of technologies!

Application

Application input is an interesting value because it plays a critical role in determining what is being deployed.  It does so by aiding in the determination of the deployment size as shown below. The Application value is also responsible for determining the template as well as the customization specification that is being assigned.  Let’s not forget the “how”: we are determining what application(s) are actually going to be deployed against the resulting machine as well. This determination can be achieved a number of different ways.

(1) We could leverage the SovLabs Ansible Tower Module to associate the machine with Ansible Tower Inventories or specifically assign an Ansible Tower Profile that dictates the Ansible Tower Playbooks to be assigned.

(2) If you are a Puppet shop you could utilize the SovLabs Puppet Enterprise Module to associate Puppet manifests to the deployment to deploy your application.

(3) If you don’t use either of these solutions, SovLabs has a solution that will allow you to execute your custom scripts against both Windows and Linux deployment, which will achieve the same result.  The SovLabs LifeCycle Components Toolkit allows more than just the ability to execute scripts, but for the purposes of this article that is where we are going to focus.

The LifeCycle Components Toolkit allows you to execute scripts against the provisioned machine as well as existing machines in your environment.  Yes, that’s right: if you wanted to register the deployed machine against a monitoring solution after it has been successfully deployed, you can invoke a script to do just that.  If you wanted to call Microsoft SCCM to invoke an application deployment, you can do that as well. You have the ability to execute scripts against Windows or Linux on both deployed and existing machines — before or after machine deployment — and you can do it via VMware Tools, SSH, WinRM, or WinSSH.

I know what your thinking: those are some great options!  That is exactly what SovLabs is all about. Building enterprise grade solutions that provide our Customers with the options they need, something you don’t get when having integrations built custom to your specific use case.

vSphere DRS

In my example, I’m driving the vSphere DRS host group assignments based on compliance.  If it’s non-compliant, it will go in to one DRS Host group. If it is compliant, it will go into a DRS host group for any machines that are SOX compliant.  The compliance input in this example is also linked to a property group for the specific option chosen. In the property group I have defined the SovLabs vSphere DRS property and value of the profile I want assigned.

Property Name: SovLabs_DRS  Property Value: Compliant

Active Directory

Although I didn’t include Active Directory in my table, it works very much like all the other examples I’ve covered.  I have created a single Active Directory Configuration using the SovLabs Active Directory Module.  Within that configuration, I’ve created logic that drives a number of properties associated with the request via the property groups assigned by my inputs, and a few additional values that are defined elsewhere within vRealize Automation.

Here is my logic from my Active Directory Configuration:

{% if ouEnv == ‘development’ or ouEnv == ‘lab’ %}  OU=Lab and Development,OU={{ouDatacenter}},OU=demo-001,DC=2k16ad,DC=sovlabs,DC=net

{% elsif ouEnv == ‘production’ and ouApp == ‘db’ %} OU=Database Servers,OU={{ouDatacenter}},OU=demo-001,DC=2k16ad,DC=sovlabs,DC=net

{% elsif ouEnv== ‘production’ and ouApp != ‘db’ %}  OU={{ouApp}},OU={{ouDatacenter}},OU=demo-001,DC=2k16ad,DC=sovlabs,DC=net  {% endif %}

Looking at the logic, you will notice I’m using if/else logic that is examining the environment as well as the application. The if/else logic allows me to determine the proper OU structure and then replace certain OU levels with values from other custom properties.  While this method is a really good example of what you can do with a single Active Directory configuration, sometimes you may need to have multiple Active Directory Configurations to achieve the results you need for your Active Directory configuration. The good news is we can dynamically handle multiple Active Directory Configurations as well. To do so, define the SovLabs Active Directory property and make the value templated as below:

Property Name: SovLabs_ADConfig Property Value: {{domain}}{{Environment}}

Of course, your templated value will be specific to your use case, but by now I’m sure you’ve gotten the idea.

In this series of articles I have covered a lot of ground. It might be hard to believe, but what I have covered is just the tip of the iceberg. Now that I have let the genie out of the bottle, I hope I’ve helped you get closer to having your wishes come true on your vRealize Automation journey.  If you would like to understand more about this solution or any of the other modules available from SovLabs please reach out and I will be happy to demo this solution and others for you.

Thank you for taking the time to read this article and I hope your genie grants all your automation wishes.