Terraform 多个状态文件最佳实践示例

Jus*_*mia 5 amazon-web-services terraform

我正在尝试使用 Terraform 构建我们的 AWS 环境,但遇到了一些扩展问题。我有一个仅包含在构建环境时要重复使用的模块的存储库,还有一个仅用于处理这些模块的实际实现的存储库。

我知道 HashiCorp 的 Github 页面有一个示例,但在那里,每个环境都是一个状态文件。我想拆分环境,但每个环境中有多个状态文件。当状态文件变大时,应用小更新需要很长时间。

我见过的每个使用多个状态文件的示例,Terraform 文件都非常不干燥且不理想。

我希望能够在环境之间具有不同的变量值但具有相同的配置。

有没有人做过这样的事情?我错过了什么吗?我有点沮丧,因为每个 Terraform 示例都没有规模化,这让像我这样的 n00b 很难走上正确的道路。非常感谢任何帮助或建议!

Mar*_*ins 6

不幸的是,环境的概念对不同的人和组织往往意味着不同的东西。

对某些人来说,它只是创建一些基础设施的多个副本——可能只是临时的,也可能是长期存在的——以允许在一个环境中进行测试和实验,而不会影响另一个(可能是生产)环境。

对于其他人来说,它是部署架构中的一流构造,环境充当容器,其他应用程序和基础设施部署到其中。在这种情况下,通常有多个单独的 Terraform 配置,每个配置在每个环境中都有一组资源,共享数据以从较小的部分创建更大的系统。

Terraform 有一个称为状态环境的功能,它通过允许多个命名状态同时存在于给定的配置中来服务于这些用例中的第一个,并允许用户使用terraform env命令在它们之间切换,以将更改操作集中在特定状态上。

单独状态环境功能对于第二个用例是不够的,因为它只处理单个配置中的多个状态。但是,它可以与其他 Terraform 功能结合使用,利用插值值来处理差异,从而允许单个配置中的多个状态环境与另一个配置中的一组相应状态环境进行交互。${terraform.env}


在我的系列文章Terraform Environment+Application Pattern中描述了一种“大规模”方法(相对而言),它描述了成功部署架构的概括,其中许多单独的应用程序部署在一起以形成环境。

在这种模式中,环境本身(作为应用程序的“容器”,如上所述)每个都使用单独的Terraform 配置创建,允许每个环境在配置方式的细节上有所不同,但它们每个都在一种标准方式,允许使用相同配置为每个环境部署一次多个应用程序——每个应用程序都使用状态环境功能。

这种妥协会导致环境配置之间出现一些重复——可以通过使用Terraform 模块在它们之间共享模式来缓解这种情况——但这些可以作为基础,允许其他配置被多次泛化和部署而不会出现这种重复。

  • 自 Terraform 0.11.something 起,“terraform env”已重命名为“terraformworkspace” (11认同)