拆分 terraform tfstate 文件答案

【问题标题】：Split terraform tfstate file拆分 terraform tfstate 文件
【发布时间】：2019-06-19 18:10:13
【问题描述】：

我们从一个 tfstate 文件开始，随着时间的推移，它增长了很多。

现在，计划起来真的很慢，我现在想分成几个 tfstate 文件（一个用于我们的开发环境，一个用于通用共享基础架构，一个用于每个生产环境）。

就像在 https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-tfstate-file-per-env/ 和 Terraform Multiple State Files Best Practice Examples 中描述的那样。

是否有任何现有工具（内置或非内置）可以帮助解决这个问题？有点像 terraform state mv 但在 tfstates 之间？

【问题讨论】：

如果有的话，我会对这个工具感兴趣。我倾向于使用 terraform rm 和 terraform import 拆分到另一个状态文件中。或复制状态文件并删除不需要的内容。取决于您在此处管理的资源数量
嗯，我想编写脚本还不错，我们先 terraform state list 然后循环使用 rm + import...
还不错，但我想问题是无法导入的资源，例如路由表中的单个路由（我上次检查时你不能）

标签： terraform

【解决方案1】：

terraform state mv 具有 -state-out 标志，您可以在其中定义另一个状态以将您的资源移动到。

但是，我无法让它与 0.11.14 版本一起使用，因此我从需要移动到另一个状态的状态文件中手动剪切并粘贴了模块，效果非常好。

编辑：这是一种解决方法，它基本上会加载两个状态文件，移动所需的状态，然后将它们重新上传到 S3 存储桶：https://github.com/hashicorp/terraform/pull/15652#issuecomment-410754814

【讨论】：

Terraform 文档示例：commands/state/mv。我无法解释为什么它对@dimitris 不起作用，但对我来说效果很好。（也许是因为 TF 现在还有 5 年的成熟期？）
可能是因为我使用 s3 支持的后端进行了尝试。尚未在本地提供两种状态的情况下对其进行测试。
哦，好点。我只是想要一个快速的 POC，所以我使用了本地 tfstate 文件。

【解决方案2】：

为基础设施和应用程序分别拥有一个单独的状态文件是有意义的。

是否有任何现有工具（内置或非内置）可以帮助解决这个问题？有点像 terraform state mv 但在 tfstates 之间？

不，据我所知。将共享部分（例如 ECS 集群、ALB、网络配置、iam 角色等）移出到单独的项目/存储库中。

当使用 S3 作为状态后端时，您可以为您的基础架构和应用程序状态定义不同的路径，例如：

/infrastructure/nonprod/terraform.tfstate
/infrastructure/prod/terraform.tfstate
/apps/app1/test/terraform.tfstate
/apps/app1/uat/terraform.tfstate
/apps/app1/prod/terraform.tfstate

当您想将应用程序部署到 TEST 或 UAT 时，您只需在基础架构项目中调用 terraform init，然后再调用 terraform apply，方法是提供非产品 S3 状态的路径。然后通过提供 TEST 或 UAT 路径的路径，在您的应用程序 terraform 配置上调用 terraform init。

理想情况下，您可以创建自己的 shell 脚本来配置和部署您的应用程序。然后在您最喜欢的 CI 中，您可以创建一个管道来根据需要配置基础设施和部署应用程序。确保参数化这些脚本，以便您可以传递要配置的环境或要部署的应用程序，例如：

./my-shared-infrastructure/provision-infrastructure.sh nonprod

./my-app-1/deploy-application.sh uat v1.0

【讨论】：

【解决方案3】：

在一个复杂的世界中，从我所参与的情况来看，我们走得更远。经过共同的努力，我们不仅成功地隔离了环境，还成功地隔离了作为基础架构一部分的所有组件。

向下挖掘，组件我的意思是每个组件有一组特定的模块/输出，配置中没有额外的资源，但当然出现了依赖关系问题......没有什么不能用一些数据解决的{}引用到微小的状态和一些脚本。

结果很棒。我们用不同的参数实例化了相同的组件，每个环境都干净，易于维护和操作。

我不建议在现有庞大基础设施的情况下使用这种方法，如果您厌倦了单一的单一状态文件，则需要一些额外的与转换相关的活动，但它可以在新建项目中大大加速。

【讨论】：