#Blogtober - vSphere and Infrastructure as Code- 2 mins
This post was previously hosted on a different site and then migrated here.
Part 1 - What is “Infrastructure as Code”?
Infrastructure as Code, or programmable infrastructure (my preferred term), is the practice of managing and defining the configurations, and automating the deployment, of infrastructure components. There are several benefits to using this kind of methodology, not least bringing things like version control, automated testing and staging, and predictable delivery to infrastructure deployments.
There are typically two kinds of software used to manage programmable infrastructure - Orchestrators, and Configuration Management tools.
Orchestrators: Orchestrators typically use codified infrastructure files to provision and build servers, or datacentre objects, automatically, based upon the values specified in their configuration files. Popular examples of this kind of software include Terraform, and AWS Cloudformation.
Config Management tools: Configuration management tools, such as Chef, Puppet, and Ansible, take this a step further. They are predominently designed to install and manage software on existing servers. Again, this is an excellent method to ensure consistent deployment of applications, and to mitigate things such as configuration drift across servers through their lifecycle.
Over the course of #blogtober, which clearly I’m starting late, I’ll show a series of posts around manipulating vSphere with both an Orchestrator, and then how to use a Config Management tool to install and manage applications within VMs.
I’m going to be using Terraform and Chef for the purposes of this series, and although I am familiar with Terraform, I will be learning Chef as we go, which is always fun. So go easy on me…
At a high level, Terraform uses a series of components to interact with your environment (or a public cloud platform). These include:
Providers: Terraform supports multiple providers, be they Public Cloud platforms like AWS or Azure, Docker, OpenStack, or as we’re going to see here vSphere. I have heard exciting rumours about a Nutanix provider about to drop, too. A full list can be found on GitHub…
Resources: Resources is where you define your components, be that a server, a VM, or whatever.
Provisioners: Provisioners is where you can call an additional 3rd party config management tool, in our case Chef, or execute scripts to bootstrap or manage the resource Terraform has just created.
To close of this first #blogtober post all we need to do is install Terraform.
Because Terraform is written in Go, it’s a piece of cake to install regardless of your platform. I’m using a Mac, so all I need to do is to pull it down from Homebrew with the following command:
brew install terraform
If you’re using Windows or Linux you should just be able to download the Terraform binary and place it into a location in your $path.
In the next post we’ll look at how to provision vSphere VMs using the Terraform vSphere provider.