Understanding Terraform For Beginners

Defining infrastructure as code(IaC) is one of the easiest ways to manage the whole infrastructure and you’ll probably like it more if you are not a fan of using GUI to manage stuff. In this beginner’s guide to understanding terraform for cloud automation, let’s see what this buzzword really is all about

Terraform is a simple and easy-to-understand declarative language to define objects or resources and make changes as you want in that defined infra. It’s multi-platform, can be installed in Linux, Mac, and Windows too. Being Agentless like Ansible is also one of the other qualities of Terraform.

Terraform Lifecycle

The lifecycle consists of 4 stages which are Init, Plan, Apply and Destroy.  Just like some God is supposed to Initialize a life, plan its span, apply it or we can say send it to earth to live it and eventually finishes it.  So, hypothetically, you’ll feel like some Tech God once you control the infra with Terraform code.  😊

Anyways, moving ahead, let’s see what these stages are:

Terraform Init: It is the stage where your Terraform Code gets initialized. Once you have your Terraform code ready, must be stored in some of the directories on your pc, you need to execute this command in the terminal to initialize the directory.

Ideally, this means that you are telling Terraform to initialize the modules (explained later in this article), backend, and download relevant provider plugins according to what is defined in your terraform code.

For example, if you have defined the provider like AWS and Azure then Terraform init will download the relevant version of AWS and Azure provider and supported binaries to initialize the code. Practically, your code is ready to launch after this one.

Terraform Plan: It’s one of the most important commands because of the information that it provides to the user. Terraform plan commands give you the actual impact of the code you’ve written which ideally means that where your code is heading and what would be the end state after it has been executed.

Terraform Apply: This guy here is your code executioner. So, once you execute this command, Terraform will start interacting with all the magical APIs of the target infra and makes the changes as defined in the plan. This is also the stage when it’ll probably tell you if you have any kind of error in your code. 

Terraform Destroy: Here comes the “Angel of Death”. This is your one-stop shop to destroy stuff. This command is used to delete or replace all the old or “not needed” resources of the infrastructure. Upon execution, it’ll provide you a view of the resources it is going to destroy. Once approved, it’ll start working towards its ultimate goal which is to delete terraform-defined infra.

Now let’s move towards the components of Terraform. It mainly has two of it:

1. Terraform Core: Consists of Terraform Configuration and the TF state.
2. Providers

Terraform Configuration

It is made of some core concepts which come together to provide you the big/desired picture of the managed infrastructure.  

• Resources:  This block defines the resource you will create or make changes to. For example an AWS EC2 instance as show in the below snippet.

• Variables: As the name suggests, variables gives you the flexibility to change the values without hindering the actual source code. For example defining a variable for the “Instance_type” in AWS EC2 instance resource as shown below.

I can change the value of the variable to c4.large or any other type without touching the source code.  When you have a large infrastructure to manage, you of course would have a large set of variables to define, for which you can use a variable definition file. Generally, this file can be called on the command line using the syntax -var-file and it has the extension as .tfvars or .tfvars.JSON.  See the below snippet:

• Data Source:

The data source is used when you want to incorporate some information that is presented by a party outside of Terraform and you want to use it in your Terraform code as an input to some variable. The most common example you’ll find for the data sources is pulling out the info regarding the AMI you’re going to use to spin up your AWS instance.

• Output Values/Outputs:

In simple terms, this block of code will represent the values you want to get as an output from your resources. For example, After the execution of terraform apply to deploy VPC, you want to know the VPC ID and the CIDR block that is assigned to it, you may define an Output block to print that on screen as shown below.

However, there are more important uses of output value block once you start using modules. You can use the output of one module as an input to another module of code. Here is the link for more details.

• Modules

A terraform module defines the concept of reusability of the code. Consider defining a set of resources in terraform code that deploys Several AWS VPCs, Security Groups, EC2 instances, and load balancers for one of your customers. How convenient this would be if you can re-use all that code for another cloud project by just changing the variable values.  So, this is what modules are, you package your code and use it as many times as you want. Saves time and effort!!

Moreover, there are several public modules that you can leverage for your Terraform projects. Visit this link to check.

• The TF State

The TF state is one of the most important .tf file for your Terraform projects. This file has all the information regarding the state of the terraform-managed infrastructure. You can think of it as a Recorder that records the state of the managed resources and helps define the target state of the infrastructure after the changes or more like a God’s Scribe 😊.

 Whenever you execute any Terraform operation, The TF state talks to APIs of the existing infrastructure and determines the current state of the infra. state file in the working directory, if there is none, then It’ll create one once the changes you defined in the code have been applied. Otherwise, it’ll refresh the TF state file as per the current state of the infrastructure.

Providers:

In layman terms “Providers” refers to the platforms/infrastructure that you can manage through Terraform. For example, AWS, Azure, GCP, VMWARE, ACI, Oracle Cloud, etc. If we go for its technical definition, then we can say that the providers define and exhibit the relevant APIs.

Basically, providers are written in Go Language as Terraform is. The code defines how a provider should interact with the APIs to do what has been told to do by the user, which means YOU. The codebase for providers is maintained by HashiCorp Teams.  I believe each provider has its own team in HashiCorp which maintains the code and you can find the code for all the verified providers here.