Hydra 1303

All News Items

Terraform: One Code To Rule Them All

from the Hydra High Council Jun 19th 2018

Code can be easily shared and re-used. Infrastructure, not so much. But what if there was a way to do just that? Enter Terraform. It's an open-source tool you can download for provisioning and creating 'versions' of your infrastructure, much like you have versions of code.

There are a LOT of options in any modern network and therefore, lots to manage from end-to-end, each platform having its own portal. This is where having an open-source Swiss army knife of automated goodness comes in handy. Terraform is constantly being updated with new modules published from hundreds of individuals worldwide. Chances are that something you're attempting to automate within your environment has probably already been solved by someone else. You download that module from Terraform's global repository, registry.terraform.io. Simply fill in the blanks with your specific inputs and Terraform executes it.

Individuals aren't the only contributors. Infrastructure providers such as AWS, Google, Azure, and VMware also publish modules into the repository. These modules contain ready made code from the official recommendations of say Google or AWS on how to provision their network. Modules also reduce complexity, obviating the need to be aware of every little detail for every platform.

Terraform primarily uses three commands: terraform refresh, terraform plan, and terraform apply.

Terraform refresh talks to the outside world. It queries infrastructure providers and finds out what is running in that environment. Much like if you were following a stock quote in real time and hit refresh on your browser, it goes out and gets the current information.

Terraform plan is where it figures out the delta between the way things are now and the way we desire it to be. As an analogy, say your New Year's resolution is to lose weight. You have a picture of what you looked like in high school and you have a mirror. The picture represents your goal and the mirror shows what you look like now. The command terraform plan defines what needs to be done to reconcile the two. The instructions to implement the plan are stored in an easy to read Terraform config file.

Some of the steps need to be done sequentially. Others can be done in parallel to save time. Terraform creates a graph of operations and figures out the optimal way to execute these actions when you use the terraform apply command.

In a nutshell, refresh just starting out discovers that nothing has yet been provisioned. Plan lists all the things that are going to be created and apply goes out and builds it.

But as you know, your infrastructure is never static. It is continually evolving. Let's say you add a component to the plan. It will go through the same three steps that you used to create your infrastructure in the first place: refresh, plan, apply. When you run them, they create a new version of your infrastructure.

Refresh reveals the current view of the infrastructure. Plan sees all the existing components, plus the one you want to add. When you run apply, it can see that no changes need to be made to the existing components. It only adds the difference, the delta. This is much like copying two similar directories of files and getting the option to not take action on the files that are identical.

Not only would you then have version 2.0 of your infrastructure, you also have a configuration that is essentially the recipe for everything you provisioned. This means that if you wanted to recreate your infrastructure for QA or for testing a new application, you could create a standalone replica of the infrastructure with minimal effort. And once you are finished with your development sandbox, another command, terraform destroy, can unwind the whole test environment in the proper order.