Turbonomic Blog

IaC Powering a Monolith to Multi-VM Architecture – Part 2

Posted by Eric Wright on Jun 4, 2020 2:57:44 PM
Eric Wright
Find me on:

Our first post in the series introduced the scenario where our IT teams on the Cloud Rush application had an application needing to make its way to production. This is often the case where the Ops team is handed the working version and asked to work backwards. It’s also important that the reason this happens is that development teams often feel like they have to do a lot on their own to get products built faster. This is our chance to bring those two teams together and use the power of good IT architecture and Infrastructure-as-Code to ensure both speed and consistency of outcome.

Design | Code | Build | Repeat

We always start from a good design and then move to the build process. Early work in testing needs a bit of a mix where you do some test builds that will help to validate the deployment style. You will use this viable test app along with the business and architectural requirements to define how we turn these ideas into codified deployments.

Let’s start by working on codifying the MVP that was brought to the Ops group by the Cloud Rush development team.

Figure 1 – Current Physical Architecture

C2CN-CloudRush-Physical-Current

There were no mentions of how we would codify the build in the Requirements, Constraints, Assumptions, and Risks. This means we have freedom to bring products in to do this and our team has decided that Terraform is going to be the tool of choice in this case. Our infrastructure is VMware and we don’t have Terraform Enterprise, so we have to make sure to account for risks and constraints of our IaC platform.

This means we have to enhance our architecture doc a bit:

Requirements
  • Must be able to receive customer sign ups from the internet
  • Data gathered must be stored in a shared database for data mining and sharing with other applications
  • There will be no single point of failure
  • Deployments will be done using an Infrastructure-as-Code (IaC) solution
Constraints
  • Application must be hosted in a private data center for regulatory reasons
  • Ruby on Rails must be used for the application platform
  • Database must be MySQL to support other back-end processes and current software availability
  • Phase 2 will use MongoDB for a NoSQL solution to store some data
  • Infrastructure must be VMware virtualization
  • Terraform OSS/CLI must be used for the IaC platform
  • Dev teams must be able to deploy a dev instance of the application infrastructure
Assumptions
  • Application code and supporting libraries will be available with ongoing support for production
  • Application developers are able to modify application as needed for scale-out architecture
  • IaC processes will be performed by both the Ops and Dev teams depending on the environment
Risks
  • Application may not support a scale-out design at high volume
  • Testing “at-scale” is not part of the MVP and will be introduced later
  • Terraform CLI/OSS will not have shared state management and must be used from centralized control VM
Getting Started with our Terraform for VMware Environment

You’ll need a couple of things to be ready for kicking off our initial build of a Terraform configuration:

  • vCenter URL
  • Terraform executable (OSS/CLI)
  • Credentials with rights to deploy a VM
  • Template VM for our application

Our template will be built using Photon Linux and will have the binaries and libraries already installed for the Ruby on Rails app with a local instance of MySQL. You aren’t going to need this VM packaged up yourself as it is the interim step just to prove out our initial Terraform workflow. Any template will do.

Your Basic Terraform Configuration

Terraform will be used with a simple template process pointing at a VMware vCenter server. There will be 5 files that you create which are:

  • variables.tf – where we keep our variable assignments and descriptions
  • data.tf – data entries to be used by our resources
  • main.tf – the core section of code that defines our resources
  • outputs.tf – where we define what outputs we want like IP address
  • provider.tf – where we set our VMware provider information

The full code samples are located here so we don’t have to list the entire files for you: https://github.com/turbonomiclabs/c2cn-terraform-samples

Setting up your Environment Variables

To configure your environment, you should use environment variables. This is more of a 12-factor method which is kind of where we would like to go. Shipping codified configurations that use environment variables means that each developer and each version of the build can be individualized easily.

My configuration file has the following variables defined. You will have to update with your appropriate credentials, vCenter URL, cluster, resource pools, etc.:

TF_VAR_vsphere_user=username@cluster.domain.name
TF_VAR_vsphere_password=PASSWORD
TF_VAR_vsphere_server=myvc.domain.name
TF_VAR_vsphere_cluster=CLUSTER
TF_VAR_vsphere_datacenter=DATACENTER
TF_VAR_vsphere_datastore=DATASTORE
TF_VAR_vsphere_resource_pool=RESOURCEPOOL
TF_VAR_wait_for_guest_net_timeout=0

Just clone the git repository and begin with the part2 folder. By initiating a terraform apply you will see the new machine spin up very quickly without any need to interact with it. Once the VM is online you also get the outputs which show you the allocated IP address (both IPv4 and IPv6).

c2cn-p2-terraform-apply

That is the first basic step. You now have a repeatable process to spin up the machine. Removing the newly crafted VM is as easy as typing terraform destroy and confirming at the prompt.

Our next blog goes to the next level of breaking out the configuration for multiple machine groups which prepares us for the service-based scaling architecture as defined in our physical design. This is where the real fun begins!

Subscribe Here!

Recent Posts