At Hedvig, we frequently use clusters across multiple clouds (Amazon, Google, Azure) and need a quick and easy way to spin up these clouds on demand. We’ve started testing Terraform to deploy clusters at Hedvig and have found it to be a very clean and productive tool. The main attraction of Terraform is a simplified API for multiple providers.
We’ve tried a number of different setups with Terraform, and have had tremendous success. For example, some of the setups we tried include: building with different AMIs, instance types, counts, subnets, and other variations. We also tried building a new AMI from an instance, as well as attaching Amazon EBS volumes to instances. These were all easy with Terraform, requiring only a few simple lines of code.
Terraform gets its power from the use of “resources,” which are clearly defined units that largely correspond to objects in a datacenter, such as resources or EBS volumes. Most of the work in Terraform is simply a matter of defining the proper resources and then defining their relationships. To start out, you must first define your provider, such as AWS, so Terraform knows where to do the tasks you require. Following, you’ll add some keys and maybe a few properties, like your region. Aside from defining the provider and standalone variables, everything will be packaged within resources.
One of the properties we used frequently was the “count” property. It is as straightforward as its name suggests. It simply means that it will duplicate any resource it is attached to that many times.By combining this with a little bit of magic called a “null_resource” and a variable, we were able to dynamically create from the command line as many, or as few, of certain objects desired.
The variable "trio” could then be manipulated from the command line using this syntax: “terraform apply -var ‘trio=3’”. This was the most complicated code we had to implement in order to tackle any of the initial problems we wanted to solve with Terraform. Everything else was handled with a resource, or with two or three resources tied together by ids. For example, bringing up an instance and trying to attach an EBS volume to it involved three resources: an aws_ebs_volume, an aws_instance, and an aws_volume_attachment, which used a volume_id and an instance_id to define the relationship between the other two. This volume attachment functioned a little like a mount point, even taking a “device_name” such as “/dev/sdc.”
That sums up our initial investigation into Terraform. We hope you’ve found something here to help you make a decision about whether to move forward with Terraform. At Hedvig, we've certainly found it to be a simple yet powerful tool.
Want to learn more around Hedvig’s integration with Terraform? Click below to see how you can apply Hedvig software-defined storage with Terraform to any cloud.