Using vRA 8.2 Terraform cloud templates to deploy AWS resources

VMware have jumped on the Terraform bandwagon and it is now fully integrated into vRA 8.2 onwards. In this blog I will go through the process of configuring vRA to deploy an AWS EC2 instance via Terraform code.

I have found this to be a pretty neat feature in vRA which allows you to create more complex and far reaching resources than vRA natively supports. As an example, I have created a load balancer, which in turn creates Route 53 elements, certificates, target groups, security groups etc all in a single vRA template.

Kubernetes configuration

Firstly, it should be noted that when Terraform is executed from vRA, it is actually runs within a k8s environment. If you are using vRA Cloud, you can ignore this completely as it is configured OOTB and just works. However, if like me you have an-premise version, you will need a k8s runtime.

As this is a lab environment and for the purposes of expediency, I actually followed this very useful hack by Gary Flynn to use the local vRA k8 environment as my runtime environment. Obviously, if this was running in a production environment, a proper cluster would be required.

Update vRA terraform version

If you wish to utilise some of the neat features within tf 13+, then you will need to tell vRA which binaries to use.

Within Infrastructure > Configure > Terraform Version .

Add a new version relevant to the version of terraform you will be executing against. As you can see below, I am using v0.14.4.

All binaries and links can be found @ https://releases.hashicorp.com/terraform/

Check the project setup

Within the projects that are to utilise terraform deployments, you must enable the following flag, else deployments will fail.

Infrastructure > Administration > Projects > Project n > Provisioning Tab .

Enable ‘Allow Terraform cloud zone mapping’.

Terraform Code – GitLab / Github

All terraform code needs to be held within Gitlab or Github to work with vRA.

My folder structure for terraform is to have subordinate folders within the repository, each of which represents different functionality and likely, a different vRA template. As you can see below I have a folder called vra_load_balancer and ec2, both of which could be called by different vRA templates and deliver vastly different compute resources.

Variables configured within terraform *.tf files will be pulled through into vRA as inputs, which can then be configured and processed via Service Broker. Similarly, configured Terraform outputs will also be read into vRA and passed back once the resource is built.

I’m not going to go into the depths of Terraform writing here, but a portion of my demo code for deploying an ec2 can be found here.

https://github.com/tonygumbrell/vra-ec2-demo

Project Integration

Now is time to associate a project with your terraform repository.

Within vRA, go to Infrastructure > Integrations > Gitlab / Github > Projects.

Click ‘Add Repository’.

Choose ‘Terraform Configurations’ from the Type dropdown.

Enter the repository name in the format master_folder/subordinate_folder.

Enter the relevant branch. In this example, I use master.

If using a folder structure similar to the one described above, I suggest leaving the Folder field blank i.e EC2, as this will be defined on the template.

Create New Cloud Template (Blueprint)

Now all the elements are in place to create a Terraform Cloud Template (or blueprint if you are using old terminology!)

Go to Design > New From > Terraform

Give the template a name and associate it with a project.

Choose the relevant repo and commit ID with you wish to use in the deployment.

The source directory field, which is basically ‘folder’, allows you to choose where your code is held for execution. As I have said previously, a different cloud template could utilise a different folder to provide different functionality ie ‘vra_load_balancer’

Before finalising, the vRA interface provides details of the inputs and outputs, which have been read in from the *.tf files in the repo. Mark any as sensitive (secret) if required, and click create.

At this stage, a template is presented to the user. Below is the YAML which has generated. Going forwards, if you commit changes to your repo, the commit ID can be updated in the YAML directly rather than going through the process of creating a new template.

inputs:
  custproj:
    type: string
    description: Customer and Project - passed via vRA
  custowner:
    type: string
    description: Owner - passed via vRA
  custuin:
    type: string
    description: Customer UIN - passed via vRA
resources:
  terraform:
    type: Cloud.Terraform.Configuration
    properties:
      variables:
        custproj: '${input.custproj}'
        custowner: '${input.custowner}'
        custuin: '${input.custuin}'
      providers:
        - name: aws
          cloudZone: TG-AWS/eu-west-2
      terraformVersion: 0.14.4
      configurationSource:
        repositoryId: e92a03e0-5b26-40c2-b3e4-a4a4bd989a36
        commitId: 66ba3ef32edee34114fcb5b844e5e1586e8935a9
        sourceDirectory: ec2

Deployment

The vRA interface provides a fairly good interface for monitoring a terraform deployment. Within Deployments > Deployment n > History, the logs for a terraform plan and deploy are available by clicking the ‘Show Logs’ link in the details column.

At a topology level, each of the generated resources are shown

I hope this gives you a good starting point for delivering Terraform IAC via vRA 8.2 onwards.

Enjoy 🙂