What is Terraform?

Introduction

Terraform works by checking the desired state of infrastructure against the current, and then ensuring the desired state matches the actual state. Terraform grants us the opportunity to preview the execution plan of our Terraform configuration file before actually provisioning the resources.

The basic workflow to create infrastructure using Terraform is outlined below:

  1. Declare the desired infrastructure state using the HCL.

  2. Run the terraform plan command to see the execution plan.

  3. Run the terraform apply command to apply the execution plan if it’s satisfactory.

Press + to interact
Provisioning resources using Terraform
Provisioning resources using Terraform

Core components of Terraform

We’ve explored the basics of Terraform and how effective it is for managing our infrastructure in an automated version. Next, let’s talk about what makes up Terraform itself.

The major parts of what we refer to as Terraform are:

  1. Terraform Core
  2. Terraform Plugins

Terraform Core is written in Go and it forms the major part of the Terraform CLI (command-line interface) tool. Terraform Core communicates with Terraform Plugins using remote procedure calls (RPC).

Terraform Plugins are basically used to define services. We can use plugins to initialize the libraries for making API calls or for authenticating to different cloud providers. The most common type of plugin is the provider plugin.

With the combination of Terraform Core and Terraform Plugins, we’re able to interact with our infrastructure on different cloud providers and in turn manage the state, manage configuration files, and manage the execution of our infrastructure.

Press + to interact
Communication between Terraform Core and Terraform Plugins
Communication between Terraform Core and Terraform Plugins

Major terminologies

Previously, we had to provision an instance on AWS. We basically needed to write a configuration file that performed a couple of steps to help provision the required instance. Our Terraform file looked exactly like the one below:

Press + to interact
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}
required_version = ">= 1.2.0"
}
provider "aws" {
access_key="{{AWS_ACCESS_KEY_ID}}"
secret_key="{{AWS_SECRET_ACCESS_KEY}}"
region = "{{AWS_DEFAULT_REGION}}"
}
resource "aws_instance" "my_instance" {
ami = "ami-0a606d8395a538502"
instance_type = "t2.micro"
tags = {
Name = "SampleInstance"
}
}

The Terraform file above shows three major blocks of code, namely terraform, provider, and resources. The terraform block starts at line 1 and ends at line 10, the provider block starts at line 12 and ends at line 16, and the resources block starts at line 18 and ends at line 25.

We’ll explore what these blocks mean and other major terraform terminologies.

The terraform block

This is where we configure all the major Terraform settings, like the provider we’re using, the provider’s version, and the version of Terraform to use. Please note that a provider represents the different ways that Terraform is able to interact with various cloud providers’ APIs. These providers include AWS, GCP, Kubernetes, and so on.

Terraform provider

This is where we authenticate against the specified provider. In our case, we’ve chosen AWS and will need to provide the access key, secret key, as well as the region to authenticate.

Terraform resources

This block allows us to provision our resources as required. We can use a declarative tone to specify the infrastructure we want to provision and then Terraform will do the work for us. The example above shows that we asked Terraform to provision an EC2 instance for us. We only had to mention the AMI ID we wanted to use, the instance type, and then the tag to attach to the instance.

Terraform state

The Terraform state refers to the current state of our infrastructure setup. Terraform stores the current/existing configuration in what’s referred to as the Terraform state file. The Terraform state file ends with the extension .tfstate. Anytime we modify our Terraform configuration files and run a terraform plan, Terraform checks the state file in order to compare the actual state of infrastructure to the desired state, and then makes the changes accordingly when we run a terraform apply command.

Terraform backend

The Terraform backend allows us to store our state file and perform Terraform operations. We have standard backends that only allow us to store the state file, as well as enhanced backends that allow the storage of the state file and other terraform operations.

Terraform workspace

Terraform workspace helps us to maintain different infrastructure configurations for different environments e.g., staging and production. By default, Terraform maintains a single workspace known as default. Using workspaces allows us to create individual state files per workspace.

As the infrastructure grows bigger, we’ll continue to have more Terraform files and more blocks to work with, but it’s important to understand the rudiments above.