vRealize Aria Automation Cloud Automation Cloud Management Platform vRealize Suite

vRealize Automation & Terraform OpenSource : Practical Examples – Part 5

Update July 2022 – The vRealize Automation Terraform Service and accompanying Terraform provider now supports Terraform CLI 1.0.  This allows you to use Terraform 1.0 and provide the latest support for it.

In this blog, let’s see how vRealize Automation leverages its native features in conjunction with all Terraform OpenSource Capabilities, such as modules and providers, by running these two use cases:

  • Nested Cloud Templates : Re-use and call cloud templates from within Cloud Templates.
  • Create a SDDC in VMC : Create and Update a SDDC in VMware Cloud in AWS.

Nested Cloud Templates

One recurring ask from peers and customers is the use of Nested Cloud Templates or simply put, the ability of calling existing Cloud Templates from within a Cloud Templates and all with their differentiated user input, e.g. different size of a VM or custom properties, full disclosure, I have solved this in the past with Code Stream (since it allows me to define multiple Cloud Templates tasks in a single pipeline and expose it altogether as a single component at Service Broker)  but just for the sake of showing a simple use case on which we could combine  vRealize Automation, and Terraform OpenSource I decided to recreate it then twist it a little bit by introducing the ability to update DNS entries on demand for the resources created during the deployment.

Observing the Visual representation (above) and/or the code in the repository from the links below, you might find several resources:

A native Agnostic VM resource (named frontend) that initializes and configures an Apache Web Server (via Cloud-Init), this resource will require to connect to a “Backend”, a MySQL Database that will be also created then configured on-demand, but most importantly, our frontend will need to be configured to access that MySQL Database, simply put, we will need to collect the IP assigned during the MySQL Database instantiation then use this data for configuring the Apache Web server (frontend) with the help of  the Cloud-Init execution (more of this later).

There is another Resource, a Terraform Resource named Nested-Cloud, this construct will call a set of standard Terraform Configuration templates from a Gitlab repository (image below), these templates will load the Terraform vRealize Automation provider and instruct vRealize Automation to deploy the MySQL Cloud Template including the input collected from the user during the deployment.

BTW, this MySQL Cloud Template  also installs and initializes the MySQL Database Software via Cloud-Init

Now, as mentioned before, our frontend server will need to access/know the IP address assigned to this mySQL resource when we instanced it, which it will be ultimately executed by the Terraform “interface” and for that, and as part of the Terraform Configuration templates, I included the “mysql_ip_address” output variable :

Here’s the interesting part, this output is passed all the way to the main Cloud Templates as input for our agnostic VM, you could verify this by inspecting the code of the Nested Cloud Template under the cloudConfig property :

Also note that the Agnostic VM Resource will not commence deployment until the first Terraform Construct building the MySQL Database is complete.

But how about the other way around?, for that, take a look into the second Terraform Construct named Terraform-DNS, in this case we will need to pass the assigned IP and hostname from our frontend VM to the Terraform-DNS configuration files, in order to have the Terraform DNS Provider be able to update our DNS server.

And it is as simple as mapping the vRealize Automation‘s VM resource output we care about (in this case first network)  as an input for the Terraform-DNS construct variable in the Cloud Templates and this will take it all the way down to the Terraform templates variables.

With all these in place, let’s deploy the whole thing, please note that since this is a Cloud Template , we will be able to apply our direct and indirect policies types defined at the Service Broker and by other mechanisms such as Project Configuration and by the Cloud Template itself ( e.g. preferred ABX extensibility environment, metadata tags and so on).

After deploying,  please note that state information and the 2nd day operations at the Deployment and Resource Levels are available based on your user entitlements (also defined by Service Broker Policies).

You can see the actual execution in the following video:

Let’s recap what we just did:

Deployed several cloud resources, applied Terraform templates within vRealize Automation, we had vRealize Automation calling itself via the Terraform vRealize Automation Provider 0.3.2 to create resources in a multi-cloud environment, that’s right, these Cloud Templates are agnostic, meaning that they could be deployed without change in Azure, AWS, vSphere and GCP, we passed bidirectional data among vRealize Automation and Terraform resources (think about it, two different infrastructure as Code Standards working as one).

We also initialized application with the same methodology (Cloud-Init), enabled 2nd day operations for all the resources deployed, performed extensibility tasks when interfacing with the external DNS Servers via the Terraform DNS Provider 2.2.0  (and you could “extend” it further with ABX, vRO (there you have it, “Los 3 amigos de la extensibilidad“)

Not to mention that vRealize Automation enhanced the field input presentation for the Terraform variables (again another indirect way to enforce my governance policies)  and we did all these without leaving vRealize Automation system… pretty flexible and powerful for an automation framework, am I right ? (virtual high-five).

This scenario was tested with the following foundation:

Create a SDDC in VMC

Another use case we get asked a lot is if we could use vRealize Automation for creating and updating SDDC environments on VMware on AWS (VMC) and the answer is, yes of course, in fact, there is an excellent two part blog addressing this use case with an ABX approach : Self-Service Hybrid Cloud – Part 1 – Provide Self-Service Catalog for VMware Cloud on AWS using vRealize Automation , BTW, did you know you can add vRealize Automation as a VMC Cloud Add-On for VMware Cloud on AWS, nice!

Now, could this use case be reproduced with the newly added vRealize Automation‘s Terraform feature? and the answer is once again, you bet!, better news it will be very similar to what I presented already in the previous case, the main difference is the Terraform provider we need to leverage, for this case we’ll use the Terraform VMC Provider for AWS, and to make things interesting, let’s include the ability to add a second cluster during deployment, and also be able to update the number of hosts and cluster members at the SDDC on-demand.

In this case, my Cloud Template code is quite simple (below), one single Terraform Configuration Resource, and several input fields we will collect during deployment (I am just showing the cluster_num_hosts and sddc_num_hosts since we will focus on this later), of course defaults are implemented to simplify the process, furthermore with the vRealize Automation‘s Cloud Forms capabilities I could create dynamic fields and/or fetch security data from an external server to populate my Cloud Template‘s input (once again there is an excellent blog describing this capability in detail: Extending vRealize Automation Custom Forms with vRealize Orchestrator)

My Terraform configuration files are also simple, I include mainly a vmc_sddc and vmc_cluster resources, then we define the VMC provider for creating those resources (you could review all this in the repository link below), very important,  I also defined output data, in this case I care about knowing the resulting vCenter URL associated to the SDDC environment we will create.

BTW, my Terraform configuration files were not exactly the bleeding edge, however the vRealize Automation‘s Terraform Service allows me to define any specific Terraform CLI version (in this case 0.12.29), so I could combine newer Terraform Configuration implementations with my legacy Terraform file sets,  as you can see, different resources and providers, but same mechanics as the previous use case.

When we deploy, we leave the defaults for the number of SDDC hosts and Clusters, 3 for each, and yes we also required user input for our API Token, Org ID and AWS Account Number, please notice that even though the Terraform configuration files are plain for those secrets, the Cloud Template allowed me to  encrypt those attributes, so it won’t be displayed to anyone when looking at the Deployment details.

during execution, we could see how vRealize Automation takes advantage of the Terraform VMC Provider for AWS 1.4.0 to build our SDDC at VMware on AWS (VMC)

When completed we confirm the number of hosts for our SDDC is 3, as expected, also not that the vc:url output as it was indicated at the Terraform Configuration files is exposed at the deployment level.

looking at the VMware on AWS (VMC) console we find the new SDDC VMware on AWS (VMC) with 2 clusters and 3 hosts per cluster:

Now, let’s say we need to increase our cluster capacity, say we need 4 hosts per cluster, that would be an easy task to accomplish by simply updating this deployment and providing our new intention for the number of hosts and cluster members.

This is possible because even though it is a Terraform Resource under the hood, it is effectively managed by vRealize Automation, which provides me with several second day operation for my deployment like the update one:

When we execute this update operation, vRealize Automation  has the ability to provide us the Terraform OpenSource execution details, here we see the update happening for both resources:

when completed,  you could see the resources were updated accordingly

and once again we could confirm at VMware on AWS (VMC) console

You could see the whole execution details in the video below:

This scenario was tested with the following foundation:

And these are only a couple use cases that I am sure you could re-use, enhance, and use as the first step for creating your very own complex use cases.

Note, no Cloud Templates or Terraform Configuration files were hurt while writing this blog ; ) and you should feel free to reuse them but if imported in a different environment, make sure to adjust the specific commitID, repositoryID and sourceDirectory as well as any constraint tags to meet your environment.

If you missed the previous blog in the series you could find them here:

vRealize Automation & Terraform : Cloud Automation Essentials – Part 1

vRealize Automation – Terraform : Infrastructure as Code & Catalog | Broker – Part 2

vRealize Automation – Terraform : Consistent Governance & Workload LifeCycle Management – Part 3 – COMING SOON

vRealize Automation – Terraform : Pipelining | DevOps – Part 4 – COMING SOON

Finally, let’s dig deeper on how vRealize Automation solves one of the most challenging issue in automation which is the resource state management across teams for native resources but also when combined with Terraform OpenSource by preventing state conflicts, data loss and corruption: vRealize Automation – Terraform : Shared State Management – Part 6

Meet you there.

Related Posts:

Francisco Hernandez

Francisco is World's Okeyest Technical Marketing Manager with more than 15 years of Multi-Platform Integration & Automation experience on a broad range of converged solutions specializing in Telecom.

Related Articles