Unlocking the Cloud with Infrastructure as Code (IaC): An Introduction to Terraform

We all know about the inherent challenges of traditional, manual infrastructure management, where human error and inconsistent configurations can lead to significant problems and security risks. The transition to Infrastructure as Code (IaC) represents a fundamental shift in a professional's mindset, moving from manual, procedural approach to a more auditable, reproducible, and scalable one. In this series of blogs, we will be discussing about Terraform and understand the basic concepts before writing some code to deploy resources into cloud environments. Hopefully at the end of it, you would have some knowledge and experiences in provisioning resources with automation using Terraform. Let's dive right in!!

Figure 1.1 Terraform is a declarative IaC tool that can provision, update, and delete resources from cloud providers and other services

Terraform is Hashicorp's "IaC tool that lets you build, change and version cloud and on-prem resources safely and efficiently." It uses a declarative approach, allowing a user to define the desired state of their infrastructure in human-readable configuration files that he/she can version, reuse and share with their team. Terraform uses Hashicorp Configuration Language (HCL) which is a declarative language meaning you describe the desired state of your infrastructure (e.g "I want a web server and a database"), and Terraform figures out the steps needed to achieve that state. This is different from imperative languages where you'd write a script that explicitly lists the steps to take.

How Terraform works?

Terraform provisions and manages resources on cloud platforms and other services through their application programming interfaces (API). Terraform uses plugins called providers to interact with cloud platforms and services with an accessible API. All publicly available providers for Terraform can be found on the Terraform Registry with each provider having it's own documentation for reference.

There are three stages to the core Terraform workflow:

Write:

You define resources using HCL as in authoring the code for the configuration files e.g create a configuration to deploy an application on virtual machines in a Virtual Private Cloud (VPC) with security groups, auto scaling groups and a load balancer.

Plan:

Terraform creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configurations.

Apply:

Once you/reviewer is happy with the execution plan, changes are approved and Terraform provisions the resources, updates or destroys them in the correct order respecting any resource dependencies.

How Terraform tracks your infrastructure

Terraform keeps track of your real infrastructure in a state file which acts as a source of truth for your environment. It is used by Terraform to map real world resources to your configurations, keep track of metadata, and also to improve performance for large infrastructures.

By default, the state file is stored as Javascript Object Notation (JSON) format in a local file named "terraform.tfstate", but it is recommended to store the state files in a remote backend. With remote state, Terraform writes state data to a remote data store, which can then be shared between all members of a team. Terraform supports various remote backends from HCP Terraform, Hashicorp Consul to Amazon S3, Azure Blob Storage, Google Cloud Storage, and many more.

If supported by your remote backend, Terraform also use state locking to prevent others in the team from overwriting your state. Sate locking is an optional precautionary step a team can take to prevent concurrent runs of Terraform against the same state. The lock files is always named ".terraform.lock.hcl" to signify that it is a lock file for various items that Terraform caches in the .terraform subdirectory of your working directory. Each time the terraform init command is run, Terraform automatically creates or updates the dependency lock file.

Sensitive Data

Terraform state can contain sensitive data like resources IDs, all resource attributes, and even databases initial passwords. When using local state, the state is stored in plain-text JSON files. when using remote backends, data maybe encrypted in the backend and is only held in memory when used by Terraform.

Ephemeral Data

Since Terraform v1.10, Terraform allows users to mark variables, outputs and resources as ephemeral. This means that the data of a block is available during runtime, but Terraform does not write that data to state or plan files. This is useful when managing credentials, tokens, or other temporary resources that you do not want to store in the state file.

Recommendations

Here are some recommendations:

1. Treat the state file as sensitive data if you manage secret credentials, or private keys with Terraform.

2. Mark sensitive data in variables as ephemeral to prevent Terraform from writing them to state and plan files.

3. Storing state remotely can provide better security as Terraform does not persist state to the local disk when remote state is in use, and some remote backends can encrypt state date at rest e.g Amazon S3 supports encryption at rest when the `encrypt` option is enabled.

Summary

That brings us to the end of a brief overview of Terraform as an Infrastructure as Code tool, including how it works and tracks infrastructure. We also looked at state files, how to treat sensitive data, and how remote backends work. In the next series of blogs on Terraform, there will be hands-on to get our hands dirty in learning and understanding more about how Terraform works. Until then, cheerio and enjoy life. Let me know of any feedback!!