liveBook · Manning

Terraform backend

As explained in Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu

A Terraform configuration block that declares the backend configuration for a module.

A team cannot reliably share a Terraform deployment if its state lives only on one developer’s computer. A backend tells Terraform where to store state so the workspace can be used from different machines. State holds metadata about managed resources; separate deployments can have separate locations in the same backend. section 1.2.5 section 1.2.6

Declare the backend inside the `terraform` settings block of the root module: `terraform { backend "consul" { ... } }`. The label selects the backend; the arguments depend on that backend. Consul, for example, needs connection and state-path settings. If neither a `backend` nor a `cloud` block is defined, Terraform uses the local backend, which writes state to the local filesystem. That is useful for development, not production. section 6.4.3 section 2.3.1

Listing 6.8 Terraform backend block with Consul
terraform {                                                       #1
  backend "consul" {                                              #2
    address      = "localhost:8500"                               #3
    scheme       = "http"                                         #4
    path         = "path/to/save/state"
    access_token = "01a56e2d-a96a-4ca5-9d39-d5152015f533"         #5
  }
}

The Consul configuration shows the block’s placement and its backend-specific address, scheme, path, and access-token arguments. The example points to a locally running Consul instance. section 6.4.3

Initialize with partial configuration

A backend block can specify `backend "consul" { scheme = "https" }` while leaving other settings in a separate configuration file. Supply that file with `terraform init -backend-config=PATH`; the example file contains `address`, `path`, and `access_token`. During `terraform init`, Terraform initializes the backend before installing providers. section 6.4.3 section 1.4.2

Before relying on a backend for shared state:

  • Choose a supported backend that fits technology the team already uses, and check its current documentation for required arguments and authentication. section 6.4.1 section 2.3.1
  • Restrict and log state access; enable encryption and locking where required. Keep reliable backups and test that they can be restored. State loss can make future plans fail or treat existing resources as new. section 6.4.2 section 6.2.1
  • Review Terraform upgrade notes: backends are built into Terraform, and their parameters or availability can change between versions. section 6.4.8

How Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu covers it

How deep it goes
Works through a root-module Consul block and partial initialization, but defers backend-specific configuration details to current documentation.
Examples
Uses a locally run Consul backend, a Terraform configuration block, and `terraform init -backend-config=PATH`.
What it assumes
Introduces backend blocks through a local Consul walkthrough that requires Docker for the example environment.
What you can do after
Operate/configure it by declaring a supported backend, initializing it, and checking access, locking, and backups before team use.
How it connects
Connects Terraform state and workspaces to backend selection, initialization, state locking, backups, and Terraform upgrades.
Cover of Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu
liveBookmanning.com
Read Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu on liveBook Get the book at manning.com

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu. The section links point to the parts of the book it draws on.