IaC has been a standard of infrastructure management for quite some time. Yet, it may not give you all the benefits if you don’t follow at least the most common best practices. Want to know what they are? We are pleased to share some knowledge regarding IaC and, more specifically, the Terraform tool we have been using for numerous projects. And it doesn’t even matter if you are a DevOps, cloud engineer, or developer - IaC is merely for everyone. Let’s dive in!

Code your cloud infrastructure.

First things first, try to embrace Terraform code as much as possible. What does it mean? It means you should fight the temptation to change your cloud infrastructure manually, even if it is a minor change that is achievable quicker if you use UI. And there are plenty of reasons for that! We all know what benefits coded infrastructure gives us - the code we get is both a configuration entry point and neat documentation, but it requires some discipline. So don’t be lazy and update a few lines of code.

Think twice before 'terraform apply'

Great, you did it, but please - don’t rush running the beloved terraform apply command. Although cloud computing has committed to ease of use and flexibility, and tools such as Terraform extended it further, you should be careful - it's not always easy to roll back without breaking something. Always double-check the changes you are applying. Even better - implement some innovative CI/CD pipeline for your IaC repository.

Simplifying environment management with Terraform

It's pretty straightforward, but this considerable topic bothers even professionals - environment management. It’s not that difficult if you use some extra tooling such as Terragrunt wrapper, which lets you use the same Terraform modules in different combinations and different configs for different environments (it simply cuts your state file into pieces and plugs outputs of one module to inputs of another if needed). But what if you don’t want to or cannot add extra tooling? No worries, Terraform provides some native workarounds that can be used along with extra bash magic.

The most obvious thing to do when managing multiple environments is to use workspaces. They allow you to use different state files for the same configuration without code duplication. Okay, that sounds great, but what if only part of our infrastructure is environment-dependent? Let’s say we have an EKS cluster; thus, environments are separated using Kubernetes tooling, but we also have some RDS databases, one per environment. It's obvious that RDS (and probably some extra resources such as IAM Roles) should be managed with Terraform, but at the same time, the EKS cluster should be one for every environment we have. What should we do then?

Terraform's efficiency: practical tips and tricks

We can implement Terragrunt functionality. Let’s define EKS and all the underlying resources, such as VPC, as a separate module with its own state file. Now you can apply it, but before defining all the outputs - you can retrieve them with a terraform output command later. See where it’s going? Define a new module that needs environment separation. Now, you can get outputs from the EKS module, write them to the terraform.tfvars file, and plug them into the RDS module. RDS environments can be handled with the workspaces we mentioned earlier. That’s just a few of the Terraform best practices (or, in some ways, tips and tricks) you can use for your project.

Stay tuned to learn more!