Zero2Hero - Using Aria Automation to Deploy Multiple Machines with Multiple Disks - Part 1

Published on 29 February 2024 by Christopher Lewis. Words: 964. Reading Time: 5 mins.

In the first of this five post blog series, we will start to look at how we can go from #Zero2Hero in authoring VMware Cloud Templates. We will be using the use case for deploy multiple virtual machines (with additional on-demand disk configurations) but we’ll start at the beginning and incrementally update the capability of the VMware Cloud Template to add different capabilities.

The series will cover the following high level use cases:

Creating a Single Virtual Machine Cloud Template (boot disk only) - Part 1
Creating a Single Virtual Machine Cloud Template (with additional static disk configuration) - Part 2
Creating a Multiple Virtual Machine Cloud Template (with additional static disk configuration) - Part 3
Creating a Single Virtual Machine Cloud Template (with additional on-demand disk configurations) - Part 4
Creating a Multiple Virtual Machine Cloud Template (with additional on-demand disk configurations) - Part 5

Note: All of the above use cases, and the VMware Cloud Templates described, could be used as standalone templates, but I thought it was important to show incremental development, i.e. we’re going from Zero to Hero.

Note: I did start to write this as a single blog post but the more and more I wrote the post, the more I realized it was a big topic to get right and explain and, therefore, it was best to provide it in smaller posts.

The Requirements

We will use the following high level requirements when developing this cloud template:

The consumer must be able to deploy one or more Virtual Machines.
The consumer must be able to choose the operating system (image) for the Virtual Machine.
The consumer must be able to choose the Virtual Machine size (flavor) at request time.
The consumer Must be able to choose to which cloud the Virtual Machine is deployed to (i.e. VMware Cloud or Private Cloud).
Each Virtual Machine must have identical disk configuration.
The disk configuration must support one to five additional disks.
The disk configuration must be chosen at request time.

Getting Started

It is pretty easy to create a basic Cloud Template on the low-code canvas in VMware Aria Automation Assembler, either using the drag and drop user interface or via the Infrastructure as Code (IaC) pane. This article is not going to cover that, I am just going to provide the YAML code for each Cloud Template as we walk through. If you are struggling with the whole IaC concept when using VMware Aria Automation then it is worth checking out the latest VMware Hands On Labs that cover this topic.

Note: VMware Aria Automation Cloud Templates are created in the standardized YAML format. The schema for which is available at the developer.vmware.com .

I’m a true believer of adding incremental capability to any sort of automation. Making small incremental updates should mean that we can easily decipher the issues if a problem occurs.

The Development Process

In the first version of the VMware Aria Automation Cloud Template we are going to cover the three of our seven requirements (#2, #3 and #4) listed above. This type of simple template is the backbone of what VMware Aria Automation can achieve quickly without much effort.

So let’s get started.

Creating a Single Machine VMware Cloud Template (boot disk only)

Inputs

With the addition of the following three simple inputs we can drastically increase the useability of the basic cloud template:

size - this is a static list of string values that corresponds to the flavor mappings that have been created, i.e. small, medium and large.
image - this is a static list of string values that corresponds to the image mappings that have been created, i.e. windows or linux.
location - this is a list of static strings that corresponds to the capability tags that have been created on the different available cloud zones, i.e. cloud:vmc and cloud:vsphere.

Note: We can see that the location input uses the oneOf rather than the enum. This key/value (or title/const) pair solution means we can display a user-friendly name rather than the tag itself which may mean nothing to the consumer.

Resources

Within the resources section, we are just going to add a single Cloud.vSphere.Machine resource object. We are going to use the inputs to be able dynamically select the options of size, image and location at runtime. As you will notice, using the size input as an example, this is achieved using the ${input.size} notation.

One of the key things we are doing here is affecting the VMware Aria Automation placement engine decisions by using a constraint tag via the constraints property. A constraint tag is essentially a capability tag that is declared or discovered on our infrastructure. In our example, we have two cloud zones, one in VMware Cloud on AWS (i.e. cloud:vmc) and one in an on-premises VMware vSphere deployment (i.e. cloud:vsphere).

Template Code

Here is the VMware Cloud Template YAML code:

Note: When you try to deploy from this cloud template, one thing to note is none of the inputs are flagged as mandatory inputs (denoted by an *). This is because we have set a default value for each input. If you do not set a default, the dropdown input will require an option to be selected as it it cannot be empty/null and hence it becomes a mandatory field.

Wrapping It All Up

In this first post of the series, we have covered the creation of a basic VMware Cloud Template that deploys a single Virtual Machine but provides flexibility of deployment options (image, size and location). Looking back at the requirements we had for this series of posts, we essentially have crossed off #2, #3, and #4.

This is a very simple VMware Cloud Template but that is where every good journey starts… at the beginning…

Published on 29 February 2024 by Christopher Lewis. Words: 964. Reading Time: 5 mins.

Blog Categories: VMware VMware Aria Automation Aria Automation