使用 Git 管理 Terraform 多个环境

时间:2021-06-21 14:28:20

标签: git terraform

我研究并观看了一些关于管理多个环境的最佳方式的视频,但我仍然对如何以更好的方式管理它感到困惑。

假设我有一个具有以下结构的存储库:

main.tf
variables.tf
backend.tf
dev/
   variables.tfvar
   backend.dev.hcl
prod/
   variables.tfvar
   backend.production.hcl

然后,在我的存储库中,我有两个分支(dev 和 main)。 将生产变量值提交到我的开发分支是否有意义?遵循最佳做法来处理这种情况的最佳方法是什么?

我的最后一个问题,一旦向 dev 分支提交了任何更改,在不丢失任何 dev/prod terraform 配置的情况下将更改合并到 prod 分支的最佳方法是什么?

先谢谢你!

1 个答案:

答案 0 :(得分:1)

这个问题的答案通常取决于您是在谈论 Terraform 配置本身的多个部署阶段本身,还是在 Terraform 上运行的任何应用程序/服务的多个部署阶段-托管基础设施。

考虑这种区别的一种方法是考虑您将使用多个阶段来实现什么。如果您的目标是在生产环境中尝试运行 terraform apply,那么您正在谈论 Terraform 配置的多个部署阶段。如果您的目标是创建一个长期存在的暂存环境,以便将应用程序/服务部署到其中,那么从部署管道的角度来看,暂存环境通常也是“生产”环境,因此通常应如此对待。


要在将 Terraform 配置应用于“真实基础设施”之前对其进行测试,您可以使用 Terraform CLI workspaces 创建与您的配置相关联的临时附加状态,这样您就可以尝试应用更改而不影响在“默认”工作区:

  • terraform workspace new temp-test 创建临时工作区。
  • 使用您的版本控制系统选择最近在 default 工作区中应用的提交。这通常位于版本控制存储库的主分支上,但根据您使用 VCS 的方式,您可能需要选择较早的提交以排除尚未应用于实际系统的任何更改。
  • terraform apply 创建与默认工作区等效的基础架构,作为测试的基础。
  • 使用您的版本控制系统切换回您要测试的配置。这通常是您存储库中的一个功能分支,可能附加到拉取请求。在此工作流的真实版本中,以您的分支名称命名您的临时工作区可能会有所帮助,这样您的同事就可以轻松查看哪些分支和工作区组合在一起。
  • terraform apply 再次规划和应用新配置所代表的更改。
  • 如果应用成功,请检查它创建的基础架构,以确保它按您预期的方式运行。
  • 完成后:
    • terraform destroy 破坏 temp-test 基础设施
    • terraform workspace select 返回默认工作区
    • terraform workspace delete temp-test 删除临时工作区

为此,您需要小心避免在远程系统需要唯一名称的情况下与现有生产对象发生冲突。对于具有独立命名空间的帐户的系统,一个常见的选择是使用不同的帐户和完全独立的凭据进行测试,这意味着您可以使用远程系统的访问控制来避免“真实”基础设施的意外中断.


要创建一个长期存在的临时或开发环境以在其自己的部署管道中测试某些更高级别的组件需要不同的策略:在这种情况下,支持临时环境的基础设施是“生产”的一部分涉及应用程序的部署过程,因此通常应如此建模。

为了实现这一目标,同时确保两个基础架构堆栈除了有意的差异之外保持相同,请将您的公共基础架构代码分解为一个或多个 modules,然后为生产基础架构调用这些模块一次,并再次为彼此调用这些模块环境的基础设施。

根据系统预期的故障域,您可以选择在单个配置中同时表示生产和暂存基础设施,其中包含对同一模块的两次调用:

module "network-production" {
  source = "../modules/network"

  cidr_block = "10.1.0.0/16"
  # etc...
}

module "network-production" {
  source = "../modules/network"

  cidr_block = "10.2.0.0/16"
  # etc...
}

或者,为了确保它们都可以独立维护,您可以编写两个单独的配置,它们都调用同一个模块并分别terraform apply

在这两种情况下,这里的想法是使用公共模块的输入变量来表示不同环境之间不可避免的差异,但在两种情况下保持声明的资源相同,但将它们都视为“生产基础设施”从应用程序管道的角度来看,将它们都保存在一个名为 default 的命名空间中,在一个配置中或跨多个配置,并在版本控制中使用相同的主分支来表示它们的“最新版本”一次。

如果您想测试对共同代表您的应用程序管道所依赖的所有环境的配置所做的更改,您可以通过创建一个代表您的整个堆栈或一个特定环境的临时工作区并应用来自在将其合并到主分支并将其应用于默认工作区之前,先分支到该堆栈。


此答案是 Terraform 文档 When to use Multiple Workspaces 中指南的详细说明。

最终,在这种情况下,您有几种不同的选择,但要权衡不同,我鼓励您查看此建议和文档中的其他相关上下文,并自行决定哪些建议最符合您的需求. Terraform 是用于解决各种不同问题的通用工具,最终只有您可以将您的特定需求集映射到 Terraform 的功能。