terraform中不同环境的多个后端(Multiple backends for different environments in terraform)

terraform中不同环境的多个后端(Multiple backends for different environments in terraform)

我曾经使用运行不同“terraform remote config”命令的多个.sh文件在不同环境（dev，test和prod）的不同Google Cloud项目中的存储桶中的状态文件之间切换。

使用0.9.0版本，我明白现在进入一个.tf文件：

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

在0.9.0版中，现在还有国家环境（“terraform env”）：

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

但是，我应该如何使用新的后端配置来管理同一目录结构中的多个环境？

I used to use multiple .sh files that ran different "terraform 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 goes into a a .tf file:

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

In version 0.9.0 there is now also the State Environment ("terraform env"):

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

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

最满意答案

在撰写本文时，Terraform中并非所有远程后端都已更新以支持状态环境。 对于那些拥有，每个后端都有自己的约定，用于表示数据存储中现在的多个状态。

从版本0.9.2开始，“consul”，“s3”和“local”后端已经更新。 “gcs”后端还没有，但是一旦它具有这里描述的过程，也将适用于此。

最初有一个“默认”环境，但是如果您从未运行terraform apply这个选定的环境，那么您可以忽略它并为您的环境命名。

要创建一个名为“生产”的新环境并切换到它：

terraform env new production

这将在后端建立一个完全独立的状态，所以terraform plan应该显示所有资源都需要新建。

您可以在已有的环境之间切换，如下所示：

terraform env select production

---

在0.9之前，许多团队（包括你的团队，听起来都像是）编写了包装脚本来模拟这种行为。 这些脚本可能并不遵循存储后端中完全相同的命名约定，因此需要进行一些手动工作才能迁移。

实现这种迁移的一种方法是开始使用“本地”后端，该后端将状态存储在本地目录（名为terraform.state.d 。 在本地工作时，您可以创建所需的环境，然后使用以前的脚本解决方案中的现有状态文件，仔细覆盖本地目录中的空状态文件。 一旦所有本地环境都具有适当的状态，您就可以将配置中的backend块更改为适当的远程后端，并运行terraform init以触​​发所有本地环境迁移到新后端。

在此之后， terraform env select命令将开始在远程环境而不是本地环境之间切换。

如果您选择的远程后端尚不支持环境，则最好暂时继续使用脚本解决方案。 这意味着使用部分配置模式将现有包装脚本中的terraform remote config替换为将特定于环境的配置传递到terraform init 。

At the time of this writing, not all of the remote backends in Terraform have been updated to support state environments. For those that have, each backend has its own conventions for how to represent the now-multiple states in the data store.

As of version 0.9.2, the "consul", "s3" and "local" backends have been updated. The "gcs" backend has not yet, but once it has the procedure described here will apply to that too.

There's initially a "default" environment, but if you never run terraform apply with this environment selected then you can ignore it and name your environments whatever you want.

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

terraform env new production

This will establish an entirely separate state on the backend, so terraform plan should show that all of the resources need to be created fresh.

You can switch between already-existing environments like this:

terraform env select production

---

Before 0.9, many teams (including yours, it sounds like) wrote wrapper scripts to simulate this behavior. It's likely that these scripts didn't follow exactly the same naming conventions in the storage backends, so some manual work will be required to migrate.

One way to do that migration is to start off using the "local" backend, which stores state in a local directory called terraform.state.d. While working locally you can create the environments you want and then carefully overwrite the empty state files in the local directory with the existing state files from your previous scripted solution. Once all of the local environments have appropriate states in place you can then change the backend block in the config to the appropriate remote backend and run terraform init to trigger a migration of all of the local environments into the new backend.

After this, the terraform env select command will begin switching between the remote environments rather than the local ones.

If your chosen remote backend doesn't yet support environments, it's best to continue with a scripted solution for the time being. This means replacing terraform remote config in your existing wrapper script with a use of the partial configuration pattern to pass environment-specific configuration into terraform init.