A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developer.hashicorp.com/terraform/language/backend/remote below:

Backend Type: remote | Terraform

Note: We introduced the remote backend in Terraform v0.11.13 and Terraform Enterprise v201809-1. As of Terraform v1.1.0 and Terraform Enterprise v202201-1, we recommend using HCP Terraform's built-in cloud integration instead. The cloud option supports an improved user experience and more features, such as structured run output mode, which displays your plan and apply results in a human-readable format.

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. It used to be called an "enhanced" backend.

When using full remote operations, operations like terraform plan or terraform apply can be executed in Terraform Cloud's run environment, with log output streaming to the local terminal. Remote plans and applies use variable values from the associated HCP Terraform workspace.

You can also use HCP Terraform with local operations, in which case only state is stored in the HCP Terraform backend.

The remote backend supports the following Terraform commands:

The remote backend can work with either a single remote HCP Terraform workspace, or with multiple similarly-named remote workspaces (like networking-dev and networking-prod). The workspaces block of the backend configuration determines which mode it uses:

The backend configuration requires either name or prefix. Omitting both or setting both results in a configuration error.

If previous state is present when you run terraform init and the corresponding remote workspaces are empty or absent, Terraform will create workspaces and update the remote state accordingly. However, if your workspace requires variables or a specific version of Terraform for remote operations, we recommend that you create your remote workspaces on HCP Terraform before running any remote operations against them.

Workspace Names

Terraform uses shortened names without the common prefix to interact with workspaces on the command line. For example, if prefix = "networking-", use terraform workspace select prod to switch to the Terraform CLI workspace prod within the current configuration. However, remote Terraform operations such as plan and apply for that Terraform CLI workspace will take place in the HCP Terraform workspace networking-prod.

Because of this, the terraform.workspace interpolation expression produces different results depending on whether a remote workspace is configured to perform operations locally or remotely. For example, in a remote workspace called networking-prod created with prefix = "networking-" the expression produces the following:

Prior to Terraform version 1.1.0, HCP Terraform workspaces used only the single default Terraform CLI workspace internally. So if a Terraform configuration used terraform.workspace to return dev or prod, remote runs in HCP Terraform would always evaluate it as default, regardless of which workspace you set with the terraform workspace select command. Therefore, we do not recommend using terraform.workspace in Terraform configurations that use Terraform 1.0.x or earlier and run remote operations against HCP Terraform workspaces.

Determining Run Environment

If you need to determine whether a run is local or remote in your Terraform configuration, we recommend using HCP Terraform run environment variables. The example below uses HCP_TERRAFORM_RUN_ID.

output "current_workspace_name" {
  value = terraform.workspace
}

variable "HCP_TERRAFORM_RUN_ID" {
  type    = string
  default = ""
}

output "remote_execution_determine" {
  value = "Remote run environment? %{if var.HCP_TERRAFORM_RUN_ID != ""}Yes%{else}No this is local%{endif}!"
}

Note: We recommend omitting the token from the configuration, and instead using terraform login or manually configuring credentials in the CLI config file.

Basic Configuration 
# Using a single workspace:
terraform {
  backend "remote" {
    hostname = "app.terraform.io"
    organization = "company"

    workspaces {
      name = "my-app-prod"
    }
  }
}

# Using multiple workspaces:
terraform {
  backend "remote" {
    hostname = "app.terraform.io"
    organization = "company"

    workspaces {
      prefix = "my-app-"
    }
  }
}
Using CLI Input 
# main.tf
terraform {
  required_version = "~> 0.12.0"

  backend "remote" {}
}

Backend configuration file:

# config.remote.tfbackend
workspaces { name = "workspace" }
hostname     = "app.terraform.io"
organization = "company"

Running terraform init with the backend file:

terraform init -backend-config=config.remote.tfbackend
Data Source Configuration 
data "terraform_remote_state" "foo" {
  backend = "remote"

  config = {
    organization = "company"

    workspaces = {
      name = "workspace"
    }
  }
}

Warning: We recommend using environment variables to supply credentials and other sensitive data. If you use -backend-config or hardcode these values directly in your configuration, Terraform will include these values in both the .terraform subdirectory and in plan files. Refer to Credentials and Sensitive Data for details.

The following configuration options are supported:

Note: You must use the name key when configuring a terraform_remote_state data source that retrieves state from another HCP Terraform workspace. The prefix key is only intended for use when configuring an instance of the remote backend.

For configurations that include a backend "remote" block, commands that make local modifications to Terraform state and then push them back up to the remote workspace accept the following option to modify that behavior:

Version note: .terraformignore support was added in Terraform 0.12.11.

When executing a remote plan or apply in a CLI-driven run, an archive of your configuration directory is uploaded to HCP Terraform. You can define paths to ignore from upload via a .terraformignore file at the root of your configuration directory. If this file is not present, the archive will exclude the following by default:

The .terraformignore file can include rules as one would include in a .gitignore file

Note that unlike .gitignore, only the .terraformignore at the root of the configuration directory is considered.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4