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.
You probably are aware of the Terraform Provider for vRealize Automation 8 and Cloud and hopefully have read already Sam McGeown’s Blog about it, however with the latest August release for vRealize Automation Cloud ( and in the upcoming vRealize Automation 8.2 ) Terraform OSS becomes a first-class citizen in vRealize Automation.
This means that you will be able to consume Terraform Configuration and Templates as a native Resource Type in your Cloud Templates (AKA Blueprints), you will find now a new Terraform Resource Construct at the vRealize Automation design canvas, that will “Front-End” the Terraform Configurations and Templates stored in a Version Control System (VCS).
Simply put, configure Terraform Templates and configurations as a native Cloud Template resource and take advantage of all vRealize Automation capabilities ( Governance, Self-Service Catalog, Extensibility, Life-Cycle Management, Approval, Leases, etc).
All Terraform providers, non-certified, available in the Registry, including the ones used to provision VMware resources (e.g., NSX, VMC on AWS, vSphere) will be supported.
Let’s explore it further !
1. You will need to have a previously configured an AWS Account, Cloud Zone and Project that consumes those resources.
Inside your project, you need to make sure that at the bottom under “Cloud Zone Mapping for Cloud Template Terraform Resources”, you have “Allow terraform cloud zone mapping” enabled.
2. The Terraform Configuration files ( *.tf, *.tfvars, etc) need to be store at a GitHub repository.
You also need to group your Terraform Configuration files into folders, that later on, you could easily reference at the Blueprint Terraform Construct.
You can find a set of Terraform Configuration files in the Working with Terraform GitHub Repository let’s use a simple Terraform plan:
moffzilla/terraformbp ( Deploys 2 X AWS EC2 )
provider "aws" {
version = "2.69.0"
region="us-east-1"
}
variable "instance_type" {
description = "AWS instance type"
default = "t2.micro"
}
variable "myTag" {
description = "My Input Tag"
default = "terraform-test"
}
resource "aws_instance" "machine1" {
ami = "ami-04b9e92b5572fa0d1"
instance_type = "t2.micro"
availability_zone = "us-east-1b"
tags = {
"type" = var.myTag
}
}
resource "aws_instance" "machine2" {
ami = "ami-04b9e92b5572fa0d1"
instance_type = "t2.micro"
availability_zone = "us-east-1b"
tags = {
"type" = var.myTag
}
}
Please note that the public GitHub and Gitlab are currently supported in vRAC however Enterprise versions and Bitbucket are planned to be introduced in vRA 8.2 GA timeframe.
3. Create a GitHub integration and associate your own project.
As mentioned previously, vRealize Automation needs to access the Terraform Configuration files store at the GitHub repository for that,
Go to “Cloud Assembly”, “Infrastructure”, “Connections”, “Integrations”, click on + ADD INTEGRATION select “GitHub”, you will be prompted to provide a “Name“, and also a Github’s Personal Token with enough permission to access the repository, VALIDATE, and if successful, ADD.
Look for your newly created GitHub integration and open it, go to “Projects” , click on + ADD PROJECT , search for your own project and hit NEXT, this will open the “Add Repository” dialog box, prompting you for the following input:
You can leave “Folder” empty, ADD then SAVE.
4. Verify that at least one valid Terraform Version is registered and available.
Go to “Cloud Assembly”, “Infrastructure”, “Configure”, “Terraform Versions”
Verify that 0.12.26 is listed, enabled and with similar settings as below, otherwise you could add it :
Please note, that you can have multiple versions for the Terraform Open Source binary, that can be downloaded from repositories with “Basic Authentication” or “No Authentication”
and call them independently inside a Cloud Template.
5. For the vRealize Automation 8.2 there is an extra integration step, referred as Terraform Run Time, please note, this is only required for vRealize Automation 8.2 , when using vRealize Automation Cloud this is not needed at all.
The Terraform Run Time defines a Kubernetes Namespace integration point for executing the Terraform Jobs, you have two options, Managed Kubernetes cluster or External Kubeconfig , in the first one you will need to add a Kubernetes Integration to vRealize Automation 8.2 , this could be a newly deployed Kubernetes endpoint or by adding an existing one, which it is what I did, in my case I added an existing Kubernetes Cluster v1.14 and I created a new namespace myterraform, please note this is not managed or assigned to any Project by vRealize Automation 8.2 since this is shared for the whole environment.
In the second option, External Kubeconfig, you don’t need to add an external managed Kubernetes cluster, instead of, just copy and paste the entire content of the Kubeconfig file for the cluster you want to access and provide a valid namespace in that environment. I personally preferred the first one as I can re-use the managed Kubernetes cluster for creating namespaces via with cloud templates but that’s a different topic.
Now you can implement the integration by going to to “Cloud Assembly”, “Infrastructure”, “Connections”, “Integrations”, click on + ADD INTEGRATION select “Terraform Runtime“, you will be prompted to provide a Kubernetes Cluster and a Namespace, (the previously one from lines above), you can also configure the Runtime Container Settings for these Terraform Jobs, please note that the default Image is just configured for kickstarting the job, the actual Terraform CLI version used is the one coded at your Cloud Template’s Terraform Constructs.
Please note that since vRealize Automation 8.4 OpenShift can also be used for supporting the Terraform Runtime Interface.
6. Create the Cloud Template
At this point you can create the blueprint with a Terraform Resource,
Go to “Cloud Assembly”, “Design”, NEW FROM, now you will be given 3 options, “Blank Canvas”, “Upload” and “Terraform”, select the last one. A wizard process will prompt you for input simplifying the Cloud Template creation process, select your existing Project and give it a name, then NEXT.
In this step you need to provide which VCS repository and the specific folder holding your Terraform Configuration and Template files that you want to associate to the vRealize Automation Resource but also the specific Git Commit ( think of it as the version associated to those Terraform files you want to deploy ), finally NEXT.
You are actually going to search for the Commit Message “MultipleVM-v008“, then the wizard will translate and insert the associated Commit ID 558bdee1c75d2bb953d9385d69c2e18d73bc897c.
also provided the appropriate folder associated to the Commit ID, in this case “awsinstance”.
It is important to mention that if the Terraform Templates and Configuration files are not properly constructed, an error, indicating the problem will be displayed at this point.
7. Finalize Configuration
Select the Terraform Version, 0.12.26 , remember, any Terraform Version you have previously added will become available here.
All vRealize Automation cloud zones allocated to your “Project” will be exposed as “Providers“, that you can select at request time, meaning, that there is not need for providing any Cloud Account credentials at the Terraform Configuration and Templates or by environment variables. If your Terraform Configuration files include their 3rd party own providers, you will see them listed here as well.
All available Variables required by your Terraform Configuration and Templates will be presented, variables from the Terraform source become inputs in the vRealize Automation Cloud Template. You can encrypt sensitive variables such as passwords by checking the Sensitive box, so they are not displayed when requesting the state also keep in mind that you could manipulate further the input, just like any other variable at vRealize Automation Cloud Template.
Outputs from the Terraform source become expressions that vRealize Automation can reference.
For example, when the Terraform source outputs the machine IP address, the vRealize Automation Cloud Template contains ${resource.terraform.outputs.address} as a value that you can re-use as input for another Resource Type.
Finally you can CREATE , and be redirected to the Cloud Assembly Design Canvas, showing a new Cloud Template with a Cloud.Terraform.Configuration Resource Type, including the input variables required by the Terraform Configuration and templates.
At this stage, you could deploy, version, export, release at Service Broker, update, apply a policy, send notifications, add other resources, include different input, etc, just like any other vRealize Automation Cloud Template, furthermore, if you look at the Resource Types you will find a Terraform Construct, simply drag and drop a Terraform Configuration, like any other valid Cloud Assembly Construct and populate the minimum required properties. It is important to acknowledge that you can add many more Terraform Resources constructs at any point in the canvas by adding them directly in the code or dragging and dropping new ones in the Design Canvas, even include other Resource Types in your blueprint and create dependencies towards others resources.
Please note that you can leverage Cloud Assembly’s Secure Properties or Secrets , you can learn more at How to use a secret vRealize Automation Cloud Assembly property in a Terraform configuration
8. Let’s go ahead and deploy it
Provide the requested input
And just like any other Cloud Template Deployment, you could inspect the Topology and History during deployment
pay special attention to the Terraform PLAN and APPLY Events being executed and providing all the same detailed information you would expect from any standard Terraform execution.
When completed, the Topology will give you access to the deployed resources, the infrastructure state, which can be requested or refreshed at any point with the Refresh or Request the Terraform State operations.
Additionally, since this deployment is composed by 2 X EC2 Instances, we get 2nd day Actions automatically available for them, such as Reboot, Power Off and Reset.
You may notice from the screenshot, some other actions for the EC2 instances, these are Custom Resource Actions that were associate to the newly added Cloud.Terraform.Resource and Cloud.Terraform.Configuration Resource Types.
Remember, Approvals and Policies could also be applied to your deployments in the same way your would do it for any other Cloud Template and Catalog Item, in the example below you could observe a few Terraform based deployments with a different lease expiration and a failed deployment due to an Approval Reject operation.
Feel free to try more complex Terraform Configuration and Templates, explore the ones available at the GitHub repository such as terraformbp/azureinstance ( Multiple Azure VM and Network Resources ) or your own.
You could also face the situation you may need to configure the Terraform Runtime Interface in an environment with no Internet access, for that you can follow vRealize Automation Cloud Assembly Terraform runtime with no internet access.
Conclusion
vRealize Automation IaC is tailored for the modern cloud engineer/administrator in enterprises managing multiple clouds with a focus on consistent governance and policies, Terraform OSS is powered by a massive breadth of endpoint and integrations support with 300+ providers, focus primarily on Public Cloud, combining their features to extend vRealize Automation extensibility capabilities while keeping governance, speed of implementation and life-cycle support is a win-win solution.
For more information feel free to check these blogs:
DevOps for Infrastructure – Demystifying Infrastructure-as-Code
