TerraForm 阶段分离的最佳实践

94次阅读

问题描述

在使用 TerraForm 管理项目中，用户希望能够将开发阶段分隔开来，以实现更好的管理。用户在阅读 TerraForm 的工作空间页面时，发现以下描述：

“单独使用工作空间不适用于系统分解，因为每个子系统都应该有自己独立的配置和后端，因此将具有自己独特的工作空间集。”

然而，很多教程，比如这个教程，提到了：

“有两种主要方法可以在不同环境之间分离状态：（…）和 工作空间。”

这两种陈述似乎相互矛盾。请问什么是在阶段分隔方面的最佳实践？目前，我计划使用分隔的目录结构：

├── prod
│   ├── main.tf (引用模块)
│   ├── variables.tf
│   ├── terraform.tfstate
│   └── terraform.tfvars
├── dev
│   ├── main.tf (引用模块)
│   ├── variables.tf
│   ├── terraform.tfstate
│   └── terraform.tfvars
└── modules
    ├── 模块 A
    └── 模块 B

解决方案

请注意以下操作可能存在版本差异，确保操作前备份。

最佳实践：目录结构和工作空间

为了在 TerraForm 中实现阶段分离，可以使用不同的目录结构和工作空间。然而，需要根据你的团队结构和代码管理方式来选择最适合你的方法。

首先，让我们解释一下前述陈述之间的关系。第一段引用的内容表明，当多个团队共用同一个 TerraForm 目录（也就是配置）时，每个团队都会从其自身的工作空间中获取不同的配置。而第二段引用的内容则更加详细地解释了如何分离环境的状态。

目录结构和工作空间的结合使用

按照 TerraForm 的最佳实践，在管理较大系统时，团队应该使用多个独立的 TerraForm 配置，以与系统中适当的架构边界相对应。这样不同的组件可以分别管理，并在适当的情况下由不同的团队负责。

然而，工作空间并不是解决系统分解的唯一方法，因为每个子系统都应该有自己独立的配置和后端。因此，在实际实施中，你可以将不同的子系统分隔到不同的目录中，并使用不同的工作空间来管理它们。这样，不同的工作空间将用于不同的子系统，确保它们各自拥有独立的状态和配置。

分隔目录结构示例

你已经提到了使用分隔的目录结构来实现阶段分离，这是一个不错的做法。在你的项目中，prod 目录和 dev 目录分别对应生产环境和开发环境，每个目录中包含了相应的 TerraForm 配置和状态文件。这种做法可以有效隔离不同环境的配置和状态，从而确保环境之间的互相影响最小化。

以下是一个示例的目录结构：

├── prod
│   ├── main.tf (引用模块)
│   ├── variables.tf
│   ├── terraform.tfstate
│   └── terraform.tfvars
├── dev
│   ├── main.tf (引用模块)
│   ├── variables.tf
│   ├── terraform.tfstate
│   └── terraform.tfvars
└── modules
    ├── 模块 A
    └── 模块 B

在上述目录结构中，你可以根据需要分别管理生产环境和开发环境的 TerraForm 配置，每个目录下都有相应的配置文件和状态文件。

自动化部署和CI/CD

另一个需要考虑的因素是自动化部署和持续集成/持续交付（CI/CD）。如果你的组织规模较大，每周可能有数百次变更，那么你可能需要自动化部署流程。一种常见的做法是在发生新 Pull Request 或分支更改时触发 CI/CD 流程。在这种情况下，你可以根据分支名称来自动切换工作空间或配置状态路径，以实现不同环境的分离。