Lots of backends for different terraform environments

Question

I used several .sh files that ran different "trraform remote config" commands to switch between state files in buckets in different Google Cloud projects for different environments (dev, test and prod).

With version 0.9.0, I understand that this now happens in the .tf file:

terraform { backend "gcs" { bucket = "terraform-state-test" path = "terraform.tfstate" project = "cloud-test" } } 

Version 0.9.0 now also has a state environment ("terraform env"):

 resource "google_container_cluster" "container_cluster" { initial_node_count = "${terraform.env == "prod" ? 5 : 1}" } 

But how do I now manage multiple environments in the same directory structure with the new backend configuration?

Answer 1

At the time of this writing, not all remote Terraform servers have been updated to support environmental states. For those who have, each backend has its own conventions on how to present several states in the data warehouse now.

Starting with version 0.9.2, "consul", "s3" and "local" have been updated. The gcs backend does not exist yet, but as soon as it is described here, this also applies.

First, the default environment is created initially, but if you never run terraform apply with the selected environment, you can ignore it and name your environments no matter what you want.

To create a new environment called "production" and switch to it:

 terraform env new production 

This sets a completely separate state on the backend, so the terraform plan should show that all resources must be created fresh.

You can switch between existing environments as follows:

 terraform env select production 

---

Prior to 0.9, many teams (including yours, that sounds) wrote shell scripts to simulate this behavior. These scripts probably did not match exactly the same naming conventions in the repositories, so some manual work is required for the migration.

One way to migrate is to start by using a "local" backend that saves state in a local directory called terraform.state.d . Working locally, you can create the environments you need and then carefully overwrite empty state files in the local directory with existing state files from your previous script. After all local environments have the corresponding states, you can change the backend block in the configuration to the appropriate remote server and run terraform init to initiate the transfer of all local environments to the new backend.

After that, the terraform env select command will begin switching between remote environments, not local ones.

If the selected remote backend does not yet support the environment, it is best to continue running the script. This means replacing the terraform remote config in your existing script shell with a partial configuration in order to pass the environment-specific configuration to terraform init .