Tag Archives: VRA

vRA Deployments with Terraform

This post covers notes made when using Terraform to deploy basic resources from VMware vRealize Automation (vRA). Read through the vRA provider plugin page here and the Terraform documentation here. There are a couple of other examples of Terraform configurations using the vRA provider here and here. If you’re looking for an introduction on why Terraform and vRA then this blog post gives a good overview. If you have worked with the vRA Terraform provider before feel free to add any additional pointers or best practises in the comments section, as this is very much a work in progress.

Terraform Setup

Before starting you will need to download and install Go and Git to the machine you are running Terraform from. Visual Studio Code with the Terraform extension is also a handy tool for editing config files but not a requirement. The steps below were validated with Windows 10 and vRA 7.3.

After installing Go the default GOROOT is set to C:\Go and GOPATH to %UserProfile%\Go. Go is  the programming language we will use to rebuild the vRA provider plugin. GOPATH is going to be the location of the directory containing source files for Go projects.

In this instance I have set GOPATH to D:\Terraform and will keep all files in this location. To change GOPATH manually open Control Panel, System, Advanced system settings, Advanced, Environment Variables. Alternatively GOROOT and GOPATH can be set from CLI:

set GOROOT=C:\Go
set GOPATH=D:\Terraform

Download Terraform for Windows, put the executable in the working directory for Terraform (D:\Terraform or whatever GOPATH was set to).

In AppData\Roaming create a new file terraform.rc (%UserProfile%\AppData\Roaming\terraform.rc) with the following contents, replace D:\Terraform with your own Terraform working directory.

providers {
     vra7 = "D:\\Terraform\\bin\\terraform-provider-vra7.exe"
}

Open command prompt and navigate to the Terraform working directory. Run the following command to download the source repository:

go get github.com/vmware/terraform-provider-vra7et GOROOT=C:\Go

Open the Terraform working directory and confirm the repository source files have been downloaded.

The final step is to rebuild the Terraform provider using Go. Download the latest version of dep. Rename the executable to dep.exe and place in your Terraform working directory under \src\github.com\vmware\terraform-provider-vra7.

Back in command prompt navigate to D:\Terraform\src\github.com\vmware\terraform-provider-vra7 and run:

dep ensure
go build -o D:\Terraform\bin\terraform-provider-vra7.exe

Running dep ensure can take a while, use the -v switch if you need to troubleshoot. The vRA Terraform provider is now ready to use.

Using Terraform

In the Terraform working directory a main.tf file is needed to describe the infrastructure and set variables. There are a number of example Terraform configuration files located in the source repository files under \src\github.com\vmware\terraform-provider-vra7\example.

A very basic example of a configuration file would first contain the vRA variables:

provider "vra7" {
     username = "username"
     password = "password"
     tenant = "vRAtenant"
     host = "https://vRA
}

Followed by the resource details:

resource "vra7_resource" "machine" {
   catalog_name = "BlueprintName"
}

Further syntax can be added to pass additional variables, for a full list see the resource section here. The configuration file I am using for the purposes of this example is as follows:

main_tf

Example config and variable files from source repo:

multi_machine_example

variables_example

Once your Terraform configuration file or files are ready go back to command prompt and navigate to the Terraform working directory. Type terraform and hit enter to see the available options, for a full list of commands see the Terraform CLI documentation here.

Start off with initialising the vRA provider plugin:

terraform init

terraform_init

Validate the Terraform configuration files:

terraform validate

If you’re ready then start the deployment:

terraform apply

terraform_apply_1

Monitor the progress from the CLI or from the task that is created in the Requests tab of the vRA portal.

terraform_apply_2

terraform_apply_3

Check the state of the active deployments using the available switches for:

terraform state

terraform_state

To destroy the resource use:

terraform destroy

terraform_destroy

Provisioning Virtual Machines with PowervRA

This post will walk through using PowervRA to provision virtual machines from vRA catalog items. PowervRA is a powerful tool allowing us to automate and customise vRA configuration and deployments by leveraging the RESTFUL API. We’ll cover requesting catalog items using both the default settings and with additional values or customisation using a JSON file. For more information review the PowervRA documentation here, the full syntax for Request-vRACatalogItem can be found here.

PowervRA can be installed direct from the PowerShell gallery.

Install-Module -Name PowervRA

Alternatively you can download from GitHub here, drop the PowervRA folder into C:\Program Files\WindowsPowerShell\Modules, and then import.

Import-Module PowervRA

Use Connect-vRAServer to establish a connection to the vRA appliance. This will prompt for a username and password.

Connect-vRAServer -Server <vRA Server> -Tenant <Tenant Name>
Connect-vRAServer -Server vralab01.corp.local -Tenant esxsi -IgnoreCertRequirements

You can also add the -Username switch and -Password switch, or -Credential to add a Powershell credential file. If you are using self signed certs add -IgnoreCertRequirements.

Use Get-vRACatalogItems to list all catalog items the user has access to. Add the -Name switch to list details for a specific catalog item. Make a note of the Id, this is required to request the catalog item.

Get-vRACatalogItem
Get-vRACatalogItem -Name <Catalog Item Name>
Get-vRACatalogItem -Name PSTestBlueprint

Use Request-vRACatalogItem to make the request, you can also add -Wait to wait for the request to complete, and -Verbose to show the event log.

Request-vRACatalogItem -Id <Catalog Item Id>
Request-vRACatalogItem -Id 78eddfcc-c9dd-4104-abd6-218b6ff1e9fa -Wait -Verbose 

We can even do something like:

$CatalogItemId = (Get-vRACatalogItem -Name PSTestBlueprint).Id
Request-vRACatalogItem -Id $CatalogItemId

powervra

In this scenario we want to go further and add values for some custom properties to the request. The request can be customised using a JSON file.

Output the catalog item properties to a JSON file for customisation.

Get-vRACatalogItemRequestTemplate -Name <Catalog Item Name> | Out-File path\file.json
Get-vRACatalogItemRequestTemplate -Name PSBlueprintTest | Out-File C:\requestTemplate.json

Set $json as the updated JSON file. You can verify this has worked and the contents of the JSON file using Write-Output.

$json = Get-Content path\file.json -Raw
$json = Get-Content C:\requestTemplate.json -Raw
Write-Output $json

powervra_1

Update and save the JSON file as required, for example adding the value for a custom property, or amending the CPU / memory allocation.

vra_json

We can now request the catalog item using the JSON file.

Request-vRACatalogItem -JSON $json

powervra_2

When the request is submitted either monitor through Powershell, if you used the verbose switch, or follow the status in the vRA portal as normal under the requests tab.

Changing Active Directory OU of vRA Provisioned Machines

In this post we will make use of ActiveDirectory.rename in the vRO Active Directory plugin to move a computer object to a new OU as a custom action from within the vRA portal. Although technically it isn’t quite Solarwinds integration with vRA, we can cheat by monitoring the new OU. In this setup we will have vRA provision machines to a standard unmonitored OU, and then have an action in the portal triggering a vRO workflow to move the computer account to a monitored OU.

Solarwinds_vRA

vRO Configuration

  • Log into the vRealize Orchestrator client and switch to Design view. Open the Workflows tab.
  • The steps below assume that an Active Directory server has been registered with vRA. If this is not the case then browse to Library, Microsoft, Active Directory, Configuration. Run the Add an Active Directory server workflow and enter the AD information. If successful the AD server should be listed in the Inventory tab under Active Directory.
  • Now from the Workflow tab right click the folder where the new workflow will be created and click New workflow. Enter a name for the new workflow and click Ok.
  • Enter a description if required. Under the Attributes header add a new attribute, give the attribute a name (in this case AD_Host) and change the type to AD:AdHost. The value will be the Active Directory host already configured as mentioned above.

New_Workflow_1

  • Click the Inputs tab. Add a new parameter, give the parameter a name (in this case vmName) and change the type to VC:Virtual Machine. There are no outputs.
  • Click the Schema tab. Drag and drop the Scriptable task item onto the design canvas.
  • Click the Scriptable task. From the Info tab update the task name (in this case I have used Add to Monitored OU).
  • From the IN tab click the Bind to workflow parameter/attribute button. Select the attribute (AD_Host) and parameter (vmName) we created earlier.

New_Workflow_2

  • Open the Scripting tab. The commands I have used are below, this finds and outputs the computer name (using the vmName parameter) from AD (searching the Active Directory host specified in the AD_Host attribute), and then moves it to the new OU.
  • Save and close the workflow.

var object = ActiveDirectory.getComputerAD(vmName.name,AD_Host);

System.log("Searching for computer: " + vmName.name)
System.log("Found computer: " + object)

ActiveDirectory.rename(object.distinguishedName, "CN= " +vmName.name , "OU=Monitored,OU=Servers,DC=Corp,DC=Local" , AD_Host)

vRA Configuration

The next step is to hook the vRO workflow into vRA. Log into the vRealize Automation portal as a user with service architect permissions. From the Design tab select XaaS and Resource Actions. Any existing resource actions are listed. Click New.

Existing_Resource

Map the resource action to the relevant vRO workflow. In this case we need to expand Library, Solarwinds and select the Add to Monitoring workflow.

SW_vRA

The input mappings should already be populated; the resource type is IaaS VC Virtual Machine, the input parameter matches up with the parameter configured in the vRO workflow (vmName which passes the virtual machine name), and this maps to the VC:VirtualMachine orchestrator type.

SW_vRA_1

Accept the default values in the Details tab. Edit the Form as appropriate, in this example I have added just a text description for the user. When you’re done click Finish.

SW_vRA_2

The new resource action is now listed as a draft. To start using the action select it and click Publish. Now select the Administration tab and Catalog Management. Open the Actions page, the new resource action we created should now be displayed.

If you want to change the icon of the resource action you can do so by selection the action and clicking Configure. There are a number of useful vRA icons available here, including sample icons for day 2 actions. Note for users of vRA 7.2 there is a known issue with changing the icon for custom actions, resolved in 7.3 as per this KB article.

SW_Catalog

The next step is to assign our custom action to an entitlement. Open the Entitlements page and select the relevant entitlement. Click the Items & Approvals tab, under Entitled Actions click the green plus symbol. Locate the new resource action and select the check box to add it to the entitled actions. Click Ok and Finish.

SW_Catalog_1

To confirm the configuration has worked browse to the Items tab and select Machines. Any virtual machines that have the custom resource action added to the entitlement will show the new action in the drop-down Actions menu.

SW_Catalog_2

When selecting the new action I am presented with the action form as per the design canvas we saw earlier. In this example when I click Submit the Add to Monitoring workflow is run moving the computer object of the virtual machine to the OU specified in the script.