vRA Tips and Tricks – Part 1

At a previous company I worked for (a Swiss Bank), they owned a spin-off company from their R&D department named DynamicOps. Some of you may be aware that DynamicOps was purchased by VMware in 2012 and their flagship automation product became VMware vCloud Automation Center and through the years had a pretty much 100% re-write until it is now the vRealize Automation product that we all love.

As head of that bank’s Virtualisation Engineering team, I led the implementation of VRM, DCAC, vCAC, and then afterwards vRA and have enjoyed (if that is the word) all the product feature and technical architecture changes since then. What has really stretched me the most however is vRA 8 and the container-based architecture and Infrastructure-as-Code capabilities which was a brand-new world to me.

Now with vRA 8.60, I believe that we have almost parity of features as was available in vRA 7.x (plus a whole lot of new ones of course), and I am writing this article to share some of the tips and tricks I have learnt along the way to bend this product to my will (shameless mention of the site’s tagline here!). I’ll present this as a series of smaller articles as I’m sure to grow the content over time as my understanding increases and/or new features are added in later product versions.

So let’s go…!

Table of Contents

• Part 1 – Array Expression in Cloud Templates
• Part 2 – Ternary Logic
• Part 3 – Property Groups

The vRA Resource Type Schema is fully documented on VMware {code} and examples of expression syntax are in the product documentation, but sometimes it is hard to find the truly valuable nuggets that really add flexibility and value to your blueprints.

One example of this is the use of arrays. An array is a data structure that contains a group of elements and in vRA blueprints we have the ability to define and select a particular value in an array. We can see how this is used below to contain blueprint sprawl:

The objective: Create a single Cloud Assembly blueprint that can deploy different OS images which are customised with a VM Customization Specification.

The issue: The VM Customization Specification is unique for Linux and Windows based templates and you are required to select the OS type when creating the Customization Specification. As a result, you cannot use a single Customization Spec defined as a static value for the vRA blueprint property customizationSpec:

We can work around this issue by using an array in the input form as per the following blueprint code:

name: Base OS
formatVersion: 1
#-------------------------INPUTS-------------------------#
inputs:
  operatingSystem:
    type: string
    # Set the values below as 'image name,customisation spec'
    oneOf:
      - title: Microsoft Windows Server 2019
        const: 'windows-server-2019,windows-spec'
      - title: CentOS Server 7.9
        const: 'centos-79,linux-spec'
      - title: CentOS Server 8.3
        const: 'centos-83,linux-spec'
    title: Operating System
    description: Select an operating system and version.
#------------------------RESOURCES-----------------------#    
resources:
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: '${split(input.operatingSystem,",")[0]}'
      customizationSpec: '${split(input.operatingSystem,",")[1]}'
      flavor: small
      constraints:
        - tag: 'cloud:private'
      networks:
        - network: '${resource.Cloud_NSX_Network_1.id}'
          assignment: static
  Cloud_NSX_Network_1:
    type: Cloud.NSX.Network
    properties:
      networkType: existing
      constraints:
        - tag: Net-T00-Dev

The operatingSystem: input has been defined in an array format as 'image name,customisation spec' with comma-separated values. This means that when you select Microsoft Windows Server 2019 in the form, the value constant will be returned as the array ‘windows-server-2019,windows-spec‘. where windows-server-2019 is in array position 0 and windows-spec is in array position 1

In the resources: section, the image: property is defined as '${split(input.operatingSystem,",")[0]}' meaning “take the value in position 0 of the operatingSystem array”

The customizationSpec: property is defined as '${split(input.operatingSystem,",")[1]}' meaning “take the value in position 1 of the operatingSystem array”

Hence, an input selection of Microsoft Windows Server 2019 in the form will return windows-server-2019 as the image and windows-spec as the VM Customization Specification. This then allows the use of a single blueprint form to deploy multiple OS types with different VM Customization Specifications (e.g. even for Windows you may have an AD-joined spec, and a non-AD-joined spec).

Stay tuned for Part 2 where I will be discussing Ternary logic expressions.