Skip to main content

Terraform Associate Notes

Backend block​

The backend defines where Terraform stores its state data files.

 If your configuration includes a cloud block, it cannot include a backend block.

There are some important limitations on backend configuration:

  • A configuration can only provide one backend block.
  • A backend block cannot refer to named values (like input variables, locals, or data source attributes).
  • You cannot reference values declared within backend blocks elsewhere in the configuration.

Terraform ships with several built-in backend types. Some backends function as remote disks for state files, while others support locking the state during Terraform operations to prevent conflicts and inconsistencies.

When you change a backend's configuration, you must run terraform init again to validate and configure the backend before you can perform any plans, applies, or state operations.

Backend Types​

  • local:
    • Terraform uses a backend called local by default. The local backend stores state on the local filesystem, locks that state using system APIs, and performs operations locally.
terraform {
  backend "local" {
    path = "relative/path/to/terraform.tfstate"
  }
}
  • remote:
    • The remote backend is unique among all other Terraform backends because it can both store state snapshots and execute operations for HCP Terraform's CLI-driven run workflow. I
    • we recommend using HCP Terraform's built-in cloud integration instead. The cloud option supports an improved user experience and more features
terraform {
  backend "remote" {
    hostname = "app.terraform.io"
    organization = "company"

    workspaces {
      name = "my-app-prod"
    }
  }
}
  • azurerm:
    • Stores the state as a Blob with the given Key within the Blob Container within the Blob Storage Account.
    • This backend supports state locking and consistency checking with Azure Blob Storage native capabilities.
terraform {
  backend "azurerm" {
    resource_group_name  = "StorageAccount-ResourceGroup" 
    storage_account_name = "abcd1234"                      
    container_name       = "tfstate"                       
    key                  = "prod.terraform.tfstate"        
    use_azuread_auth     = true  
  }
}
  • consul:
    • Stores the state in the Consul KV store at a given path.
    • This backend supports state locking.
terraform {
  backend "consul" {
    address = "consul.example.com"
    scheme  = "https"
    path    = "full/path"
  }
}
  • gcs:
    • Stores the state as an object in a configurable prefix in a pre-existing bucket on Google Cloud Storage (GCS). The bucket must exist prior to configuring the backend.
    • This backend supports state locking.
terraform {
  backend "gcs" {
    bucket  = "tf-state-prod"
    prefix  = "terraform/state"
  }
}
  • http:
    • Stores the state using a simple REST client.
    • State will be fetched via GET, updated via POST, and purged with DELETE. The method used for updating is configurable.
    • This backend optionally supports state locking. When locking support is enabled it will use LOCK and UNLOCK requests providing the lock info in the body.
terraform {
  backend "http" {
    address = "http://myrest.api.com/foo"
    lock_address = "http://myrest.api.com/foo"
    unlock_address = "http://myrest.api.com/foo"
  }
}

  • kubernetes:

  • pg:

    • Stores the state in a Postgres database version 10 or newer.
    • This backend supports state locking.
    • Before initializing the backend with terraform init, the database must already exist.
terraform {
  backend "pg" {
    conn_str = "postgres://user:pass@db.example.com/terraform_backend"
  }
}
  • s3:
    • Stores the state as a given key in a given bucket on Amazon S3.
    • This backend also supports state locking and consistency checking via Dynamo DB, which can be enabled by setting the dynamodb_table field to an existing DynamoDB table name. A single DynamoDB table can be used to lock multiple remote state files.
terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key"
    region = "us-east-1"
  }
}

VCS Providers​

Terraform supports the following VCS providers:

  • GitHub.com
  • GitHub App for TFE
  • GitHub.com (OAuth)
  • GitHub Enterprise
  • GitLab.com
  • GitLab EE and CE
  • Bitbucket Cloud
  • Bitbucket Data Center
  • Azure DevOps Server
  • Azure DevOps Services

Benefits when connecting to VCS providers:

  • When workspaces are linked to a VCS repository, HCP Terraform can automatically initiate Terraform runs when changes are committed to the specified branch.
  • HCP Terraform makes code review easier by automatically predicting how pull requests will affect infrastructure.
  • Publishing new versions of a private Terraform module is as easy as pushing a tag to the module's repository.

Publish Modules​

Published modules support versioning, automatically generate documentation, allow browsing version histories, show examples and READMEs, and more. We recommend publishing reusable modules to a registry. The registry extracts information about the module from the module's source. The module name, provider, documentation, inputs/outputs, and dependencies are all parsed and available via the UI or API

The list below contains all the requirements for publishing a module:

  • GitHub. The module must be on GitHub and must be a public repo. This is only a requirement for the public registry. If you're using a private registry, you may ignore this requirement.

  • Named terraform-<PROVIDER>-<NAME>. Module repositories must use this three-part name format, where <NAME> reflects the type of infrastructure the module manages and <PROVIDER> is the main provider where it creates that infrastructure. The <NAME>segment can contain additional hyphens. Examples: terraform-google-vault or terraform-aws-ec2-instance.

  • Repository description. The GitHub repository description is used to populate the short description of the module. This should be a simple one sentence description of the module.

  • Standard module structure. The module must adhere to the standard module structure. This allows the registry to inspect your module and generate documentation, track resource usage, parse submodules and examples, and more.

  • x.y.z tags for releases. The registry uses tags to identify module versions. Release tag names must be a semantic version, which can optionally be prefixed with a v. For example, v1.0.4 and 0.9.2. To publish a module initially, at least one release tag must be present. Tags that don't look like version numbers are ignored.

Topics to review​

  • variable scopes
  • dynamic block
  • import
  • publish module on Terraform registry
Tags:
Last updated on by daniel.guo