When discussing the concepts of DevOps and Infrastructure-as-a-Code, the tools developed by HashiCorp quickly come up. With Terraform, HashiCorp offers a simple way to automate infrastructure provisioning in both public clouds and on-premises. Terraform has a long history of deploying and managing OVH’s Public Cloud resources. For example, you can find a complete guide on GitHub. In this article, we will focus on using Terraform to interact with another OVH solution: Private Cloud.
Private Cloud enables customers to benefit from a VMware vSphere infrastructure, hosted and managed by OVH. Terraform lets you automate the creation of resources and their life cycle. In this first article, we will explore the basic notions of Terraform. After reading it, you should be able to write a Terraform configuration file to deploy and customise a virtual machine from a template. In a second article, we will build on this example, and modify it so that it is more generic and can be easily adapted to your needs.
Installation
Terraform is available on the HashiCorp website for almost all OSs as a simple binary. Just download it and copy it into a directory in your operating system PATH. To test that everything is working properly, run the terraform command.
$ terraform
Usage: terraform [-version] [-help] <command> [args]
The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.
Common commands:
apply Builds or changes infrastructure
console Interactive console for Terraform interpolations
destroy Destroy Terraform-managed infrastructureFolders and files
Like other Infrastructure-as- a-Code tools, Terraform uses simple files to define the target configuration. To begin, we will create a directory and place a file named main.tf. By default, Terraform will read all the files in the working directory with the .tf extension, but to simplify things, we will start with a single file. We will see in a future article how to organise the data into several files.
Similarly, to make it easier to understand Terraform operations, we will specify all the necessary information directly in the files. This includes usernames, passwords and names of different resources (vCenter, cluster, etc.). It is obviously not advisable to do this in order to use Terraform in production. The second article will also be an opportunity to improve this part of the code. But for now, let’s keep it simple!
Providers
The providers let you specify how Terraform will communicate with the outside world. In our example, the vSphere provider will be in charge of connecting with your Private Cloud’s vCenter. We declare a provider as follows:
provider "vsphere" {
user = "admin"
password = "MyAwesomePassword"
vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}We see here that Terraform uses its own way of structuring data (it is also possible to write everything in JSON to facilitate the automatic generation of files! ). Data is grouped in blocks (here a block named vsphere, which is of the provider type) and the data relating to the block are in the form of keys/values.
Data
Now that Terraform is able to connect to the vCenter, we need to retrieve information about the vSphere infrastructure. Since we want to deploy a virtual machine, we need to know the datacentre, cluster, template, etc., and where we are going to create it. To do this, we will use data-type blocks:
data "vsphere_datacenter" "dc" {
name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}
data "vsphere_datastore" "datastore" {
name = "pcc-001234"
datacenter_id = "${data.vsphere_datacenter.dc.id}"
}
data "vsphere_virtual_machine" "template" {
name = "UBUNTU"
datacenter_id = "${data.vsphere_datacenter.dc.id}"
}In the above example, we are trying to get information about the datacentre named pcc-XXX-XXX-XXX-XXX_datacenter3113 and get the information from the datastore named pcc-001234 and a template whose name is UBUNTU. We see here that we use the datacentre id to get information about an object associated with it.
Resources
The resources will be used to create and/or manage elements of the infrastructure. In our example, we will use a resource of type virtual_machine, which as its name suggests, will help us to create a VM.
resource "vsphere_virtual_machine" "vm" {
name = "vm01"
resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
datastore_id = "${data.vsphere_datastore.datastore.id}"
guest_id = "${data.vsphere_virtual_machine.template.guest_id}"
scsi_type = "${data.vsphere_virtual_machine.template.scsi_type}"
network_interface {
network_id = "${data.vsphere_network.network.id}"
}
disk {
label = "disk0"
size = "${data.vsphere_virtual_machine.template.disks.0.size}"
}
clone {
template_uuid = "${data.vsphere_virtual_machine.template.id}"
customize {
linux_options {
host_name = "vm01"
domain = "example.com"
}
network_interface {
ipv4_address = "192.168.1.2"
ipv4_netmask = 24
}
ipv4_gateway = "192.168.1.254"
dns_suffix_list = ["example.com"]
dns_server_list = ["192.168.1.1"]
}
}
}
The structure of this resource is a little more complex, because it is composed of several sub-blocks. We see that we will first define the name of the virtual machine. We then provide information about its configuration (Resource pool, datastore, etc.). The network_interface and disk blocks are used to specify the configuration of its virtual devices. The clone sub-block will let you specify which template you wish to use to create the VM, and also to specify the configuration information of the operating system installed on the VM. The customize sub-block is specific to the type of OS you want to clone. At all levels, we use information previously obtained in the data blocks.
Full example
provider "vsphere" {
user = "admin"
password = "MyAwesomePassword"
vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}
data "vsphere_datacenter" "dc" {
name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}
data "vsphere_datastore" "datastore" {
name = "pcc-001234"
datacenter_id = "${data.vsphere_datacenter.dc.id}"
}
data "vsphere_compute_cluster" "cluster" {
name = "Cluster1"
datacenter_id = "${data.vsphere_datacenter.dc.id}"
}
data "vsphere_network" "network" {
name = "vxw-dvs-57-virtualwire-2-sid-5001-Dc3113_5001"
datacenter_id = "${data.vsphere_datacenter.dc.id}"
}
data "vsphere_virtual_machine" "template" {
name = "UBUNTU"
datacenter_id = "${data.vsphere_datacenter.dc.id}"
}
resource "vsphere_virtual_machine" "vm" {
name = "vm01"
resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
datastore_id = "${data.vsphere_datastore.datastore.id}"
guest_id = "${data.vsphere_virtual_machine.template.guest_id}"
scsi_type = "${data.vsphere_virtual_machine.template.scsi_type}"
network_interface {
network_id = "${data.vsphere_network.network.id}"
}
disk {
label = "disk0"
size = "${data.vsphere_virtual_machine.template.disks.0.size}"
}
clone {
template_uuid = "${data.vsphere_virtual_machine.template.id}"
customize {
linux_options {
host_name = "vm01"
domain = "example.com"
}
network_interface {
ipv4_address = "192.168.1.2"
ipv4_netmask = 24
}
ipv4_gateway = "192.168.1.254"
dns_suffix_list = ["example.com"]
dns_server_list = ["192.168.1.1"]
}
}
}3… 2… 1… Ignition
Let’s look at how to use our new config file with Terraform…
Initialisation
Now that our configuration file is ready, we will be able to use it to create our virtual machine. Let’s start by initialising the working environment with the terraform init command. This will take care of downloading the vSphere provider and create the different files that Terraform needs to work.
$ terraform init
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "vsphere" (1.10.0)...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
...
* provider.vsphere: version = "~> 1.10"
Terraform has been successfully initialized!
...Plan
The next step is to execute the terraform plan command to validate that our configuration file contains no errors and to visualise all the actions that Terraform will perform.
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
+ vsphere_virtual_machine.vm
id: <computed>
boot_retry_delay: "10000"
change_version: <computed>
clone.#: "1"
clone.0.customize.#: "1"
clone.0.customize.0.dns_server_list.#: "1"
clone.0.customize.0.dns_server_list.0: "192.168.1.1"
clone.0.customize.0.dns_suffix_list.#: "1"
clone.0.customize.0.dns_suffix_list.0: "example.com"
clone.0.customize.0.ipv4_gateway: "172.16.0.1"
clone.0.customize.0.linux_options.#: "1"
clone.0.customize.0.linux_options.0.domain: "example.com"
clone.0.customize.0.linux_options.0.host_name: "vm01"
clone.0.customize.0.linux_options.0.hw_clock_utc: "true"
clone.0.customize.0.network_interface.#: "1"
clone.0.customize.0.network_interface.0.ipv4_address: "192.168.1.2"
clone.0.customize.0.network_interface.0.ipv4_netmask: "16"
clone.0.customize.0.timeout: "10"
clone.0.template_uuid: "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
clone.0.timeout: "30"
cpu_limit: "-1"
cpu_share_count: <computed>
cpu_share_level: "normal"
datastore_id: "datastore-93"
default_ip_address: <computed>
disk.#: "1"
disk.0.attach: "false"
disk.0.datastore_id: "<computed>"
disk.0.device_address: <computed>
...
Plan: 1 to add, 0 to change, 0 to destroy.
It is important to take time to check all information returned by the plan command before proceeding. It would be a mess to delete virtual machines in production due to an error in the configuration file… In the example below, we see that Terraform will create a new resource (here a VM) and not modify or delete anything, which is exactly the goal!
Apply
In the last step, the terraform apply command will actually configure the infrastructure according to the information present in the configuration file. As a first step, the plan command will be executed, and Terraform will ask you to validate by typing yes.
$ terraform apply
...
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
vsphere_virtual_machine.vm: Creating...
boot_retry_delay: "" => "10000"
change_version: "" => "<computed>"
clone.#: "" => "1"
clone.0.customize.#: "" => "1"
clone.0.customize.0.dns_server_list.#: "" => "1"
clone.0.customize.0.dns_server_list.0: "" => "192.168.1.1"
clone.0.customize.0.dns_suffix_list.#: "" => "1"
clone.0.customize.0.dns_suffix_list.0: "" => "example.com"
clone.0.customize.0.ipv4_gateway: "" => "192.168.1.254"
clone.0.customize.0.linux_options.#: "" => "1"
clone.0.customize.0.linux_options.0.domain: "" => "example.com"
clone.0.customize.0.linux_options.0.host_name: "" => "terraform-test"
clone.0.customize.0.linux_options.0.hw_clock_utc: "" => "true"
clone.0.customize.0.network_interface.#: "" => "1"
clone.0.customize.0.network_interface.0.ipv4_address: "" => "192.168.1.2"
clone.0.customize.0.network_interface.0.ipv4_netmask: "" => "16"
clone.0.customize.0.timeout: "" => "10"
clone.0.template_uuid: "" => "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
clone.0.timeout: "" => "30"
cpu_limit: "" => "-1"
cpu_share_count: "" => "<computed>"
cpu_share_level: "" => "normal"
datastore_id: "" => "datastore-93"
default_ip_address: "" => "<computed>"
disk.#: "" => "1"
...
vsphere_virtual_machine.vm: Still creating... (10s elapsed)
vsphere_virtual_machine.vm: Still creating... (20s elapsed)
vsphere_virtual_machine.vm: Still creating... (30s elapsed)
...
vsphere_virtual_machine.vm: Still creating... (1m50s elapsed)
vsphere_virtual_machine.vm: Creation complete after 1m55s (ID: 42068313-d169-03ff-9c55-a23e66a44b48)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.When you connect to the vCenter of your Private Cloud, you should see a new virtual machine in the inventory!
Next steps
Now that we have seen a standard Terraform workflow, you may want to test some modifications to your configuration file. For example, you can add another virtual disk to your VM by modifying the virtual_machine resource’s block like this:
disk {
label = "disk0"
size = "${data.vsphere_virtual_machine.template.disks.0.size}"
}
disk {
label = "disk1"
size = "${data.vsphere_virtual_machine.template.disks.0.size}"
unit_number = 1
}Then run terraform plan to see what Terraform is going to do to in order to reconcile the infrastructure state with your configuration file.
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 4206be6f-f462-c424-d386-7bd0a0d2cfae)
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ vsphere_virtual_machine.vm
disk.#: "1" => "2"
disk.1.attach: "" => "false"
disk.1.datastore_id: "" => "<computed>"
...
Plan: 0 to add, 1 to change, 0 to destroy.If you agree with terraform action’s proposal, you can rerun terraform apply, to add a new virtual disk to your virtual machine.
Clean it up
When you have finished your tests and you no longer require the utility of the infrastructure, you can simply run the terraform destroy command to delete all previously-created resources. Be careful with this command, as there is no way to get your data back after that!
$ terraform destroy
data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy
Terraform will perform the following actions:
- vsphere_virtual_machine.vm
Plan: 0 to add, 0 to change, 1 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
vsphere_virtual_machine.vm: Destroying... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)
vsphere_virtual_machine.vm: Destruction complete after 3s
Destroy complete! Resources: 1 destroyed.In this article, we have seen how to deploy a virtual machine with a Terraform configuration file. This allowed us to learn the basic commands plan, apply and destroy, as well as the notions of provider, data and resource. In the next article, we will develop this example, by modifying it to make it more adaptable and generic.
