posted

0 Comments

Update Sept 21 2020

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 and call them independently inside a Cloud Template.

 

 

 

 

 

 

 

 

 

 

 

5. 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.

6. 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.

7. 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 RebootPower 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.

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

DevOps for Infrastructure: From VI Admin To DevOps Champion