by Zoe Lu
As part of Catalyst’s operational activity we recently decided to try out Terraform in our orchestration toolset for a large piece of client infrastructure build. I was given the task of investigation and experimentation in using Terraform to stand up our application stacks.
This blog post does not aim to be a comprehensive overview of terraform, but I wanted to share my impressions and discoveries.
So, what is Terraform? Terraform is an open source solution that has come from the team at HashiCorp, who also brought us such cool tools as vagrant and packer. It’s one more of the many abstraction tool sets for orchestrated infrastructure builds, letting us deploy into a range of cloud platforms (i.e. AWS, Azure, OpenStack). One more way to provision and manage infrastructure.
My first production stack
The first stack that I used Terraform to build was for one of our Enterprise Moodle LMS customers. This involved the following components:
-
Multiple stateless front-end/application web servers running PHP under nginx, all behind a set of HA Load Balancers
-
GlusterFS clustered file system running over three storage nodes
-
HA PostgreSQL relational database solution
-
Other administration, syslog and monitoring compute components.
This application needs to be high availability with no single point of failure. The target platform in this case was AWS.
The good
Basic stuff is easy
Terraform is quite straightforward to get started with some basic stack elements. There are plenty of examples, meaning I could spin up the beginnings of a stack on day one. Also the markup for templates is very readable.
Execution rehearsal
It’s great that before I fire off some new infrastructure, Terraform provides a dry-run launch feature ‘plan’ – meaning I will see what Terraform is about to do before it does it for real. Useful as I was not always sure of what some of my changes would do. The below shows the plan output for a single AWS compute instance being spun up.
Terraform graphs
These are pretty cool. With one single command - terraform graph - this tool outputs a visual representation based on the execution plan. Showing relationships between the cloud resources, while highlighting dependencies. I found it useful that I could see which resources could be created independently.
Automagic dependency management
With some orchestration toolsets, I have had to implement manual waits and checks to ensure that stack components launch in the correct order. This can be quite onerous and time consuming. For example: application compute servers may need to be fully available before a load balancer is provisioned in front of them.
Terraform has some great smarts under the hood that manages many of these dependencies automatically. Once a stack gets big enough, this is really useful.
The not so good
How to manage infrastructure long-term?
After building, changing and tearing down a number of application stacks using Terraform, I’m still not entirely sure how we should manage the inevitable future changes to a production stack using it.
There are a number of workable options, but none that look perfect as yet. I was always very aware that a mistake in my configuration templates applied to a real stack could have disastrous consequences.
What have we learned? How can we work around the constraints?
I found Terraform fairly flexible and easy to pick up.
Once I had my head around the way it worked, I was able to get to work quickly, building real application stacks on AWS.
I can see real operational advantages for us to using Terraform over AWS CloudFormation in some cases. However, I still think that Terraform has more appeal as the initial build tool than as the ongoing management mechanism.
The cross-platform support is also a big plus as we roll our solutions out to a number of cloud platforms. Given that some of our clients are moving towards internal private clouds, we need to avoid vendor lock-in as much as possible.
Also, we have been encouraged to see a high level of commits and improvements in Terraform (see github).
Thanks very much to Joel May for all his Terraform support and help with this article.