Infrastructure as Code: Terraform

In my last post, we discussed the concept of infrastructure as code and how it relates to Terraform and Ansible. Lets dig a bit deeper into the power (and limitations) of Terraform.

What is Terraform?

Terraform is a syntax language for writing infrastructure as code. While things like AWS Cloud Formation provides the same functionality, Terraform is platform agnostic and can define infrastructure for platforms such as Azure, Oracle Cloud, and Active Directory (see https://registry.terraform.io/browse/providers for a full list). For this reason we chose Terraform as our primary language at Mosaic Learning.

Every Terraform provider provides a list of resource types which can be defined and managed through code. There are two main constructs in Terraform:

• resource objects
• data objects

Resource objects defines a tracked and managed resource, such as an aws_instance(AWS EC2 Instance). Once defined, Terraform can spin up and spin down the instance as many times as necessary, and even spin up a secondary instance in a new workspace. Data objects, on the other hand, are not managed by Terraform in the same way. Rather, they only reference an existing resource and utilize it in a read only fashion.

Lets see an example taken from https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance

We see an example here of both resource objects and data objects. The code above defines an aws_instance resource object named webwith an instance type of t3.microand a tag with a key value pair. Every resource object has a list of required and optional fields. In this example, the optional field amidefines which AMI the instance will will be generated from. The AMI itself, however, is NOT being managed by Terraform and rather existed previously. We use the data object to search for it using filter syntax, and then reference it in the resource viadata.aws_ami.ubuntu.id.

Limitations

Terraform is great and powerful, but there are times when you might not want to use it. Imagine you have created a RDS server or S3 bucket in terraform. As we described above, terraform can create these with ease… and destroy them as well. What would happen if one of these were accidentally destroyed?…

Pets vs Cattle

With this we can introduce the concept of Pets vs Cattle. The goal of any Infrastructure as Code provisioning tool is that the infrastructure is as dispensable as cattle, not fondled like a pet. Terraform makes sense for things like EC2 instances, load balancers and security groups. This genre of resources is essentially configuration at its core as it does not represent user data or assets at all. However, S3 buckets and RDS servers represent data that is unique and irretrievable if lost. These should be maintained in the regular ‘manual’ way external to Terraform.

Conclusion

Terraform is amazing tool in your toolbox to assist in server automation. Just make sure to use it wisely!