Hello Everyone!

On today’s post, we’re going to talk about the newly released feature in Aria Automation 8.16.1 which is the native integration with the AVI Load Balancer (also called Advanced Load Balancer, and from now on this post, ALB) by using a NSX-T Load Balancer as an example and starting point.

The goal of this post will be for you to be able to operate with the AVI Load Balancer from Aria Automation in the same way that you can do today with the NSX-T Load Balancer.

Initial Setup

For the initial setup and cloud account configuration, you can follow https://docs.vmware.com/en/VMware-Aria-Automation/8.16/Using-Automation-Assembler/GUID-190DD085-2F1B-4888-A7F1-DAA8D5A8380E.html

On that document, in addition to a list of steps, you will also see what permissions are needed by the Aria Automation user that will be interacting with ALB.

It is important to configure these Cloud Accounts with the same capability tags that the vCenters in the same location (and that will be hosting these resources) have.

While there is a native ‘association’ between NSX-T and vCenter, that concept does not currently exist with ALB. If you plan on having more than one ALB Cloud Account in your Aria Automation instance, and you plan to leverage the allocation helper construct (which we will talk about later) make sure the tagging is in place.

This will create a Cloud Zone in Aria Automation as well. Make sure you are adding this Cloud Zone to the projects you plan to consume (as stated in the documentation above). This will all come into play later.

Assumptions on the ALB side

For the purposes of this blog post, I’m going to take the following assumptions on the ALB configuration side, which need to be in place for the integration to work.

• There is a NSX-T Cloud Configured with the same vCenter and NSX-T account that you will be using in Aria Automation
• There is at least one IPAM profile assigned to the NSX-T cloud with at least one usable VIP network profile configured for allocating VIP IPs
  • This VIP network profile name matches the network name in NSX-T
• There is a Service Engine group correctly configured

Now that everything is set up on the Aria Automation side (and ALB side) let’s move on to our use case!

NSX-T Template

Let’s take a look at the following NSX-T LB YAML Code

LB:
    type: Cloud.NSX.LoadBalancer
    properties:
      routes:
        - protocol: HTTP
          port: 80
          instancePort: 80
          instanceProtocol: HTTP
          algorithm: ROUND_ROBIN
          healthCheckConfiguration:
            healthyThreshold: 2
            unhealthyThreshold: 3
            protocol: HTTP
            intervalSeconds: 15
            urlPath: /
            httpMethod: GET
            port: 80
          persistenceConfig:
            type: COOKIE
            cookieMode: INSERT
            cookieName: CK-${uuid()}
            cookieGarble: true
            maxAge: 3600
            maxIdle: 600
        - protocol: TCP
          port: 1000
          instancePort: 1000
          instanceProtocol: TCP
          algorithm: LEAST_CONNECTION
          healthCheckConfiguration:
            healthyThreshold: 2
            unhealthyThreshold: 3
            protocol: TCP
            intervalSeconds: 15
            port: 1000
          persistenceConfig:
            type: SOURCE_IP
            ipPurge: true
            maxIdle: 60
      network: ${resource.Cloud_NSX_Network_1.id}
      loggingLevel: WARNING
      instances: ${resource.Cloud_vSphere_Machine_1[*].id}

What do we have?

• Two virtual servers. One with TCP Port 1000, and another one with HTTP Port 80. Load Balancer Algorithm used for each of them is different
• Each virtual server has it’s own specific health check configuration as well as an application persistence configuration
• Load Balancer is using an existing NSX network in the deployment
• Load Balancer is taking the VM instances in the deployment as their pool members. Since VMs have a dynamic count, it is specified in that way in the assignment.

So how do we recreate this using ALB?

ALB Objects

Let’s first take a look at all the ALB objects that are available to use -> From https://docs.vmware.com/en/VMware-Aria-Automation/8.16/Using-Automation-Assembler/GUID-4844BFD9-18A5-4F8D-A53F-059DDE5DB0FF.html

This is how these resources look in the Canvas:

In addition to this, we’re going to need to use the Allocation Helper for the cloud zone, which is also an available resource in the canvas.

Now that we have all of this, what does our NSX-T example translate to, with regards to objects?

We’re going to need:

• One VS VIP object for IP allocation (either static or dynamic)
• One Pool object per route
• One Virtual Service object per route
• One Monitor object per each individual health check configuration
• One Application Persistence object per each individual persistence configuration
• One Cloud Zone Helper object for placement

I know this sounds like a handful, but we will explain how to build each of these objects below. ALB provides much greater flexibility with regards to features, but that comes with the tradeoff of complexity.

It might take us longer to build what looked simpler in NSX-T, but once we’re over that hurdle, the amount of new possibilities is much greater!

Building the ALB Objects

While I’m going to explain each how to build each object here, there is a resource that’s invaluable for building all of this, which is the Swagger documentation of the ALB API.

You can access it by going to https://your_avi_controller_fqdn/swagger/#/

In the swagger documentation, you will be able to see each object’s schema model, as well as examples of creation. You might need to tweak and modify some of it to be able to use it in Aria Automation, but with some trial and error, success is very likely!

I will go about these objects in order by dependency – that means, an object has to be created first (it has to exist), to then be referenced by another object.

Cloud Zone Helper Object

This object will be used to apply constraint tags – In this example, I will match the tags that my VM objects have, so that there is matching with the vCenter – This one is pretty self explanatory, and it will be referenced by other objects

Allocations_CloudZone_1:
    type: Allocations.CloudZone
    properties:
      accountType: avilb
      constraints:
        - tag: site:${input.site}
        - tag: securityzone:${input.securityZone}
        - tag: az:${input.availabilityZone}

VS VIP Object

 VSVIP_1:
    type: Idem.AVILB.APPLICATIONS.VS_VIP
    properties:
      name: VSVIP_${env.deploymentName}
      description: Managed by Aria Automation
      vrf_context_ref: T1-W1-Gateway-DR-01
      tier1_lr: /infra/tier-1s/20f6q214-e8b3-4cb3-aaeb-6c07639ada23
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      vip:
        - vip_id: 0
          auto_allocate_ip: true
          auto_allocate_ip_type: V4_ONLY
          enabled: true
          ipam_network_subnet:
            network_ref: ${resource.Cloud_NSX_Network_1.resourceName}

Object Explanation:

• VSVIP requires a name – This is the name that you will see in the ALB console – you can set this to whatever name you want, but it makes sense to tie this to the deployment name so that you can identify it
• description can also be anything
• vrf_context_ref would be the name of the context ref in your NSX-T Cloud in ALB
• tier1_lr is the path to the T1 Gateway in your NSX-T instance – this uses the relative path in the NSX-T API as it is not an ALB Object:
  • Note: this might change in future versions and might not be needed
• account is the ALB cloud account that you’re going to use – here is where you reference the Cloud Zone Helper created before
• vip is it’s own object, with the following properties
  • Since we’re only using a single VIP, vip_id would be 0
  • auto_allocate_ip is set to true because we want dynamic IP
  • auto_allocate_ip_type is set to V4_ONLY because we’re doing IPV4
  • enabled is set to true because we are enabling this VS VIP as we create it
  • ipam_network_subnet is an object with a network_ref that maps to a VIP network profile in ALB
    • Since this should match to a NSX-T network, we can use the network name in the deployment as an identifier
    • This would be different if you were using a dedicated VIP segment. If that is the case, you can reference a specific VIP network profile name by name instead of using the name of the network resource in the deployment

Monitor Objects

For this deployment, we will have two monitor objects – one for each health check configuration

MONITOR_1:
    type: Idem.AVILB.PROFILES.HEALTH_MONITOR
    properties:
      name: MONITOR_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      monitor_port: '80'
      type: HEALTH_MONITOR_HTTP
      successful_checks: 2
      failed_checks: 3
      send_interval: 15
      http_request: GET /
  MONITOR_2:
    type: Idem.AVILB.PROFILES.HEALTH_MONITOR
    properties:
      name: MONITOR_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      monitor_port: '1000'
      type: HEALTH_MONITOR_TCP
      successful_checks: 2
      failed_checks: 3
      send_interval: 15

Object Explanation:

• These objects also require names. To maintain consistency, we will be using the deployment name as an identifier
  • Important – Since there will be more than one monitor, we’re using _NUMBER as an identifier as well. Then we can use the same numbering to map this to other objects (like Virtual Services, Pools or Profiles)
  • You can also see that I’m using the same numbering for the objects within the YAML. This helps maintain consistency and makes it easier to understand what maps to what.
• account follows the same logic as in the VS VIP (and all the objects) – mapped to the Cloud Zone Helper object
• monitor_port is the port that is being monitored
• type is the monitor type – in this case, we have a HTTP and a TCP monitor
• successful_checks, failed_checks and send_interval are self explanatory
• http_request (which only shows up in the HTTP monitor) would be the method to use, and to what URL, in this case, we’re doing a GET to /

Application Persistence Objects

For this deployment, we will have two Application Persistence objects, one per application persistence configuration

 PERSISTENCE_PROFILE_1:
    type: Idem.AVILB.PROFILES.APPLICATION_PERSISTENCE_PROFILE
    properties:
      name: PERSISTENCE_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      persistence_type: PERSISTENCE_TYPE_CLIENT_IP_ADDRESS
      ip_persistence_profile:
        ip_mask: 0
        ip_persistent_timeout: 60
 PERSISTENCE_PROFILE_2:
    type: Idem.AVILB.PROFILES.APPLICATION_PERSISTENCE_PROFILE
    properties:
      name: PERSISTENCE_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      persistence_type: PERSISTENCE_TYPE_HTTP_COOKIE
      http_cookie_persistence_profile:
        cookie_name: CK_${env.deploymentName}_2
        timeout: 3600
        is_persistent_cookie: false

Object Explanation

• Like every object, they need a name – following the same structure as the other objects
• account also follows the same structure
• persistence_type will depend on the type of persistence. We have one config for Source IP and one config for Cookie
• The object with the properties will be dependent on the persistence_type
  • If you’re using Source IP persistence, the object will be ip_persistence_profile
    • ip_mask is the mask to be applied to the client IP. This is 0 because we’re not applying a mask
    • ip_persistent_timeout is the length of time before expiring the client’s persistence to a server, after its connections have been closed
  • If you’re using Cookie Persistence, the object will be http_cookie_persistence_profile
    • cookie_name is required and we can use the same naming structure as we use for the rest of the objects. I’m also making the number match to the number in the YAML resource for easier undertanding
    • timeout is the maximum lifetime of any session cookie
    • is_persistent_cookie controls the usage of the cookie as a session cookie even after the timeout, if the session is still open. With false, we’re allowing for this to happen

Pool Objects

For this deployment, we will have two Pool objects, one per route

POOL_1:
    type: Idem.AVILB.APPLICATIONS.POOL
    properties:
      name: POOL_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      tier1_lr: /infra/tier-1s/20f6a214-e8b3-4bb3-aaeb-6c06639ada23
      description: Managed by Aria Automation
      default_server_port: '80'
      health_monitor_refs:
        - ${resource.MONITOR_1.name}
      lb_algorithm: LB_ALGORITHM_ROUND_ROBIN
      servers: '${map_by(resource.Cloud_vSphere_Machine_1[*].address, address => {"ip": {"addr": address, "type" : "V4"}})}'
      application_persistence_profile_ref: /api/applicationpersistenceprofile/${resource.PERSISTENCE_PROFILE_1.resource_id}
POOL_2:
    type: Idem.AVILB.APPLICATIONS.POOL
    properties:
      name: POOL_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      tier1_lr: /infra/tier-1s/20f6a214-e8b3-4bb3-aaeb-6c06639ada23
      description: Managed by Aria Automation
      default_server_port: '1000'
      health_monitor_refs:
        - ${resource.MONITOR_2.name}
      lb_algorithm: LB_ALGORITHM_LEAST_CONNECTIONS
      servers: '${map_by(resource.Cloud_vSphere_Machine_1[*].address, address => {"ip": {"addr": address, "type" : "V4"}})}'
      application_persistence_profile_ref: /api/applicationpersistenceprofile/${resource.PERSISTENCE_PROFILE_2.resource_id}

Object Explanation

• name, account and description follow the same structure as the other objects
• tier1_lr is used in the same way as in the VS VIP object
• default_server_port is the default server port (would map to the internal port in the NSX-T Load Balancer)
• health_monitor_refs is an array of monitor references. Since our monitors are different, we are only going to use one item in the array, and this reference maps to the numbering used in the monitors
  • This is why we kept numbering consistent – so MONITOR_1 maps to POOL_1 and MONITOR_2 maps to POOL_2
• servers maps to the servers in the deployment – the syntax uses map_by to allow for clustering as well as both attributes needed by the ip object, which are addr and type
• application_persistence_profile_ref maps to the application persistence object defined before
  • Same scenario with the monitor – We keep numbering consistent so PERSISTENCE_PROFILE_1 maps to POOL_1 and PERSISTENCE_PROFILE_2 maps to POOL_2

Virtual Services Objects

For this deployment, we will have two Virtual Services objects, one per route

VIRTUALSERVICE_1:
    type: Idem.AVILB.APPLICATIONS.VIRTUAL_SERVICE
    properties:
      name: VS_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      vrf_context_ref: T1-W1-Gateway-DR-01
      enabled: true
      services:
        - enable_ssl: false
          port: '80'
      traffic_enabled: true
      vsvip_ref: /api/vsvip/${resource.VSVIP_1.resource_id}
      pool_ref: /api/pool/${resource.POOL_1.resource_id}
      application_profile_ref: /api/applicationprofile?name=System-HTTP
      network_profile_ref: /api/networkprofile?name=System-TCP-Proxy
 VIRTUALSERVICE_2:
    type: Idem.AVILB.APPLICATIONS.VIRTUAL_SERVICE
    properties:
      name: VS_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      vrf_context_ref: T1-W1-Gateway-DR-01
      enabled: true
      services:
        - enable_ssl: false
          port: '1000'
      traffic_enabled: true
      vsvip_ref: /api/vsvip/${resource.VSVIP_1.resource_id}
      pool_ref: /api/pool/${resource.POOL_2.resource_id}
      application_profile_ref: /api/applicationprofile?name=System-L4-Application
      network_profile_ref: /api/networkprofile?name=System-TCP-Fast-Path
  

Object Explanation

• name and account follow the same structure as in the other objects
• vrf_context follows the same structure as in the VS VIP object
• enabled is set to true because we want this service to be enabled
• services is an array – but since we’re mapping this to a single pool, we will only have one service in the virtual service
  • We’re using the same port as the internal port, and enable_ssl is set to false
• traffic_enabled is set to true to allow for traffic
• vsvip_ref references the VS VIP object previously created – since there is a single VSVIP object, both virtual services will reference it
• pool_ref references the pool that has the members for this service. Using the same numbering strategy as before, VIRTUALSERVICE_1 references POOL_1 and the same thing with number 2
• application_profile_ref will vary based on the protocol – To align with NSX-T LB:
  • for HTTP it will reference System-HTTP
  • for TCP it will reference System-L4-Application
• network_profile_ref will also vary based on the protocol – To align with NSX-T LB
  • for HTTP it will reference System-TCP-Proxy
  • for TCP it will reference System-TCP-Fast-Path

Complete object

Adding up everything we created before, we end up with this YAML code!

Allocations_CloudZone_1:
    type: Allocations.CloudZone
    properties:
      accountType: avilb
      constraints:
        - tag: site:${input.site}
        - tag: securityzone:${input.securityZone}
        - tag: az:${input.availabilityZone}
VSVIP_1:
    type: Idem.AVILB.APPLICATIONS.VS_VIP
    properties:
      name: VSVIP_${env.deploymentName}
      description: Managed by Aria Automation
      vrf_context_ref: T1-W1-Gateway-DR-01
      tier1_lr: /infra/tier-1s/20f6q214-e8b3-4cb3-aaeb-6c07639ada23
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      vip:
        - vip_id: 0
          auto_allocate_ip: true
          auto_allocate_ip_type: V4_ONLY
          enabled: true
          ipam_network_subnet:
            network_ref: ${resource.Cloud_NSX_Network_1.resourceName}
MONITOR_1:
    type: Idem.AVILB.PROFILES.HEALTH_MONITOR
    properties:
      name: MONITOR_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      monitor_port: '80'
      type: HEALTH_MONITOR_HTTP
      successful_checks: 2
      failed_checks: 3
      send_interval: 15
      http_request: GET /
  MONITOR_2:
    type: Idem.AVILB.PROFILES.HEALTH_MONITOR
    properties:
      name: MONITOR_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      monitor_port: '1000'
      type: HEALTH_MONITOR_TCP
      successful_checks: 2
      failed_checks: 3
      send_interval: 15
POOL_1:
    type: Idem.AVILB.APPLICATIONS.POOL
    properties:
      name: POOL_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      tier1_lr: /infra/tier-1s/20f6a214-e8b3-4bb3-aaeb-6c06639ada23
      description: Managed by Aria Automation
      default_server_port: '80'
      health_monitor_refs:
        - ${resource.MONITOR_1.name}
      lb_algorithm: LB_ALGORITHM_ROUND_ROBIN
      servers: '${map_by(resource.Cloud_vSphere_Machine_1[*].address, address => {"ip": {"addr": address, "type" : "V4"}})}'
      application_persistence_profile_ref: /api/applicationpersistenceprofile/${resource.PERSISTENCE_PROFILE_1.resource_id}
POOL_2:
    type: Idem.AVILB.APPLICATIONS.POOL
    properties:
      name: POOL_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      tier1_lr: /infra/tier-1s/20f6a214-e8b3-4bb3-aaeb-6c06639ada23
      description: Managed by Aria Automation
      default_server_port: '1000'
      health_monitor_refs:
        - ${resource.MONITOR_2.name}
      lb_algorithm: LB_ALGORITHM_LEAST_CONNECTIONS
      servers: '${map_by(resource.Cloud_vSphere_Machine_1[*].address, address => {"ip": {"addr": address, "type" : "V4"}})}'
      application_persistence_profile_ref: /api/applicationpersistenceprofile/${resource.PERSISTENCE_PROFILE_2.resource_id}
VIRTUALSERVICE_1:
    type: Idem.AVILB.APPLICATIONS.VIRTUAL_SERVICE
    properties:
      name: VS_${env.deploymentName}_1
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      vrf_context_ref: T1-W1-Gateway-DR-01
      enabled: true
      services:
        - enable_ssl: false
          port: '80'
      traffic_enabled: true
      vsvip_ref: /api/vsvip/${resource.VSVIP_1.resource_id}
      pool_ref: /api/pool/${resource.POOL_1.resource_id}
      application_profile_ref: /api/applicationprofile?name=System-HTTP
      network_profile_ref: /api/networkprofile?name=System-TCP-Proxy
 VIRTUALSERVICE_2:
    type: Idem.AVILB.APPLICATIONS.VIRTUAL_SERVICE
    properties:
      name: VS_${env.deploymentName}_2
      account: ${resource.Allocations_CloudZone_1.selectedCloudAccount.name}
      vrf_context_ref: T1-W1-Gateway-DR-01
      enabled: true
      services:
        - enable_ssl: false
          port: '1000'
      traffic_enabled: true
      vsvip_ref: /api/vsvip/${resource.VSVIP_1.resource_id}
      pool_ref: /api/pool/${resource.POOL_2.resource_id}
      application_profile_ref: /api/applicationprofile?name=System-L4-Application
      network_profile_ref: /api/networkprofile?name=System-TCP-Fast-Path

Adding this code to a blueprint that already has a VM Object and a Network Object will let us do a deployment that will look like this!

Hooray!!!!

Some Caveats and Final Thoughts

• Currently, the only supported way to update ALB objects using vRA is via Iterative Updating – this means, applying a new YAML code to the deployment
  • This can be done by changing the blueprint and then updating the deployment, or by using blueprint-requests API to send new YAML code to the deployment
• Official documentation (linked above) and the Swagger are your best friends – There are many more options that can be configured based on your business needs!
• The official blog by Scott McDermott also has some examples that could be useful! -> https://blogs.vmware.com/management/2024/02/deploy-avi-load-balancer-with-aria-automation-templates.html

I hope you find this useful! If you do, please leave a comment, and don’t hesitate to reach out with any questions!

Hello Everyone!

I wanted to make this post to invite you to the session I’m going to be presenting at VMware Explore 2023 in Las Vegas, Aug 21-24, with my colleague Pontus Rydin!

The title of the session is “Lessons Learned from the Most Complex VMware Aria Automation 7 to 8 Migration to Date”

In this session we will go over an extremely interesting customer scenario with regards to migration, and how we managed to get to the other side successfully. A lot of requirement analysis, thinking outside of the box, developing process, code, testing, and coming up with creative ideas to a problem that seemed impossible.

We are going to be presenting this session twice!

• We will be presenting this at the general session, that is going to be August 22th at 1PM
  • The code for this session is CEIB1318LV and you can find it in the content catalog!
  • https://event.vmware.com/flow/vmware/explore2023lv/content/page/catalog?search=CEIB1318LV&tab.contentcatalogtabs=1627421929827001vRXW – Direct link to the session in the content catalog!

• We will also be presenting this to our TAM and S360 customers in a more intimate crowd, and that is going to be August 23rd at 12PM (noon)
  • The code for this session is TAM2641LV and you can find it in the content catalog, but you will only see it if you’re a TAM/S360 customer
  • https://event.vmware.com/flow/vmware/explore2023lv/content/page/catalog?search=TAM2641LV&tab.contentcatalogtabs=1627421929827001vRXW – Direct link to the session in the content catalog!

I’m really looking forward to seeing you all there. It’s going to be a blast.

Hello Everyone! I hope you’re having a good end of the year.

On today’s post, I will talk about a specific use case and one of the ways to solve it:

The business need was to do the following:

• Have a single master template with dozens of inputs, to fullfill every deployment need.
• This master template will be consumed by multiple projects and different users
• Availability of inputs need to change based on the consumer / project
• Visibility of inputs needs to change based on the consumer / project
• Format of inputs needs to change based on the consumer / project
• Source (in case of external data) for input data needs to change based on the consumer / project

You can see that we’re hitting a few limitations in the vRA OOB code:

• The ‘conditional’ values for existence, visibility, format, etc, for a service broker form inputs don’t allow for this level of customization
• A single cloud template can’t have more than one service broker form attached to it

So how do we solve this business need? Here comes the API solution!

Important: all the API information in swagger format (everything that was used in making this solution) is available in your vRA instance at https://VRA_FQDN/automation-ui/api-docs

What does the solution need to accomplish?

I will make a quick summary of what the code needs to do

• Grab the inputs from a service broker form (and the requester ID, this is important)
• Save the actual deployment name, but make the API deployment (mapped to the vRO workflow) use a temporary
• Use the inputs to deploy the master template blueprint via the API (since we’re using the API and we don’t have access to the requester’s credentials, the API call will be executed by an administrative account configured in vRO)
• Poll the master template blueprint deployment until it is successful
• Once it is successful, change the owner to the original requester
• Once that is done, destroy the temporary deployment that generates the API one.

Does that make sense?

I’ll break it down a bit:

These are the blueprint inputs:

inputs:
  instances:
    type: integer
    default: 1
  flavor:
    type: string
    default: SMALL
  image:
    type: string
    default: centos
  network:
    type: string
    default: 'network:web'
  environment:
    type: string
    default: 'env:vsphere'

These inputs (and a bit more) are the ones that are going to be used in the API call to the blueprint-request API -> part of that code. I create the body of the call with the inputs

var blueprintId = "01b5b4db-48b6-4b29-b062-a7dc1c5d9c93" // hardcoded master template
var blueprintInputs = {}
blueprintInputs.instances = instances
blueprintInputs.environment = environment
blueprintInputs.image = image
blueprintInputs.network = network
blueprintInputs.flavor = flavor
var blueprintBody = {}
blueprintBody.blueprintId = blueprintId
blueprintBody.blueprintVersion = "1"
blueprintBody.deploymentName = realDeploymentName
blueprintBody.projectId = projectId
blueprintBody.reason = "X"
blueprintBody.inputs = blueprintInputs
blueprintBodyString = JSON.stringify(blueprintBody)
System.log(blueprintBodyString)
var request = restHost.createRequest("POST", "/blueprint/api/blueprint-requests", blueprintBodyString);

Now those inputs need to be part of the action and the workflow we’re going to use, as you can see here:

You can see that we have some extra inputs that are not in the blueprint!

• All the REST configuration will be variables of the workflow that is calling the action. This will use the previously configured REST host and the credentials
• ProjectId is needed for the deployment, and we get that from the Service Broker Form
• ownerId is needed for the deployment change owner action, and we get that from the execution context of the workflow that is being called by the service broker form
• realDeploymentName is the actual deployment name (remember that the Service Broker form will use the temporary deployment name, and the actual deployment will use the name you input.

So what does the structure look like? In this case, we have two offerings for two projects:

Each of them have different configurations for the fields, for example:

These two service broker forms map to two vRO workflows:

Why do I need two workflows? because as mentioned before, I can’t use two service broker forms for the same catalog item. However, these two vRO workflows are just wrappers of the ‘main’ workflow

However, there is an important caveat here. The ownerId will only be part of the workflow that is called by Service Broker, in this case, the wrapper one. So the information for the requester is on the execution context of this workflow.

And I need to pass that to the base workflow. So how do I do that? By extracting the property from the execution context, and then passing it to the base workflow.

The only thing left now is to destroy the temporary deployment after it is done with the API one. So how do we do that?

We have a workflow that will delete a deployment via API – It basically calls the the deployments API with a DELETE action

//delete Deployment
System.log(deploymentId)
var request = restHost.createRequest("DELETE", "/deployment/api/deployments/"+deploymentId);
request.contentType = "application/json";
request.setHeader("accept", "application/json");
request.setHeader("Authorization", "Bearer " + tokenResponse)
 
//Attempt to execute the REST request
try {
    response = request.execute();
    jsonObject = JSON.parse(response.contentAsString);
    System.log(response.contentAsString)
}
catch (e) {
    throw "There was an error executing the REST call:" + e;
}

The deploymentId comes from the subscription run. Since this is run from the Event Broker state ‘Deployment Completed’, we have the deploymentId available there

So we just extract it (the same way we did with the execution context) but from the inputProperties (payload used in the event broker subscriptions)

So how does all of this look in an actual run? Let’s show it in a video! (takes around 6 minutes, you will see the temporary deployment being generated, then the actual one via the API, the owner name change, and the destruction of the original one.

And I’m going to attach the code of the two most important actions that form the workflows (deployViaApi and deleteDeployment) here:

https://github.com/luchodelorenzi/scripts/blob/master/deleteViaAPI.js

https://github.com/luchodelorenzi/scripts/blob/master/deployViaAPI.js

Summary

I hope you enjoyed reading and understanding this as much as I did while trying to come up with this solution and then making this a reality. This idea can be heavily customized to suit other use cases (and grow this one way more) but the principles used here should still apply!

Please leave your feedback in the comments if you liked it, and share it!

Hello Everyone,

On today’s post, we will go through creating an ABX Action to change the DNS Servers for a Deployment in vRA8. This might be needed to do in scenarios in which, even though the network has DNS servers configured, a specific deployment might require to use other DNS Servers while still being on the same network, for example, to join a different AD domain

The same idea can be used to edit other fields of the deployment, such as the IP Address, search domains, etc.

The post will be divided in 5 sections:

• Cloud Template
• Event Topic
• ABX Action
• ABX Subscription
• Test

Cloud Template

In the template we’re going to need two inputs – dnsServers (comma separated list of DNS Servers) as well as an input to manage the amount of VMs in the deployment, we can call it ‘instances’

 instances:
    type: integer
    title: Amount of VMs
    default: 1
    maximum: 5
  dnsServers:
    type: string
    description: Comma separated list of DNS Servers
    title: DNS Servers
    default: '1.1.1.1,8.8.8.8'

These two values will be custom properties on the VM Object

properties:
   count: '${input.instances}'
   dnsServers: '${input.dnsServers}'

In addition to this, the network assignment for the VM resource should be set to ‘static’. A customization specification profile is optional, since using a ‘static’ assignment will auto-generate a ‘ghost’ customization specification profile at the time of provisioning

networks:
    - network: '${resource.VMNetwork1.id}'
      assignment: static

Event Topic

The event topic that we need to use to make changes to the Network Configuration is the one that has the object that we need to edit being presented to the workflow in an editable state, as in, not read-only.

For this specific use, the state is Network Configure

The dnsServers object is a 3D Array, so that is what we need to use in the ABX Action Code

So from this point we learn that:

• The action will run once for a cluster of machines, so if we were to do a Multi-VM deployment we need to take this into account, otherwise, it will only run for a single VM and not all of the VMs in the deployment
• a 3D array needs to be used to insert the DNS Servers into the object at the event topic

ABX Action

For this example, I will use Python, and I will not use any external libraries for array management (such as numpy) since I wanted to see if it could be done natively. Python has way better native support for lists than it does for arrays, but in this case, given the schema of the object in the event topic, we’re forced to use a 3D Array.

The first thing we need to do when creating the action, is to add the needed inputs. In this one, I will add the custom properties of the resources as an input

Once we have that as an input, we can use it to get the data we need (amount of instances and DNS servers)

To pass data back to the provisioning state, we will use and return the ‘outputs’ object

This is the code of the action itself, I will explain it below

def handler(context, inputs):
    outputs = {}
    dnsServers = [[[]]]
    instances = inputs["customProperties"]["count"]
    inputDnsServers = inputs["customProperties"]["dnsServers"].split(",")
    if (len(inputDnsServers) > 0):
        outputs["dnsServers"] = dnsServers
        outputs["dnsServers"][0][0] = inputDnsServers
        for i in range(1,int(instances)):
            outputs["dnsServers"] = outputs["dnsServers"] + [[inputDnsServers]]
    return outputs

• Define the outputs object
• Define the 3D Array for DNS Servers
• Assign the inputs as variables in the script
• Convert the comma separated string into a List
• If the list is not empty (this means that the user did enter a value in the DNS Servers list on the input form) then we add the 3D Array to the outputs object.
  • Why am I asking to see if it is empty? Because if the user did not put anything on the field, we will be overwriting the output with an empty array, and that will overwrite the DNS that were read from the network in vRA. We only want to overwrite that if we’re actually changing the DNS Servers.
• Also in the same condition, we want to add the DNS Servers array to each VM, so we iterate through the amount of VMs.
  • The way to add it without using numpy (we have no append method) is not elegant, but it does the trick. Basically, we initialize the first element and then we add other elements to the same array using the same format.
• Return the outputs object

This can also be done in javascript and powershell, the idea would be the same.

So how does this object look like in an actual run?

Lastly, we need to configure a subscription for it to run at this specific state.

ABX Subscription

This is the most straightforward part – We create a blocking subscription in the Network Configure state, and we add the action we just created

The ABX subscription can be filtered via a condition (for example, to run only on specific cloud templates) as well.

So let’s do our deployment now!

The network i’m going to select has the 8.8.8.8 DNS configured

This will be overwritten by whatever we put on the input form. I’m going to use 1.2.3.4 and 5.6.7.8 for this example, and there will be 2 VMs in the deployment

We can check the output of the action before the deployment finishes

In there we can see the actual code that run, if it was successful or not, the payload, and the output the action had. In this case, our two DNS Servers for our two VMs with a successful output.

Checking the DNS for one of the VMs, we can see the two DNS Servers we selected as inputs!

Summary

I hope you found this post useful! The same idea can be used to change several other properties at provisioning time. Also, it was a learning experience for me to learn how to play with arrays in Python natively, and how to interact with ABX properly.

More posts will be coming soon!

If you liked this one, please share it and/or leave a comment!

Hello Everyone,

On today’s post, I will focus on a Dynamic Multi-NIC configuration for a Cloud Template in vRA 8.x

This allows customers to reuse the same cloud templates for virtual machines that could have a different amount of NICs, and this amount is defined at the time of the request. If this wasn’t dynamic, then a cloud template with three networks, will always need to have three networks configured at the time of the request, which might not be the case.

Using a Dynamic construct allows for less cloud template sprawl, since multiple application configurations can use the same cloud template.

Since this configuration is not trivial, this post will be a step by step guide on how to achieve this result.

Current Environment

For this Lab demonstration, we will use a vSphere Cloud Account, 4 NSX-T segments that are part of a Network Profile with a capability tag named “env:production” – In doing so, when using that constraint tag in the cloud template, we can guarantee our deployment will use that specific network profile.

The 4 NSX-T segments also have a single tag that refers to the type of network it is. In this scenario, Application, Frontend, Database and Backup are our 4 networks.

Creating the Cloud Template

To get the Dynamic Multi-NIC configuration on the Cloud Template to work, we need the following things:

• Inputs for Network to NIC mapping based on tagging
• Inputs for NIC existence
• Network Resources
• VM Resource and Network Resource assignment

In addition to this, we can do customization in Service Broker to change the visibility of the fields. This is done to only allow the requester to choose a network mapping for a NIC what will actually be used.

Inputs for Network to NIC mapping based on tagging

This cloud template will allow for configurations of up to 4 NICs, and since we have 4 networks, we should let the requester select, for each NIC, what networks can be used.

This is what it looks like

Network1:
    type: string
    description: Select Network to Attach to
    default: 'net:application'
    title: Network 1
    oneOf:
      - title: Application Network
        const: 'net:application'
      - title: Frontend Network
        const: 'net:frontend'
      - title: Database Network
        const: 'net:database'
      - title: Backup Network
        const: 'net:backup'
  Network2:
    type: string
    description: Select Network to Attach to
    default: 'net:frontend'
    title: Network 2
    oneOf:
      - title: Application Network
        const: 'net:application'
      - title: Frontend Network
        const: 'net:frontend'
      - title: Database Network
        const: 'net:database'
      - title: Backup Network
        const: 'net:backup'
  Network3:
    type: string
    description: Select Network to Attach to
    default: 'net:database'
    title: Network 3
    oneOf:
      - title: Application Network
        const: 'net:application'
      - title: Frontend Network
        const: 'net:frontend'
      - title: Database Network
        const: 'net:database'
      - title: Backup Network
        const: 'net:backup'
  Network4:
    type: string
    description: Select Network to Attach to
    default: 'net:backup'
    title: Network 4
    oneOf:
      - title: Application Network
        const: 'net:application'
      - title: Frontend Network
        const: 'net:frontend'
      - title: Database Network
        const: 'net:database'
      - title: Backup Network
        const: 'net:backup'

We can see that each of the inputs allows for any of the networks to be selected.

Inputs for NIC Existence

Other than the first NIC (which should always exist, otherwise our VM(s) wouldn’t have any network connectivity, we want to be able to deploy VMs with 1, 2, 3, and 4 NICs, using the same Cloud Template.

To achieve that, we will create 3 Boolean Inputs that will define if a NIC should be added or not.

needNIC2:
    type: boolean
    title: Add 2nd NIC?
    default: false
  needNIC3:
    type: boolean
    title: Add 3rd NIC?
    default: false
  needNIC4:
    type: boolean
    title: Add 4th NIC?
    default: false

Network Resources

To manage the configuration of the NICs and networks, the network resources for NICs 2, 3 and 4 will use a count property, and this property’s result (either 0 if it doesn’t exist, or 1 if it does exist) will be based on the result of the inputs. Network 1 will not use that property

Also, we will use the deviceIndex property to maintain consistency with the numbering – So the network resources look like this

Network1:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing
      deviceIndex: 0
      constraints:
        - tag: '${input.Network1}'
        - tag: 'env:production'
  Network2:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing
      count: '${input.needNIC2 == true ? 1 : 0}'
      deviceIndex: 1
      constraints:
        - tag: '${input.Network2}'
        - tag: 'env:production'
  Network3:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing
      count: '${input.needNIC3 == true ? 1 : 0}'
      deviceIndex: 2
      constraints:
        - tag: '${input.Network3}'
        - tag: 'env:production'
  Network4:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing
      count: '${input.needNIC4 == true ? 1 : 0}'
      deviceIndex: 3
      constraints:
        - tag: '${input.Network4}'
        - tag: 'env:production'

The constraint tags that are used are the Network Input (to choose a network) and the ‘env:production’ tag to make our deployment use the Network Profile we defined earlier.

VM Resource & Network Resource Assignment

This is the tricky part – Since our networks could be non-existent (if the needNic input is not selected) we cannot use the regular syntax to add a network, which would be something like:

networks:
        - network: '${resource.Network1.id}'
          assignment: static
          deviceIndex: 0
        - network: '${resource.Network2.id}'
          assignment: static
          deviceIndex: 1
      ...

This will fail on the Cloud Template validation because the count for Network2 could be zero, so to do the resource assignment, we need to use the map_by syntax.

Several other examples can be seen on the following link: https://docs.vmware.com/en/vRealize-Automation/8.5/Using-and-Managing-Cloud-Assembly/GUID-12F0BC64-6391-4E5F-AA48-C5959024F3EB.html

The VM resource uses a simple Ubuntu Image with a Small Flavor, so here is what it looks like once the map_by syntax is used for the assignment

Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      image: Ubuntu-TMPL
      flavor: Small
      customizationSpec: Linux
      networks: '${map_by(resource.Network1[*] + resource.Network2[*] + resource.Network3[*] + resource.Network4[*], r => {"network":r.id, "assignment":"static", "deviceIndex":r.deviceIndex})}'
      constraints:
        - tag: 'env:production'

28/07/22 Update

I’ve gotten comments saying this didn’t work in newer versions such as vRA 8.7 or 8.8. The syntax for those versions might be:

networks: '${map_by(resource.Network1[*].* + resource.Network2[*].* + resource.Network3[*].* + resource.Network4[*].*, r => {"network":r.id, "assignment":"static", "deviceIndex":r.deviceIndex})}'

This allows for any combination of NICs, from 1 to 4, and if the count of one of the resources is 0, it won’t be picked up by the assignment expression.

This is what the Cloud Template looks on the canvas. You can see that Networks 2, 3 and 4 have the appearance of possible multiple instances. This is because we’re using the count parameter.

If we were to deploy this Cloud Template, it will look like this:

How do we fix this? We can leverage Service Broker to manage the visibility of the fields based on the boolean input!

So now, from Service Broker, it looks like this:

So if we deploy this, it should have three networks assigned. The first NIC should use the Application Network, the second NIC should use the Frontend Network and the 3rd NIC should use the Database Network.

Let’s test it!

We can see that even if the Cloud Template had 4 Network Resources, only 3 were instantiated for this deployment! And each network was mapped to a specific NSX-T segment, thanks to the constraint tags.

Closing Note

I hope this blog post was useful – The same assignment method can be used for other resources such as Disks or Volumes – the principle is still the same.

Feel free to share this if you found it useful, and leave your feedback in the comments.

Until the next time!