In my previous post, Infrastructure as Code and vRealize Automation, I talked about the principles of Infrastructure as Code and how vRealize Automation can help you put some of those ideas into action. I also mentioned Terraform as a complimentary technology to vRealize Automation. There are several VMware providers for Terraform (including vSphere, NSX-T, vCloud Director, vRealize Automation 7) which allow customers to consume VMware products in a programatic way. The vRealize Automation Terraform Provider, as well as a wide range of 3rd party providers, and can augment the functionality provided by vRealize Automation with additional external components (as demonstrated recently on Grant Orchard’s blog).
Update 05/2020 – The vRealize Automation Terraform Provider has been updated to v0.2.0, check out the release notes for up to date information on what’s new!
Installing the vRealize Automation Terraform Provider
To start using the vRA Terraform provider you’ll need to have Terraform and Go installed on your local machine. For Mac users you can install both using homebrew, for Windows users I’d recommend chocolatey. Up-to-date installation instructions for the vRA terraform provider are available on the Github repository, the steps I’m using below are used for a Mac.
I’ve created a new folder to hold my Terraform configuration files:
main.tf– this is my main terraform file in which I am describing the desired state of my environmentterraform.tfvars– used for setting variable valuesvariables.tf– used for declaring variables
Generating an API token
In order for Terraform to authenticate with the vRealize Automation API we need an API token – this can either be an access token, a refresh token, or an API token which is issued for a specific purpose. API tokens can be limited to a specific organisation scope, functionality, can be revoked, and can be set to expire. Access and Refresh tokens are based on your login credentials and expire in 8 hours or 6 months respectively, but share the scope and permissions as your user account, and cannot be revoked without disabling the account. For vRealize Automation 8 (on-premises) you will need to use the instructions or scripts provided to retrieve a refresh token.
To create a new API Token, log into VMware Cloud Services Console and navigate to User Settings > My Account > API Tokens > Generate Token
The generated token is given a meaningful name, an expiry, and scoped to a specific organization and permissions. Once the token is generated be sure to save it, we’ll need it in the next steps.
Configuring the vRealize Automation Terraform Provider
The vRA provider requires two bits of information for the initial configuration: the refresh token, and the API URL
Edit the terraform.tfvars file created earlier to include these two variables. We also need to tell terraform what provider we’re using, so edit the main.tf file to include the provider definition as shown in the code below.
The provider vra definition references the two variables we’ve configured in the terraform.tfvars file through the “var” keyword. Now we can run terraform init to see if the provider configures successfully.
So far, so good – the provider is initialised and is ready to start configuring vRealize Automation!
Configuring Infrastructure Components with the vRealize Automation Terraform Provider
The first thing I want to do is configure some of the needed infrastructure within Cloud Assembly in order to deploy a virtual machine – the following components need to be configured to support my workload:
- Cloud Account
- Cloud Zone
- Flavors
- Images
- Project
An AWS Cloud Account requires two additional variables in our terraform.tfvars file – an access key, and a secret key. These are my AWS credentials (that you might use for the aws cli, for example). The variables need to be declared, and while you can declare them in the main.tf file it’s better practice to declare them in a separate variables.tf file to allow for code re-use.
This is where the declarative and self-documenting nature of Infrastructure as Code comes into play – we can see at first glance what this will create a new Cloud Account named “AWS Cloud Account”, using the variables declared in variables.tf. There are two regions configured, and the Cloud Zone should have a tag – “cloud:aws”.
Executing terraform plan will describe what will happen if we run the code:
Now that we have a good idea what the code will do, we can use terraform apply to execute the code – the image below shows that the Cloud Account has been created with the correct regions selected, and the “cloud:aws” tag assigned.
The same method can be used to build up a full description of the infrastructure end state we want to see – including the Cloud Zone, Flavor Mapping, Image Mapping and Project – everything that we need to begin deploying workloads.
Re-running terraform apply results in the new infrastructure being configured:
Creating a Blueprint
All of this infrastructure is great, but it’s really about the workloads. The following code creates a Blueprint in the Project and using the Flavor and Images created earlier. The “content” property of the resource is the YAML code of the blueprint itself.
Once again running terraform apply will create the blueprint
Deploying a blueprint
Finally, let’s deploy the blueprint using the ID of the blueprint we just created, and specifying the inputs. If you have multiple versions of a blueprint, you can specify the desired one using the “blueprint_version” property, without it the deployment will be the “Current Version”.
The blueprint is deployed and configured with the inputs specified in the vra deployement resource.
Conclusion
Hopefully this brief introduction to the vRealize Automation Terraform Provider and the world of Infrastructure as Code has been useful, I’ve only scratched the surface of what you can create. You can find out more about the vRealize Automation provider complete with code examples on the GitHub pages.
