The Ops Community ⚙️

Cover image for Understanding Terraform's Core Workflow

Understanding Terraform's Core Workflow

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:

  1. init
  2. plan
  3. 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.

Terraform Init - Execution

Plan

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

Terraform Plan - 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.

Terraform Plan - Execution

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:

  1. Add - New resources will be added to your infrastructure
  2. Change - Existing resources will be changed in your infrastructure
  3. 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.
Enter fullscreen mode Exit fullscreen mode

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.

Sources and References

Official Docs

Top comments (3)

Collapse
 
diek profile image
Diek

Great first approach to tf :)

Collapse
 
oleonardorodrigues profile image
Leonardo Rodrigues de Oliveira Author

Thanks!

I'm going to post more content, each time a little more complex and/or specific, if you're interested.

Collapse
 
diek profile image
Diek

Yes, i am :) keep the good work, thank you.