我正在尝试使用 Terraform 构建我们的 AWS 环境，但遇到了一些扩展问题。我有一个只包含我想在构建环境时重复使用的模块的存储库，还有一个用于处理这些模块的实际实现的第二个存储库。
我知道 HashiCorp 的 Github 页面有一个示例，但在那里，每个环境都是一个状态文件。我想将环境拆分出来，然后在每个环境中有多个状态文件。当状态文件变大时，应用小更新需要很长时间。
我见过的每个使用多个状态文件的示例，Terraform 文件都非常不干燥且不理想。
我希望能够在环境之间使用不同的变量值，但具有相同的配置。
有人做过这样的事吗？我错过了什么吗？我有点沮丧，因为每个 Terraform 示例都没有规模，这让像我这样的 n00b 很难走上正确的道路。非常感谢任何帮助或建议！
【问题讨论】：
标签： amazon-web-services terraform
不幸的是，环境的概念往往对不同的人和组织有不同的含义。
对某些人来说，它只是创建一些基础架构的多个副本——可能只是临时的，或者可能是长期存在的——以允许在一个环境中进行测试和实验而不影响另一个（可能生产）环境.
对于其他人来说，它是部署架构中的一流构造，环境充当容器，其他应用程序和基础架构部署到该容器中。在这种情况下，通常有多个单独的 Terraform 配置，每个配置在每个环境中都有一组资源，共享数据以从较小的部分创建一个更大的系统。
Terraform 有 a feature called State Environments 服务于第一个用例，它允许多个命名状态同时存在于给定的配置中，并允许用户使用 terraform env 命令在它们之间切换以将更改操作集中在一个特定的状态。
State Environments 功能单独 不足以满足第二个用例，因为它仅在单个配置中处理多个状态。但是，它可以与其他 Terraform 功能结合使用，利用 ${terraform.env} 插值来处理差异，以允许单个配置中的多个状态环境与另一个配置中的相应状态环境集交互。
在我的系列文章Terraform Environment+Application Pattern 中描述了一种“大规模”方法（相对而言），它描述了成功部署架构的概括，其中许多单独的应用程序部署在一起以形成一个环境。
在该模式中，环境自身（如上所述，作为应用程序的“容器”）每个都使用单独的 Terraform 配置创建，允许每个在如何配置的细节上有所不同，但它们都以标准方式公开数据，以允许多个应用程序（每个应用程序都使用 State Environments 功能）为每个环境部署一次，使用相同配置。
这种妥协会导致环境配置之间出现一些重复——这可以通过使用Terraform modules 在它们之间共享模式来缓解——但这些随后作为允许其他配置被泛化和部署多次的基础没有这样的重复。
【讨论】：
terraform env 已重命名为 terraform workspace