I’ve been playing some with the Terraform provider for vRA that was recently posted on GitHub. If you’re new to terraform like it’s not real clear how to reference the various components of a blueprint, so I wanted to share an example of how to do it in a multi-machine blueprint with some software components.
(I’ll assume you’ve got Terraform and the vRA provider installed/compiled)
So taking a look at the blueprint we can see there are some custom properties lab.bp.prop1 and lab.bp.Prop2.
Looking at the Design Canvas itself we can see that there are two sets of VMs.
Both of them are based on Ubuntu 16 LTS. Each one has different constraints on memory, CPU and disk.
|Build From||CPU Min/Max||Mem Min/Ma||Storage Min/Max||# Of Instances (Min/Max)|
In addition, one instance of the same software component is applied to each VM.
This component has two properties (booleanValue1 and downloadLocation) which can be set at deployment time.
All of the properties in this blueprint/catalog item that we can change are summarized in the following table:
|Component/Level||Property Name||Custom Property
|Default Value||Value set in Terraform cfg|
|lab.vm2.prop1||Custom||VM2 Prop1 Default Value|
The nitty -gritty
So the actual configuration involves three files.
- main.tf – The file that describes the environment & resources we want to spin up
- variables.tf – File describing/prepping the some of the vRA related variables we’ll use in main.tf
- terraform.tfvars – Helps assign values to the variables vs having to specify on the command line. This would be more specific to your install.
Let’s look at each one quickly.
Here we define the 4 variables for connecting to vRA. They’re pretty self-explanatory
Here’s where we specify the values we want to use in the variables. There are other ways to provide this information but I find this easy.
This is just an example.
This file is where we specify that actual resources we want spun up by vRA and their configurations. This example config focuses only on vRA.
The first part is where we specify the provider type and in this case use the variables and values we’ve created.
The second part, the resource, has a couple of components (high level description is available on the provider GitHub (https://github.com/vmware/terraform-provider-vra7#resource)
In this instance we’re going to be invoking a catalog item called TF_VRA_2VM_BP and we want just one instance of it. We’re going to name the Terraform resource we’re spinning up TF_Prop_Example. So the first part of our resource config looks like:
The next section is the catalog_configuration, where we can specify any blueprint level properties if they exist. This blueprint has 2 so the section looks like:
The resource configuration section is where things get interesting. Here the properties have to be referenced relative to the component.
The cpu setting for VM1 is referenced as vm1.cpu. The custom property lab.vm1.prop1 on VM1 is referenced as vm1.lab.vm1.prop1. This is also true of the properties in the software components. The downloadLocation property in SWComponent1_1 which is part of VM1 Is referenced as vm1.SWComponent1_1.downloadLocation.
The completed resource configuration section looks like:
Let’s spin up some VMs….First we need to do an init
And then an apply
That seems to have been successful so lets actually log into vRA and look
My request was successfully submitted and is in progress….and we can already see that the blueprint level properties were set correctly by Terraform.
Looking at VM2 we can see the same.
The number of CPUs was modified to 2, memory to 4GB and lab.vm2.prop1 was set to the value we specified in the terraform config.