Understanding Terraform's Core Workflow

#devops #terraform #iac #cloudops

Terraform is a growing tool created by HashiCorp to deploy cloud resources using the same syntax, making it easier to apply what you already know to new cloud providers.

Enough about the reasons, let's get into how you can manage your cloud infrastructure using Terraform.

Terraform uses a three step core workflow:

init
plan
apply

Init

First of all, you'll need to write your Terraform configuration using valid cloud credentials, these can be your own or some service account with the necessary permissions.

With your configuration ready you'll have to initialize your Terraform module using terraform init, this will download any dependencies, such as providers and referenced modules, the init command also creates the terraform.lock.hcl file, an automatically generated dependency lock file simmilar to requirements.txt from Python.

The last thing done during the module's initialization is configuring the backend, this is where Terraform will store its state file, the state file or TFState is responsible for holding everything Terraform needs to know about your infrastructure to be able to manage it.

Plan

Planning your Terraform configuration works as a way of comparing three things, and it looks something like this diagram:

The items compared during a plan are:

Terraform Configuration

The configuration itself, what Terraform assumes is the desired state for the cloud resources you declared inside the module.

Terraform State

Everything mapped by Terraform from previous applies/updates, this is only used as a way of knowing what was done by Terraform and what was done by outside sources.

Cloud Provider

The cloud provider is the place where your actual infrastructure is running, by checking the provider's API, Terraform is able to tell the current status of things, any changes from what is registered in the state will make Terraform want to update things, always trying to match the desired state declared on your configuration.

Terraform always needs to perform this step to plan what changes need to be done to the running infrastructure so it matches the desired state declared in the configuration.

Using the -o or -output option on the CLI you're able to generate a plan file, this can be used when applying the planned changes to make sure only the planned/approved changes will take place.

Apply

The final command of what is known as Terraform's Core Workflow is apply, running this command starts the same way as running plan if a plan file is not provided.

After determining what changes should take place, Terraform will ask for the user's approval before applying any real changes/updates to the infrastructure, the -auto-approve flag eliminates the need for the manual approval, but it's not a recommended practice, since it may even delete running infrastructure.

At the bottom of the changes list, there's a summary telling the user how many of each operation will take place if the plan is actually approved and applied.

The kinds of operation are:

Add - New resources will be added to your infrastructure
Change - Existing resources will be changed in your infrastructure
Destroy - Existing resources will be deleted from your infrastructure

The summary will look something like this:

Plan: 2 to add, 5 to change, 4 to destroy.

In some cases destroying a resource might mean the resource is going to be replaced due to a breaking change. Terraform doesn't decide what is a breaking change, this is a responsability of the cloud provider and its API, since Terraform is not responsible for the resource's configuration and/or contents, it cannot guarantee if the replacements won't break dependencies and running applications.

When approved, the changes will start to be applied.

Conclusion

Applying changes using Terraform may have destructive impacts to your infrastructure, so do it carefully, but it's predictable and repeatable, making it one of the safest way to manage a cloud environment, if you don't think so, just think about the mistakes you could have done by forgetting a route table or a single NSG rule.