4.4 KiB
layout, page_title
| layout | page_title |
|---|---|
| docs | Initializing and Migrating to Terraform Cloud - Terraform CLI |
Initializing and Migrating
After configuring Terraform Cloud settings for a working directory, you must run terraform init to finish setting up. When running this command, Terraform may guide you through an interactive process where you may choose whether or not to migrate state from any existing workspaces.
There are three potential scenarios:
- Fresh working directory: If the working directory has no existing Terraform state, no migrations will occur. You can start using Terraform with Terraform Cloud right away, creating workspaces and starting runs.
- State backend or local state: If the working directory already has state data in one or more workspaces (using either local state or a state backend), Terraform will ask if you're like to migrate that state to new Terraform Cloud workspaces. You will need permission to manage workspaces in the destination Terraform Cloud organization. You may also be prompted to rename the workspaces being migrated, to better distinguish them within a Terraform Cloud organization.
remotebackend: If the working directory was already connected to Terraform Cloud with theremotebackend, Terraform can continue using the same Terraform Cloud workspaces. The local names shown for those workspaces will change to match their remote names.
The rest of this page briefly describes cases 2 and 3.
Migrating from Local State or Other Backends
If the working directory already has state data available (using either local state or a state backend), Terraform will ask your approval to migrate that state to Terraform Cloud. This process is interactive and self-documenting, and resembles moving between state backends.
You may also be prompted to rename your workspaces during the migration, to either give a name to
the unnamed default workspace (Terraform Cloud requires all workspaces to have a name) or give
your workspace names more contextual information. Unlike typical Terraform workspaces representing
an environment associated with a particular configuration (e.g. production, staging, development),
Terraform Cloud workspaces are named uniquely across all configurations used within an organization.
Because of this, you'll be given an opportunity to rename the working directory's workspaces
according to a pattern relative to their existing names. A typical strategy to start with is
<COMPONENT>-<ENVIRONMENT>-<REGION> (e.g. networking-prod-us-east,
networking-staging-us-east). For more information on workspace naming, see Workspace
Naming in the Terraform Cloud documentation.
Migrating from the remote Backend
The remote backend was the primary
implementation of Terraform Cloud's CLI-driven run workflow for
Terraform versions 0.11.13 through 1.0.x. We recommend using the native cloud
integration for Terraform versions 1.1 or later, as it provides an improved user experience and
various enhancements.
Block Replacement
When switching from the remote backend to a cloud block, Terraform will continue using the same
set of Terraform Cloud workspaces. Replace your backend "remote" block with an equivalent cloud
block:
-
If you were using a single workspace with the
nameargument, change the block label tocloud.terraform { - backend "remote" { + cloud { organization = "my-org" workspaces { name = "my-app-prod" } } } -
If you were using multiple workspaces via the
prefixargument, replace it with acloudblock that uses thetagsargument. You may specify any number of tags to distinguish the workspaces for your working directory, but a good starting point may be to use whatever the prefix was before.The tags you configure do not need to be present on the existing workspaces. When you initialize, Terraform will add the specified tags to the workspaces if necessary.
terraform { - backend "remote" { + cloud { organization = "my-org" workspaces { - prefix = "my-app-" + tags = ["app:mine"] } } }