Terraform + vRA. Custom deployment

Terraform vRA provider’s capabilities for creating deployments are not limited to working with cloud templates and catalog items . Deployments can be created entirely from scratch by building them as a constructor from a variety of resources. Which of the following methods is the best? Let’s first analyze the latter, then compare all three options.

Provider vRA resources

Before running the first example , take a look at the vRA provider generic resource types documentation , note the following resources:

• vra_machine – resource description for creating a virtual machine in the cloud;
• vra_network – a description of the network configuration, we will connect the VM to the already configured networks;
• vra_block_device – resource description for creating additional disks;
• vra_deployment – vRA deployment.

Example 1. Simple deployment, one VM:

# main.tf 
provider "vra" { 
  url             = var . vra_url  
  refresh_token   = var . vra_refresh_token
} 

data "vra_project" "this" { 
  name            = var . project_name
}   

data "vra_network" "this" { 
  name            = var . network_name
}   

resource "vra_machine" "vm_test" { 
  name            = "$ {var.vm_prefix} -as1" 
  description     = var . vm_description    
  project_id      = data . vra_project . this . id
  image           = var . vm_image 
  flavor          = var . vm_flavor 

  nics { 
    network_id    = data . vra_network . this . id
    addresses     = var . vm_ip_address
   }
}

The files are available for download at https://github.com/isas2.

For this Terraform configuration, one virtual machine will be created, the vRA deployment for it is not described, but it will be created automatically. If you add another virtual machine to this configuration, it will be placed in a separate deployment. And so each resource …

To combine several resources in one deployment, specify the deployment ID of the first resource when creating all the others:

resource "vra_machine" "vm_test_1" {
...
}

resource "vra_machine" "vm_test_2" {
...
  deployment_id = vra_machine.vm_test_1.deployment_id
...
}

Deployment to order

The following example creates an infrastructure for deploying some cluster software: virtual machines (multiple master nodes, multiple worker nodes), additional disks for worker nodes, network setup. Using deployment simplifies the code and allows you to give it an arbitrary name and description.

Example 2. Cluster VM:

# main.tf 
provider "vra" { 
  url                 = var . vra_url  
  refresh_token       = var . vra_refresh_token
} 

data "vra_project" "this" { 
  name                = var . project_name
}   

data "vra_network" "this" { 
  name                = var . network_name
}   

resource "random_id" "this" { 
  byte_length         = 4
}   

resource "vra_deployment" "this" { 
  name                = "$ {var.deployment_name} - $ {random_id.this.hex}" 
  description         = var . deployment_descr    
  project_id          = data . vra_project . this . id
}

resource "vra_block_device" "disk" {
  count             = var.workers_count
  capacity_in_gb    = 5
  name              = "${var.workers_prefix}-disk-0${count.index}"
  project_id        = data.vra_project.this.id
  deployment_id     = vra_deployment.this.id
}

resource "vra_machine" "masters" {
  count             = var.masters_count
  name              = "${var.masters_prefix}-0${count.index}"
  description       = var.masters_description
  project_id        = data.vra_project.this.id
  image             = var.vm_image
  flavor            = var.masters_flavor
  deployment_id     = vra_deployment.this.id

  nics {
    network_id      = data.vra_network.this.id
    addresses       = [var.masters_ip_addresses[count.index]]
  }
}

resource "vra_machine" "workers" {
  count             = var.workers_count
  name              = "${var.workers_prefix}-0${count.index}"
  description       = var.workers_description
  project_id        = data.vra_project.this.id
  image             = var.vm_image
  flavor            = var.workers_flavor
  deployment_id     = vra_deployment.this.id

  nics {
    network_id      = data.vra_network.this.id
    addresses       = [var.workers_ip_addresses[count.index]]
  }

  disks {
    block_device_id = vra_block_device.disk[count.index].id
  }
}

The files are available for download at https://github.com/isas2.

Cloud templates are the basis for IaaS in vRA 8, all other logic is built around them. By refusing to use templates from Terraform, you lose connection with some of the key components of vRA and you have to pay for this in the loss of functionality:

• In the examples provided, the static IP addresses of the VM are specified. If you remove the addresses field from the configuration of network interfaces , then IP allocation will be via DHCP. It is not yet possible to use the built-in vRA IPAM for vra_machine (it was possible to work with the external IPAM configured in vRA, specifying a static IP outside the used subnet – a crutch);
• Allocating resources bypassing the main system logic requires elevated privileges: only the Cloud Assembly Administrator can work at this level;
• Terraform vRA provider does not work with all types of resources, for example, there is no support for Custom Resources;
• Without a cloud template, the deployment diagram does not show the links between resources:

Comparison of deployment creation methods

1. Creation of deployment by vRA catalog item

See example and description Terraform + vRA. Quick start.

• Pros:
  • ease of use;
  • the ability to call any item published in the directory, for example, the vRO process;
• Minuses:
  • no flexibility, the deployment is created according to the vRA administrator template.

2. Creation of deployments from cloud templates

Create new templates or use existing ones: Terraform + vRA. Blueprints.

• Pros:
  • the ability to create new cloud templates and deployments from them;
  • making changes to template schemas to update deployments;
• Minuses:
  • knowledge of the syntax for writing vRA templates is required;
  • for the template to work correctly, all its parameters and used tags must be agreed with the vRA administrator;
  • adding vRA template code to a Terraform configuration greatly impairs readability.

3. Build deployment from various resources

Description in the Terraform configuration of all required resources: vra_network , vra_machine , vra_block_device …

• Pros:
  • full control over the composition of the deployment;
  • description and modification of each resource separately;
• Minuses:
  • more complex configuration, you need to take into account all the parameters of the future deployment;
  • there is no support for Custom Resources vRA ;
  • required role Cloud Assembly by Administrator ;
  • vRA-integrated IPAM is not supported.

At first glance, it might seem that creating deployments by describing individual resources is the most powerful and flexible way to work with Terraform with vRA. However, the existing drawbacks greatly limit the possibilities of its application in real projects.

In my opinion, the best option is to use cloud templates and store the template code in a Git repository.

Translated by Google Translate