Terraform States

Terraform must store the state of your managed infrastructure and configuration.

Terraform uses this state to map real-world resources to your configuration, track information, and boost efficiency for huge infrastructures.

This state is stored by default in a local file named “terraform.tfstate”.

Terraform State

Terraform uses the state to decide which infrastructure changes to make.

Terraform does a refresh before any operation to update the state with the actual infrastructure.

Benefits of States

1. Mapping

2. Metadata

3. Performance

4. Synchronize

Terraform State File

Terraform creates a state file called “terraform.tfstate”.

This State File contains full details of resources in our terraform code.

When you modify something on your code and apply it on cloud, terraform will look into the state file, and compare the changes made in the code from that state file and the changes to the infrastructure based on the state file.

State File

Terraform Backend

Terraform Backend is a configuration option in Terraform that allows you to store and manage the state of your infrastructure in a remote or local location.

The backend is responsible for storing the state file and providing an interface for reading and writing state data.

There are two types of Terraform backends: local and remote.

Backend

Terraform State File Types

Desired State — the state we wish for our resources to be in, this is represented by our Terraform code.

Existent State — the state our resources are according to where they are deployed; in the case of Azure, it would be the state of the resources in the cloud (visible via the Portal/API).

Observed State — the state that Terraform has observed or augmented the resources to be in at its last run; this representation is held inside state files within our backend.

States

1. Local Backend

A local backend stores the state file on the machine where Terraform is running.

This is the default backend that is used if you don’t specify a backend in your Terraform configuration.

The local backend is useful for testing and development environments, but it’s not recommended for production environments since it can lead to inconsistencies if the state file is lost or corrupted.

terraform {
  backend "local" {
    workspace_dir = "/Users/brendanthompson/Development/terraform-state"
    path = "awesome-project/development.tfstate"
  }
}

1. Remote Backend

A remote backend stores the state file in a centralized location, such as a cloud object storage service or a database.

Remote backends provide several benefits, such as enabling collaboration between team members, versioning state files, and providing a history of changes.

There are several remote backend providers available, such as Amazon S3, Azure Storage, Google Cloud Storage, and HashiCorp Consul.

terraform {
  backend "remote" {
    hostname = "ministry-of-magic.scalr.io"
    organization = "env-tqaqjimtnmmgiv0"

    workspaces {
      name = "mysteries-kubernetes-dev"
    }
  }
}

Remote Backend Service Types

1. S3

Amazon S3 is a popular cloud object storage service that can be used as a backend for storing Terraform state files.

terraform {
  backend "s3" {
    bucket = "s3sydprdmomstate"
    key    = "dev/mysteries-kubernetes.tfstate"
    region = "ap-southeast-2"
  }
}

1. Azure

Azure Storage is a cloud object storage service offered by Microsoft Azure that can be used as a backend for storing Terraform state files.

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-aus-prd-mom-state"
    storage_account_name = "saausprdmomstate"
    container_name       = "dev"
    key                  = "mysteries-kubernetes.terraform.tfstate"
  }
}

1. GCP

Google Cloud Storage is a cloud object storage service offered by Google Cloud Platform that can be used as a backend for storing Terraform state files.

terraform {
  backend "gcs" {
    bucket  = "gcs-syd-prd-mom-state"
    prefix  = "dev/mysteries-kubernetes"
  }
}

Local Vs Remote

Local Vs Remote