Terraform Best Practices

Whenever Terraform is first to run against any account based on cloud infrastructure, it creates an intermediate consistent data store. This data store maintains the cloud infrastructure state representation by invoking Terraform tools.

Generally, accounts based on cloud infrastructure aren’t capable of maintaining exact changes made to it; this is where Terraform comes in. The Terraform state allows users to track changes in the resources and determine which changes are needed so that the cloud infrastructure matches the Terraform code.

You can choose from a wide range of services to store your Terraform state. These include but aren’t limited to a shared file system, local file system, relational database, and shared object-store location. It doesn’t matter how many infrastructure code developers you might have; you should always use one shared backend location as best practice.

To ensure that only a single infrastructure provisioning operation is underway at a given time, you must always leverage a locking mechanism. You can choose from one of the many options of locking mechanisms available to you.

Maintaining the Terraform states from one shared location lets you make your infrastructure more secure. You can impose authorization and restrictions to control who and how your infrastructure is updated.

You can structure your infrastructure code however you want without any interruptions from Terraform. You can implement small atomic components that can be individually tracked or provisioned. Moreover, the system allows you to implement a megalithic structure where all the cloud resources are described, even across different environments.

You can choose from any of the two extremes. However, the best practice would be to group relevant resources by application or environment in this case. Moreover, you should always create a separate state location in Terraform for every group you create.

Of course, this also implies that you’ll have to deal with numerous state locations; however, the logical separation of applications from environments will significantly boost Terraform’s performance. Moreover, it also helps in preventing conflicts.

Coding frameworks in Terraform code can be written well or poorly. In the case of poorly written code, the infrastructure will become tough to maintain due to bugs and a slow pace. However, the infrastructure can be broken down into modules with Terraform to enable a good design. The modules are atomic infrastructure components with well-defined outputs and inputs.

These modules can create infrastructure representation that can be reused or maintained. It is only possible because the modules create reusable components that match your application’s implementation.

Let’s look at an example. Suppose you have an application with an RDS instance, S3 bucket, and EC2 instance. The correct choice of action would be to create a separate module for each, i.e., RD instance, S3 bucket, and EC2 instance. The next step would be to create one more module that controls all previously created modules. This module will represent the application and be used as a reference in the actual environment logic provisions.

The use of multi-level representation allows the reuse of standard resource modules. They can be used for fully-composed and other application modules across several environments.

You must separate the logic into different modules. Moreover, you should maintain a different state for each application and environment. However, that’s not all. You should also break the Terraform provisioning and module code into different locations.

As a rule of thumb, modules are maintained in their specific Git repository. Any environment that needs provision needs to have a separate Git repository maintained. As a result, you can collaborate and reuse the modules and ensures that the module library is segregated from the environment-centric code.