What is Terraform Architecture and Best Practices?

As the number of cloud computing environments and servers increases, the management process for those resources becomes more complex. Infrastructure-as-Code (IaC) is one of the best ways to scale an organization’s IT infrastructure. Every DevOps professional must be aware of IaC, which is a widespread practice in the industry where the entire IT infrastructure can be managed and provisioned through machine-readable definition files. There are several IaC tools in the industry, and Terraform is one of the most widely used tools. In this article, you will learn about Terraform features, Terraform architecture, and Terraform best practices that will provide you with the desired outcome.

What is Terraform?

Developed by HashiCorp, Terraform is an open-source Infrastructure-as-Code tool used by legions of DevOps teams to automate infrastructure tasks. This tool allows DevOps teams to deploy a single workflow for their multi-cloud setup. It supports all the leading public and private clouds, including Microsoft Azure, Amazon Web Services, and Google Cloud Platform.

Terraform can be used to define the entire IT infrastructure in code form. One of the best things about this tool is that it allows the users to build and manage multiple clouds from different providers simultaneously. Furthermore, it allows IaC in HashiCorp Configuration Language (HCL), a human-readable language, simplifying the process.

Why Use Terraform?

As mentioned earlier, Terraform is used by several DevOps teams in the industry. But why is it so popular? Here are the reasons that make this IaC tool so desirable.

#1: Automate Changes:

With Terraform, the need to write instructions step-by-step for creating resources is eradicated as it can manage the essential logic. Moreover, the configuration files in Terraform are declarative, which defines the end state of the infrastructure. All these factors allow Terraform users to automate changes.

#2: Infrastructure Management:

Undeniably, Terraform or any other IaC tool can help you manage a provider’s IT infrastructure. However, Terraform can work with not just a single provider but multiple cloud providers simultaneously. With this tool, you can write your custom registry and manage the platform and services you use.

#3: Configuration Standardization:

Terraform supports modules which are reusable configuration components that describe the configurable collections of your infrastructure. Not only do they promote the correct practices, but they save crucial time as well. Another excellent thing about this tool is that you can customize these modules or even use publicly available ones.

#4: Infrastructure Tracking:

With this tool, you can create a plan and always seek permission before making any infrastructure alteration. Furthermore, it monitors the infrastructure in a state file. By using this file, this tool can identify the necessary modifications to make in the existing infrastructure to meet the set configurations.

Architecture of Terraform:

Terraform follows a standard architecture to fulfill the necessary IaC tasks. It includes two different components; Terraform Core and Providers. The below section will elaborate on these two components of Terraform and how they perform the desired tasks.

Terraform Core: When it comes to managing dependencies, Terraform relies heavily on graph theory. The Terraform core is responsible for reading configurations and building the dependency graph.
- Working of Terraform Core:-Terraform uses two different input sources for accomplishing its tasks. The primary input source is the input the user gives for configuring Terraform and describing the resources that should be created or provisioned. On the other hand, all the data provided to Terraform regarding the existing infrastructure setup is the second input that this component of Terraform’s architecture uses.
  
  After taking these inputs, this tool decides the actions that should be taken for the infrastructure. In addition, it analyzes the user-specified desired state, performs a quick comparison with the existing state, and sets up the architecture that eradicates the gaps in the infrastructure. In simpler terms, the Terraform Core identifies the things that should be created, modified, or deleted to make the most out of your existing infrastructure.
Providers: Providers are the second component of the Terraform architecture and are referred to as external individual static binaries. The Terraform core communicates with the plugins through Remote Procedure Call (RPC) when the applying and planning phases are going on. These plugins are written in the Go language. In the Terraform configuration file, every provisioner and provider is a plugin.
- Working of Providers :Providers in Terraform are cloud providers like Microsoft Azure or Amazon Web Services. However, they can also be any other platform as a service tool. There are several different providers for different technologies, and they all provide access to the users to the resources. For example, if a user uses AWS, Terraform will gain access to all the EC2 instances within the stack. Afterwards, the user can build infrastructure on several various levels.

This was the entire architecture of Terraform, including the two components; Core and Providers. Though it is not a highly complex architecture, it can help complete the infrastructure setup quickly and just through code.

Terraform Workflow:

There are three different stages in the Terraform Workflow: Write, Review, and Apply. These states are briefly explained below.

Stage#1: Write– The foremost step in the Terraform workflow includes defining the infrastructure resources as code through HCL. These resources can be across different cloud services and providers.
Stage #2: Review-Terraform will begin displaying the plan to add or remove resources in the next stage. Furthermore, the plan will define the infrastructure created, modified, or destroyed depending on the current configuration and infrastructure.
Stage #3: Apply-The final stage in the Terraform workflow is Apply, where you can determine the planned changes for adding or removing any infrastructure resource. Once approved, the terraform will perform the desired actions in the defined execution order.

Terraform Best Practices:

Terraform can be used with multiple cloud providers, and knowing about the best practices while using this tool can provide an excellent outcome. With that in mind, this section will elaborate on the best practices to implement while using Terraform with different service providers, including Microsoft Azure, Amazon Web Services, and Google Cloud Platform.

#1:Terraform Best Practices for Microsoft Azure–

Most Terraform users will agree that YAML tasks look simpler and uncomplicated initially. However, the more you use them, or with time, they become another abstraction layer that will require manual debugging. By using the YAML tasks, you may end up not mastering the tool but only the particular action. On the other hand, using the Terraform command line will help you understand all about this tool and allow you to master it when using it with Azure.

Use YAML Pipelines rather than UI– The Azure DevOps service carries legacy features like Classic pipelines. When you intend to create new pipelines, it is best not to begin with classic pipelines. Rather than that, it is best to use Pipelines as Code which ultimately means YAML pipelines. However, if you already have classic pipelines, you need to start migrating them to YAML. Though both will get the job done, Microsoft is focused more on YAML pipelines, and using YAML pipelines will ensure that you remain future-proof and on the right track.
Using Terraform Partial Configuration– Initially, the documentation in Terraform will seem easy to read and include different aspects like storage account name, resource group name, container name, and access key. However, in this practice, the data specific to you may be stored somewhere else. With that in mind, it is always advised not to use the default configuration of Terraform but a partial configuration.
The partial configuration is when the user does not need to specify every argument in the backend configuration. In case certain arguments are provided automatically through a running automation script in the Terraform, they can be omitted. Eradicating some or all the arguments is considered partial configuration.
Custom Role for Terraform-Granting more than necessary access to any role can be a security concern. To diminish the risk, providing only the necessary access to a particular role is always advised. Many remain confused about whether the service principal used by Terraform should have an owner or contributor role. The answer is that none of these roles should be given to it. Instead, creating a custom role for the Terraform service principal should be assigned.

#2: Terraform Best Practices for Amazon Web Services–

Amazon Web Services is another widely used cloud service currently. Here are some of the best Terraform practices you should adopt with AWS.

Split Files Logically: In Terraform, the main file that has the provider and creates the resources is the Main.tf. Having a single file can enhance the complexity of readability. Even though the Terraform code can be written in a single file, one of the Terraform best practices in AWS is to split the files logically. These files are:
- Main.tf – locals, call modules, and data sources to create the resources
- Variables.tf – This file contains the details of the variables used in the main.tf file.
- Outputs.tf – Every output generated in the main.tf from the resources are found in this file.
  As mentioned earlier, having a single file may reduce the file’s readability, which is why the best practice is to split the files into these formats for better readability.
Locking the State File: One of the most typical reasons for data loss, conflicts, and state file corruption is having multiple runs on the same state file. When working on a project, you cannot risk data loss. Terraform has a locking feature that can lock the state file and avoid any parallel run of the same state. Only a single member can run the Terraform configurations when a state file is locked, preventing the above mentioned scenarios.
Metadata Extraction: The only data source that extracts data from the Terraform backend is terraform_remote_state. With this source, you can use the root-level output of Terraform configurations as input data for other configurations. Network, application, and database are some of the layers the user needs to manage. Upon creating the basic network resources, the application and the database layer should directly refer to the resource from the vpc layer through the terraform_remote_state data source.
Tag your Amazon Resources: Terraform allows the user to assign custom metadata to every resource as tags. By tagging your AWS resources, you can categorize them in any way you want. Tagging is extremely useful when there are multiple resources of the same type, allowing you to find the desired resource per the assigned tag.

#3:Terraform Best Practices for Google Cloud Platform–

The Google Cloud Platform or GCP is another market leader in providing cloud services. The following section elaborates on some of the best practices that can be followed while using Terraform with GCP.

Variable Usage: The Google Cloud Platform, or GCP, is another market leader in cloud services. The following section elaborates on some of the best practices that can be followed while using Terraform with GCP. The first in this list is taking the proper steps while using variables. Every variable in GCP should be declared in variables.tf. As GCP API does not have any standard unit, it is essential to name variables with units. For instance, local variables, inputs, and outputs depicting numeric values should be named with units like disk_size_gb. Apart from that, binary unit prefixes should be used for storage units so that it matches with that of the Google Cloud.
Limit Custom Script Usage: It is always advised to use scripts only when required and not always. The reason is that Terraform does not manage the state of resources created through scripts. Custom scripts should be avoided unless the Terraform resources do not support the required behavior. Moreover, every custom script should have a documented reason for existence and a deprecation plan. Every custom script called by Terraform should be put in the scripts/ directory.
Limiting the Complexity of Expressions: The complexity of individual interpolated expressions should be limited. If multiple functions are required in a single expression, the best Terraform best practice for GCP is to split it into several expressions through local values. Also, avoiding multiple ternary operations in a single line is best. However, you can use multiple local values to build up the logic.
Follow a Standard Module Structure: Every Terraform module should follow the standard module structure, and the module should begin with main.tf as the resources are located here by default. Furthermore, each module should have a readme.md file in Markdown format, and it should have the essential documentation about the module. The root directory of the module should include only Terraform and metadata files.

FAQ(Terraform)

What is better than Terraform?

Even though Terraform is a renowned cloud infrastructure automation tool, it may not be suitable for every user. For such users, the better alternatives to Terraform can be Ansible, Pulumi, and Cloud Foundry.

What are the building blocks of Terraform?

Terraform Modules are also considered the building blocks of Terraform as they can help in abstracting common configuration blocks into reusable infrastructure elements. Modules reside outside of the root config folder. They also have input and output variables which help in abstraction. Having modules will solve duplication, versioning, and many other problems which can occur without these building blocks.

How do you store Terraform codes?

The codes in Terraform can be stored in a single file with a .tf extension. Though it can be stored in a single file, it is always advised to segregate them for better management and navigation.

What is Terraform File Structure?

Terraform file structure can vary with the project as well as the users. However, a basic structure for any Terraform code is mentioned below:

Variables.tf for defining variables needed by provider resource parameters.
Providers.tf to define providers and their versions.
Examples.tfvars showcases the input values for the variables.
Outputs.tf defines the Terraform output variables.
Locals.tf for local interpolation and variables.
Main.tf will describe the provider resources.

October 6, 2022 ThinkSys DevOps, Cloud

Previous Next

Blogs