Introduction to Terraform Modules

In Part 1 of this series I compared traditional programming languages to Terraform. We can do the same thing with Modules. For example, with Powershell or Python, you can download a module that provides functionality and consume that functionality in your code without having to author it. The same thing happens in Terraform, and just like with other languages, you can create your own, or download one from a third party.

Terraform Registry

Thankfully, Hashicorp provides us with a registry that we can use to find and consume Terraform Modules. At the time this post is published, the Terraform Registry contains support for 63 providers and has 3454 Modules. So if you are looking for specific functionality, check there first!

Roll Your Own Module

That said, you may have a need to create your own module, or if you’re like me, want to make sure you understand how modules work before you use one that someone else created.

Best Practices

First and foremost, you’ll want to take a look at the official documentation from Hashicorp on the standard module structure. It gets pretty in-depth, but I’ll hit on a few high level important items.

• Store your module in github
• At the very least, make sure you split your variables and outputs into different TF files
• Include an examples directory and show every variation of how to call your module. For example, if you can create a linux image or a windows image, but you need to call them differently, show an example for each.
• Include a README.md file that has a description of the module, but also references your examples

Why store your module in GitHub?

Aside from the wide ranging benefits of using version control, using GitHub will allow you to call a specific version of your module.

File Structure

The following files should be in your GitHub reposity. When you run terraform init, it will be downloaded to the .terraform directory on the machine running the project.

main.tf

variables.tf

output.tf

How to use this module?

Now that we’ve created our module and have it in Github, all we need to do in order to complete our initial goal of having a three tier application is to create a single main.tf file, and call the module 3 times. Below is an example that allows us to set separate information for each of the new VMs.

References and what’s next?

What’s Next?

At this point we have shown how to create and manage images using packer, a couple of parts on how to use Terraform to deploy infrastructure, so all we have left is doing configuration of our newly created VMs.

• Use Ansible to configure our newly provisioned VMs
• Wrap the Terraform VM Deployment process, as well as the Ansible VM configuration process together into a single process you execute once
• Use Ansible to do a greenfield deployment of a vSphere environment

References

• Part 1 – Provision VMware VMs using Terraform
• Terraform Registry
• Module Structure

The post VMware Provisioning using Hashicorp Terraform – Part 2 appeared first on VirtJunkie.

Jitsi is an open source video conferencing platform that I’ve been hearing about a lot lately, and finally had a chance to look into. In this post I’ll explain how to use Terraform to provision a Jitsi instance when you need a conference and tear it down when you are done. We’ll be using Vultr and their Jitsi “application” and AWS Route 53 for DNS.

Why Am I Writing This Article, and What Does It Accomplish?

Why am I writing this article?

1. We always want to have our apps and infrastructure defined in code
2. We pay for traditional web conferencing software 24 hours a day, 7 days a week, regardless of if we are are using running a conference or not. Why don’t we spin up conference infrastructure when we need it, and tear it down when we don’t?

At a high level, this project will accomplish the following:

1. Provision a Vultr VPS that is pre-configured with Jitsi
2. Take the IP Address that Vultr assigns the VPS and use it to create an A Record in Route 53
3. Copy a script to your VPS that will be used to finish the Jitsi configuration
4. Run the script that we copied and pass a few command line arguments that are specific to our environment

Prerequisites

In addition to having Terraform downloaded and installed, we’ll need the following items:

Vultr Account + API Access

Vultr is definitely my go-to for VPS’s these days. Not only because of their price/performance/feature availability ratio, but because they provide a number of pre-configured applications that are ready, or near ready for use. Jitsi is one of these applications. If you do use Vultr, please do me a favor and use this link to sign up. I’ll get a little kickback, but you’ll get $100 USD to use on the site in your first month.

Once you have a Vultr account, you’ll need to generate and record an API key to use with Terraform. Use the steps below to generate it.

1. Log into Vultr
2. Navigate to Settings, and then API
3. Generate an API key, and copy it somewhere safe, we’ll be using it later

AWS Account + API Access

We’ll be using AWS’s Route 53 service, which is really just a fancy DNS service that’s hooked into AWS. In order to automate Route 53 with Terraform, we’ll need to enable API access.

Use this link to access the IAM Management page

1. Expand the “Access Keys” blade
2. Select “Create New Access Key
3. Save the resulting file, as we’ll use the contents later

Domain Registrar Using Custom Nameservers

In addition to the above, the domain you want to use will need to be configured to use the Route 53 Name Servers. Route 53 will provide you the nameservers when you create a zone, and you’ll simply plug those into your registrar DNS settings page. I’m not going to explain how to create a zone in Route 53, or how to configure your registrar, but if you have questions, throw them in the comments and I’ll do my best to help.

Getting Started

Run This Project

1. Grab the files below, or copy them from my Github Repository
2. Enter the directory that contains the files
3. At a minimum, modify the fields in the auto.tfvars file
   1. vultr_api_key
   1. aws_access_key
   2. aws_secret_key
   3. domain
   4. email
4. Initialize Terraform by running terraform init
5. Create a terraform plan by running terraform plan
6. Apply the configuration by running terraform apply
7. Voila! In less than 5 minutes, you’ve got a functional, secure Jitsi instance, running on a server and domain you control. Upon successful creation, you’ll see text like what we see below giving you the URL and credentials. When you are done with your conference, just run terraform destroy to stop from receiving charges on a server/service you aren’t using.

null_resource.jitsi_config (remote-exec): ------------------------------
null_resource.jitsi_config (remote-exec): |                            |
null_resource.jitsi_config (remote-exec): |   JITSI SETUP COMPLETED!   |
null_resource.jitsi_config (remote-exec): |                            |
null_resource.jitsi_config (remote-exec): ------------------------------
null_resource.jitsi_config (remote-exec): JITSI URL: https://conference.yourdomain.com/

null_resource.jitsi_config (remote-exec): USERNAME: admin
null_resource.jitsi_config (remote-exec): PASSWORD: @#$asdfahgsd34579--23%4asdf

Code

Main.tf

This file does all of the work.

#main.tf
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53

#Conifugre the Vultr provider
provider "vultr" {
  api_key = var.vultr_api_key
  rate_limit = 700
  retry_limit = 3
}

#Configure the AWS Provider
provider "aws" {
  #profile    = "default"
  #shared_credentials_file = "/home/jhowe/storage/btsync/folders/Sync/awscredentials/credentials"
  region     = var.aws_region
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

#https://www.terraform.io/docs/providers/aws/d/route53_zone.html
data "aws_route53_zone" "selected" {
  name         = "${var.domain}."
  private_zone = false
}

#Provision Vultr Server
resource "vultr_server" "my_server" {
    plan_id = var.vultr_plan_id
    region_id = var.vultr_region
    app_id = var.vultr_app_id
    label = "${var.hostname}.${var.domain}"
    tag = var.vultr_tag
    hostname = "${var.hostname}.${var.domain}"
    enable_ipv6 = false
    auto_backup = false
    ddos_protection = false
    notify_activate = false

    connection {
        type     = "ssh"
        user     = "root"
        
        #https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
        password = self.default_password

        #https://www.terraform.io/docs/provisioners/connection.html#the-self-object
        host     = self.main_ip
    }

    provisioner "local-exec" {
      command = "echo SSH to this server with the command: ssh root@${vultr_server.my_server.main_ip} with the password '${vultr_server.my_server.default_password}'"
    }
}

#Create the Route 53 A Record
#https://www.terraform.io/docs/providers/aws/r/route53_record.html
resource "aws_route53_record" "conference" {
  zone_id = data.aws_route53_zone.selected.zone_id
  name    = "${var.hostname}.${data.aws_route53_zone.selected.name}"
  type    = "A"
  ttl     = "300"
  records = ["${vultr_server.my_server.main_ip}"]
}

#This null resource exists to handle configuration of the Vultr VPS after Route 53
resource "null_resource" "jitsi_config" {
    
    connection {
        type     = "ssh"
        user     = "root"
        
        #https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
        password = vultr_server.my_server.default_password

        #https://www.terraform.io/docs/provisioners/connection.html#the-self-object
        host     = vultr_server.my_server.main_ip
    }

    provisioner "file" {
        source      = "./configure_jitsi_param.sh"
        destination = "/root/configure_jitsi_param.sh"
    }

    provisioner "remote-exec" {
        inline = [
            "chmod +x /root/configure_jitsi_param.sh",
            "/root/configure_jitsi_param.sh ${var.hostname}.${var.domain} ${var.email} y"
        ]
    }
}

Variables.tf

This file defines the variables that we will use in main.tf

#variables.tf
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53

variable "vultr_api_key" {
    description = "API Key Used by Vultr (https://my.vultr.com/settings/#settingsapi)"
}

variable "vultr_region" {
    description = "Vultr Region Selection (curl https://api.vultr.com/v1/regions/availability?DCID=1)"
    default = 1
}

variable "vultr_plan_id" {
    description = "Vultr Plan for the VPS to use (curl https://api.vultr.com/v1/plans/list)"
    default = 202
}

variable "vultr_tag" {
    description = "Vultr Tag to apply to the new VPS"
    default = "jitsi-conference"
}

variable "vultr_app_id" {
    description = "Vultr App to pre-install. This should always be '47', if jitsi is being provisioned (curl https://api.vultr.com/v1/app/list)"
    default = 47
}

variable "hostname" {
    description = "Hostname to be used"
    default = "conferences"
}

variable "email" {
    description = "email to be used for let's encrypt acme config"
    default = "john.doe@email.com"
}

variable "domain" {
    description = "domain to be used"
    default = "aremyj.am"
}

variable "aws_access_key" {
    description = "AWS Access Key - get it here: (https://console.aws.amazon.com/iam/home?#security_credential)"
}

variable "aws_secret_key" {
    description = "AWS Secret Key - get it here: (https://console.aws.amazon.com/iam/home?#security_credential)"
}

variable "aws_region" {
    description = "AWS Region"
    default = "us-east-1"
}

[yourdomain].auto.tfvars

The auto.tfvars file provides values to the variables defined in the variables.tf file. You’ll have to create this file from scratch, and terraform best practices dictate that you exclude this file from source control. Here’s an example you can use. Modify this for your environment. The name doesn’t matter, as long as it ends with auto.tfvars.

vultr_api_key = "[fill this in]"
vultr_region = 1
vultr_plan_id = 202
vultr_app_id = 47
vultr_tag = "jitsi-conference"
hostname = "conference"
email = "your.email@address.org"
domain = "your-domain.com"
aws_region = "us-east-1"
aws_access_key = "[fill this in]"
aws_secret_key = "[fill this in]"

configure_jitsi_param.sh

Full disclosure, I did not create this script. Vultr created it, and provides it on your Jitsi VPS when you request it. Unfortunately, the version they provide is intended to be executed interactively, so I made a few very minor modifications to allow for us to run it with parameters.

#!/bin/bash
#This script was copied from /opt/vultr/configure_jitsi.sh on a Vultr VPS that has the one-click Jitsi App
#I added lines 7-9 to allow for adding parameters on the CLI and commented lines 11-13 to force the variables to be provided on the CLI
#https://www.vultr.com/docs/one-click-jitsi
#https://www.virtjunkie.com/jitsi-jit-conferencing-tf-vultr-route53/
#https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53
HOSTNAME=$1
EMAIL=$2
response=$3
# User choices
#read -ep "Please specify which domain you would like to use: " HOSTNAME
#read -ep "Please enter your email address for Let's Encrypt Registration: " EMAIL
#read -r -p "Would you like to enable password authorization? [y/N] " response
case "$response" in
    [yY][eE][sS]|[yY])
        AUTH=1
        ;;
    *)
        AUTH=0
        ;;
esac


PROSODYPATH=/etc/prosody/conf.avail/${HOSTNAME}.cfg.lua
JITSIPATH=/etc/jitsi/meet/${HOSTNAME}-config.js
JICOFOPATH=/etc/jitsi/jicofo/sip-communicator.properties

# Remove and purge (Stop first and wait to avoid race condition)
purgeold() {        
        /opt/vultr/stopjitsi.sh
        sleep 5
        apt -y purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2 jitsi*
}

# Reinstall
reinstalljitsi() {
        echo "jitsi-videobridge2 jitsi-videobridge/jvb-hostname string ${HOSTNAME}" | debconf-set-selections
        echo "jitsi-meet-web-config jitsi-meet/cert-choice string Generate a new self-signed certificate (You will later get a chance to obtain a Let's encrypt certificate)" | debconf-set-selections
        apt-get -y install jitsi-meet
}

# Remove nginx defaults
wipenginx() {
        rm -f /etc/nginx/sites-enabled/default
}

# Configure Lets Encrypt
configssl(){
    systemctl restart nginx
    sed -i -e 's/echo.*Enter your email and press.*/EMAIL=$1/' /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
    sed -i -e 's/read EMAIL//'  /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
    /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh ${EMAIL}
}

configprosody() {
  AUHTLINE='authentication = "internal_plain"'
  sed -i "s/authentication\ \=\ \"anonymous\"/${AUTHLINE}/g" ${PROSODYPATH}
  cat << EOT >> ${PROSODYPATH}

VirtualHost "guest.${HOSTNAME}"
    authentication = "anonymous"
    c2s_require_encryption = false

EOT
}

configjitsi() {
        sed -i "s/\/\/\ anonymousdomain\:\ 'guest.example.com',/anonymousdomain\:\ 'guest.${HOSTNAME}',/g" ${JITSIPATH}
}

configjicofo() {
        echo "org.jitsi.jicofo.auth.URL=XMPP:${HOSTNAME}" >> ${JICOFOPATH}
}

registeruser(){
        PASSWORD=$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-16};echo;)
        prosodyctl register admin ${HOSTNAME} ${PASSWORD}
}

restartjitsi() {
        /opt/vultr/stopjitsi.sh
        /opt/vultr/startjitsi.sh
}

completedsetup(){
    echo ""
    echo "------------------------------"
    echo "|                            |"
    echo "|   JITSI SETUP COMPLETED!   |"
    echo "|                            |"
    echo "------------------------------"
    echo "JITSI URL: https://${HOSTNAME}"/
    echo ""
}

outputUser(){
    echo "USERNAME: admin"
    echo "PASSWORD: ${PASSWORD}"
    echo ""
}

# Script start

purgeold
reinstalljitsi
wipenginx
configssl
if [ "$AUTH" == "1" ]; then
    configprosody
    configjitsi
    configjicofo
    registeruser
    restartjitsi    
fi
completedsetup
if [ "$AUTH" == "1" ]; then
    outputUser
fi

Summary + More Reading

There you have it! With this project you can have a fully functional Jitsi instance on your own domain with end to end encryption in less than 5 minutes. When you are done, there’s no harm in deleting it so you aren’t charged.

Here are some references I used while creating this:

• https://github.com/jonhowe/Virtjunkie.com/tree/master/Jitsi-JIT-Conferencing-TF-Vultr-Route53
• https://www.vultr.com/docs/one-click-jitsi
• https://www.terraform.io/docs/providers/aws/d/route53_zone.html
• https://www.terraform.io/docs/providers/aws/r/route53_record.html
• https://www.terraform.io/docs/providers/vultr/r/server.html#default_password
• https://www.terraform.io/docs/provisioners/connection.html#the-self-object
• Create Vultr API Key: https://my.vultr.com/settings/#settingsapi
• Create AWS Access/Secret Key: https://console.aws.amazon.com/iam/home?#security_credential
• Vultr API Reference – has examples that will get you plan, region, and app IDs. https://www.vultr.com/api/

The post Jitsi for Just in Time Conferencing using Terraform on Vultr with Route 53 appeared first on VirtJunkie.

Source Code

As always, you can find all of the source code for this project on my Github account.

Deploying VMware Templates in vCenter

Nothing new here.. log into vCenter, deploy a VM from a template, use a guest customization specification. The pro’s are obvious, so I’ll skip over them and focus on the cons.

Deploy VMs via Ansible

Ansible communicates with an OS via SSH on Linux, and via WinRM on Windows. It has different modules that can be used to communicate with different providers, such as AWS, GCP, and yes, VMware.

Pros:

• Infrastructure is defined in code
• Excellent at ensuring desired state configuration of
• Multi-os, and multi-cloud support

Cons:

• This could end up being a bit of a holy war, but I consider it a con that Ansible requires different modules to connect to different cloud providers. They are maintained by different teams and individuals, and end up working differently than each other.

Deploy VMs using Terraform

Terraform, similarly to Ansible, is able to communicate with Linux via SSH and Windows via WinRM. Where it differs, is it’s ability to communicate with cloud providers such as AWS, GCP, Azure, and VMware. Terraform uses the concept of “Providers”, with a number of them being maintained by Hashicorp, and a number of them being maintained by the community. In addition to cloud providers, they also have providers that allow for configuration of networking hardware, storage, databases, monitoring, DNS systems, and many more, all using the same structure in your code.

Terraform Component Overview

Few points to get us started here:

• Terraform will look in a directory for all files that have the extension of .tf, and .auto.tfvars
• Terraform configuration files are written in a language called HCL, but can also be written in JSON.
• Terraform uses the concept of blocks, I’ll go through them below

Resource Block

Hashicorp defines resources as the most important element in the Terraform language. Each resource block describes one or more infrastructure objects, such as virtual networks, compute instances, or higher-level components such as DNS records.

In our example, we will be working with the resource type “vsphere_virtual_machine” that is defined by the vSphere provider. This resource block contains all information needed to provision and customize a new VM.

Provider Block

We’ll be working with the vSphere provider in this project. Providers have two main functions we should keep in mind when using Terraform with VMware.

• They define parameters used to connect to vCenter
• They expose additional resources we can use. Most notably, the vsphere_virtual_machine resource.

Hashicorp Provider Documentation

Data Source Blocks

Hashicorp tells us that “Data sources allow data to be fetched or computed for use elsewhere in Terraform configuration. Use of data sources allows a Terraform configuration to make use of information defined outside of Terraform, or defined by another separate Terraform configuration” and that “Each provider may offer data sources alongside its set of resource types”.

To say this “cloud agnostically”, data sources allow us to fetch information from a provider (whether it be something like AWS, GCP, Azure, or vSphere), and use that information in a resource.

To say this in “VMware Speak”, we use data sources to pull information like a datacenter, cluster, datastore, or port group from a vCenter, and use it to build a VM.

Input Variable Block

Hashicorp’s documentation says that Input Variables “serve as parameters for a Terraform module, allowing aspects of the module to be customized without altering the module’s own source code, and allowing modules to be shared between different configurations“. To say this another way, input variables end up working like parameters added on the command line on a script.

Examples

Let’s put all of this together. I’ll give you two examples here, one for setting up a Linux VM and one for a Windows VM.

Provision Linux VM with Terraform

The three files below are required for this project, and can be found in the github repository.

├── main.tf
├── variables.tf
└── homelab.auto.tfvars

Quick Start

Run the following commands to get started!

git clone https://github.com/jonhowe/Virtjunkie.com.git
cd Virtjunkie.com/Terraform/SingleLinuxVM
terraform init
terraform plan
terraform apply

Running terraform init will set up the Terraform project. It will download any required modules and plugins for the project to be created. It will store all of it’s files in a hidden directory called “.terraform”.

The command terraform plan looks at the destination and determines what needs to change. Optionally, you can have Terraform store this “plan” in a file to be used at a later time. To do this, you’ll run this command: terraform plan -out myplan.tfplan. The extension and file name are not important.

Finally, the command terraform apply is used to make changes to the environment that were determined in the “plan” step. Optionally, you can tell terraform to “apply” based on the output. To do this, you’ll run the following command: terraform apply myplan.tfplan. This isn’t necessary for a single VM deployment, but if you are using automation, or deploying multiple VMs, it is more important.

main.tf

As the name states, this is the main file in the project. It contains the provider, data source, and resource blocks.

The provider block simply is pretty self explanatory. If this is your first time looking at a Terraform file, you’ll probably be interested in the var.”whatever” lines. In the provider block, there’s a variable in the variables.tf file called vsphere_user (and the others as well). The “var.” prefix tells us that we should look for this variable definition in an input variables block.

The data blocks take raw data from the vSphere environment (datacenter, datastore, cluster, and port group) and store them in variables used for building a VM.

To understand this a bit more, please take a look at the picture below. We are creating a variable called datacenter_id on line 19 and assigning it the value data.vsphere_datacenter.dc.id. Understanding this concept is key to understanding how Terraform creates and consumes variables. The below image will elaborate a bit. The value of data.vsphere_datacenter.dc.id is returned from the datacenter object in the vCenter Server.

I’ll be comparing the way that Terraform blocks work together to the way that a programming function works. I’ll be using the following pseudocode to show similarities. The main.tf file, alongside with the blocks it contains would correspond with the area below:

Line 40 – Resource block begins
Now that we understand how to reference values from input and data variables, most of this should be pretty clear. The one area I want to spend a little bit of time on is the customize block, starting on line 67. In this example, we are simply setting the host name and the domain inside of the provisioned VM. However, there you could set static networking, dns and the time zone as well, if you like.

Here’s the code for the main.tf file. It’s also available on github.

#The variables are all defined in the variables.tf file. The values assigned to the variables are set in the auto.tfvars file

provider "vsphere" {
  #https://www.terraform.io/docs/providers/vsphere/index.html
  user                 = var.vsphere_user
  password             = var.vsphere_password
  vsphere_server       = var.vsphere_server
  allow_unverified_ssl = true
}

data "vsphere_datacenter" "dc" {
  #https://www.terraform.io/docs/providers/vsphere/d/datacenter.html
  name = var.datacenter
}

data "vsphere_datastore" "datastore" {
  #https://www.terraform.io/docs/providers/vsphere/d/datastore.html
  name          = var.datastore
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_compute_cluster" "cluster" {
  #https://www.terraform.io/docs/providers/vsphere/d/compute_cluster.html
  var.cluster
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_network" "network" {
  #https://www.terraform.io/docs/providers/vsphere/d/network.html
  name          = var.portgroup
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_virtual_machine" "template" {
  #https://www.terraform.io/docs/providers/vsphere/d/virtual_machine.html
  name          = var.template_name
  datacenter_id = data.vsphere_datacenter.dc.id
}

resource "vsphere_virtual_machine" "vm" {
  #https://www.terraform.io/docs/providers/vsphere/r/virtual_machine.html
  name             = var.vm_name
  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id     = data.vsphere_datastore.datastore.id

  num_cpus = var.vcpu_count
  memory   = var.memory
  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
    adapter_type = data.vsphere_virtual_machine.template.network_interface_types[0]
  }

  disk {
    label            = "disk0"
    size             = data.vsphere_virtual_machine.template.disks.0.size
    eagerly_scrub    = data.vsphere_virtual_machine.template.disks.0.eagerly_scrub
    thin_provisioned = data.vsphere_virtual_machine.template.disks.0.thin_provisioned
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.template.id

    customize {
      #https://www.terraform.io/docs/providers/vsphere/r/virtual_machine.html#linux-customization-options
      linux_options {
        host_name = var.vm_name
        domain    = var.domain_name
      }

      #This example uses DHCP. To switch to static IP addresses, comment the line below...
      network_interface {}

      #... and uncomment this bloc
      /*
      network_interface {
        ipv4_address = var.vm_ip
        ipv4_netmask = var.vm_cidr
    }
      ipv4_gateway = var.default_gw
      dns_server_list = ["1.2.3.4"]
    */

    }

  }
}

variables.tf

Terraform can be most easily understood by comparing the structure of a project to a programming function. The main file is the body of the function, and it consumes values of variables to “do stuff”. Most programming languages require us to declare a variable before we can assign a value to it or use it. That’s really all the input variables block is for. In the example below, we are defining the variable name, providing a description for it, and assigning a default value.

If you want to use a pseudocode example, the variable definition below is the function of the input variable block, and the function of the entire variables.tf file

Here’s the code for the variables.tf file, which is also available on github.

variable "vsphere_server" {
  description = "vsphere server for the environment - EXAMPLE: vcenter01.hosted.local"
  default     = "vcenter.corp.lab"
}

variable "vsphere_user" {
  description = "vsphere server for the environment - EXAMPLE: vsphereuser"
  default     = "administrator@vsphere.local"
}

variable "vsphere_password" {
  description = "vsphere server password for the environment"
  default     = "VMware1!"
}

variable "adminpassword" { 
    default = "terraform" 
    description = "Administrator password for windows builds"
}

variable "datacenter" { 
    default = "Datacenter"
    description = "Datacenter name in vCenter"
}

variable "datastore" { 
    default = "vsanDatastore" 
    description = "datastore name in vCenter"
}

variable "cluster" { 
    default = "Cluster" 
    description = "Cluster name in vCenter"
}

variable "portgroup" { 
    default = "VM Network" 
    description = "Port Group new VM(s) will use"
}

variable "domain_name" { 
    default = "contoso.lan"
    description = "Domain Search name"
}
variable "default_gw" { 
    default = "172.16.1.1" 
    description = "Default Gateway"
}

variable "template_name" { 
    default = "Windows2019" 
    description = "VMware Template Name"
}

variable "vm_name" { 
    default = "WS19-1" 
    description = "New VM Name"

}

variable "vm_ip" { 
    default = "172.16.1.150" 
    description = "IP Address to assign to VM"
}

variable "vm_cidr" { 
    default = 24 
    description = "CIDR Block for VM"
}

variable "vcpu_count" { 
    default = 1 
    description = "How many vCPUs do you want?"
}

variable "memory" { 
    default = 1024 
    description = "RAM in MB"
}

homelab.auto.tfvars

If you’ve been reading in order up to this point, you understand the programming function analogy. Ansible will look in it’s directory for a file with the extension of .auto.tfvars. It will use it to assign values to input variables that are defined in the variables.tf file.

Below is a pseudo code example that shows how we’d compare terraform to a function in a conventional programming language.

Below is the tfvars file I use in my home lab, and for your reference, it’s also available on github.

vsphere_server = "vcenter.home.lab"

vsphere_user = "administrator@vsphere.local"

vsphere_password = "VMware1!"

adminpassword = "terraform" 

datacenter = "Datacenter"

datastore = "vsanDatastore" 

cluster = "Cluster"

portgroup = "100-LabNetwork" 

domain_name = "home.lab"

default_gw = "172.16.1.1" 

template_name = "Ubuntu18" 

vm_name = "Ubuntu18-1" 

vm_ip = "172.16.1.150"

vm_cidr = 24

vcpu_count = 1

memory = 1024

Provision Windows VM with Terraform

Since provisioning a Windows and Linux VM share literally everything in a virtual environment with exception of the OS itself, there’s not a whole lot that’s different in provisioning Windows VMs. The one are that is different is the Customize block inside of the Resource block.

We are handling this the exact same as the Linux VM, however, we have a handful of options we can add, such as

• Join a domain
• Execute a list of commands
• Add a product key
• Enable auto login for a specified amount of logins
• Supply your own SysPrep file

Here’s the code, but all files are stored on Github.

resource "vsphere_virtual_machine" "vm" {
  name             = var.vm_name
  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id     = data.vsphere_datastore.datastore.id

  num_cpus = var.vcpu_count
  memory   = var.memory
  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
    adapter_type = data.vsphere_virtual_machine.template.network_interface_types[0]
  }

  disk {
    label            = "disk0"
    size             = data.vsphere_virtual_machine.template.disks.0.size
    eagerly_scrub    = data.vsphere_virtual_machine.template.disks.0.eagerly_scrub
    thin_provisioned = data.vsphere_virtual_machine.template.disks.0.thin_provisioned
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.template.id

    customize {
      #https://www.terraform.io/docs/providers/vsphere/r/virtual_machine.html#windows-customization-options
      windows_options {
        computer_name  = var.vm_name
        admin_password = var.adminpassword
        /*
        join_domain = "cloud.local"
	      domain_admin_user = "administrator@cloud.local"
	      domain_admin_password = "password"
        run_once_command_list = [

        ]
        */
      }
      network_interface {}

      /*
      network_interface {
        ipv4_address = var.vm_ip
        ipv4_netmask = var.vm_cidr
      }
      ipv4_gateway = var.default_gw
      dns_server_list = ["1.2.3.4"]
      */
    }
  }
}

References

The following resources were helpful for me getting started, and I suggest you take a look at them as well.

The Terraform documentation is the best place to start (link)
Dmitry Teslya has a great article that got me started here, but like the packer article he created, wasn’t working for me. Highly recommend this one (link)

What’s next?

Good Question! At this point, I’ve written about how to manage images (read: vmware templates) using Packer. I’ve written this article, which speaks to how to deploy the VMs. The next things I’ll speak about are:

• Write our own Terraform Module, store it in Github, and use that, instead of a full Terraform project, so we can deploy multiple VMs, from different templates, all at once.
• Use Ansible to configure our newly provisioned VMs
• Wrap the Terraform VM Deployment process, as well as the Ansible VM configuration process together into a single process you execute once
• Use Ansible to do a greenfield deployment of a vSphere environment

The post VMware Provisioning using Hashicorp Terraform appeared first on VirtJunkie.