Introducing Terraform: Part 1

Introduction

Terraform is a tool from Hashicorp, the same startup responsible for Vagrant and Consul, that enables users to “declaratively design” infrastructure and have those designs materialize into working components. This series will cover what exactly that means, why Terraform is so interesting, and how to use it.

Declarative Configuration

Declarative Configuration is a way of describing the state of a system without having to show the underlying code that would perform the task. For example, Puppet, a popular Configuration Management System, allows a file to be created on a system by declaring the following: 

file { '/tmp/myfile.txt':
  owner => 'root',
  group => 'root',
  mode => '0640',
  content => "Hello, World!",
}

And this is how you would do the same thing programmatically using Ruby, the programming language that Puppet is based on:

require 'fileutils'
f = File.open('/tmp/myfile.txt', 'w')
f.puts "Hello, World!"
f.close
File.chmod(0640, '/tmp/myfile.txt')
FileUtils.chown('root', 'root', '/tmp/myfile.txt')

The result of the two examples is the same: a file called “/tmp/myfile.txt” with the content, “Hello, World!”, owned by user “root” and group “root”, with file permissions of “0640”. But there are some benefits to the first, declarative example.

The first benefit is that all of the programming logic is hidden away; it looks more like a statement rather than a block of code. This allows the user to not be concerned about how the file is created, just that it will be created.

The second benefit is that the declarative statement can implement a lot of complementary logic behind the scenes. For example, if you believe the user should know whether “/tmp/myfile.txt” already existed with different contents, the declarative statement can report that. Compare this to programmatic blocks of code, where reporting prior existence must be explicitly written out.

There’s an interesting catch to all of this though: the declarative statement is actually the result of a bunch of programmatic code. You can see the code for Puppet’s “file” statement here.

This kind of relationship is known as a Domain-Specific Language (DSL). Keeping Puppet in mind, the advantages and disadvantages of using a DSL for Configuration Management are best describe by Luke Kanies, the creator of Puppet, here.

Declarative Infrastructure

It should now make a little more sense when I describe Terraform as declarative.

Except, Terraform isn’t interested in declaring the files, users, packages, or any of the other components that make up a fully functional system. Rather, it works a level above that: declaring entire systems, networks, storage devices, and other pieces of infrastructure.

Terraform isn’t the first tool to do this. OpenStack’s Heat and Amazon’s CloudFormation are two existing tools, but there’s one big difference between them: where Heat and CloudFormation are services provided by a cloud provider (and thus restricted to the cloud provider), Terraform is a client-side tool. This is a big deal.

Imagine you have access to an OpenStack cloud and an Amazon AWS account, and you want to manage your virtual infrastructure in both. Without Terraform, you would have to use two separate tools: Heat and CloudFormation. The only other alternative would be for the party responsible for the OpenStack cloud to call Amazon, work out a deal to allow your OpenStack account to somehow be linked to your AWS account, and then implement the actual code to make this happen.

The same situation applies for every combination of services that Terraform supports. Using Terraform, someone can create and mesh virtual infrastructure from OpenStack, CloudStack, Heroku, DigitalOcean, AWS, and more.

The way Terraform enables this is similar to how Puppet enables the creation of files: it implements a declarative language that abstracts the complex programmatic logic required to build out the virtual infrastructure in each cloud service

Conclusion

This post gave a high-level overview of what Terraform is, how it works, and how it’s different from similar tools. The next post will demonstrate how to use Terraform to build out actual cloud resources using Cybera’s Rapid Access Cloud.

Leave a Comment

Your email address will not be published. Required fields are marked *