全面解析Terraform Stacks：规模化基础设施管理新范式

Terraform Stacks是一项旨在简化大规模基础设施配置与管理的新功能。本文深入探讨了Stacks如何解决跨配置依赖、多环境部署等挑战，详细介绍了其组件、部署、编排规则等核心概念，并提供了迁移指南。文章涵盖了Stacks在简化管理、提升生产力及支持Kubernetes等复杂用例方面的显著优势。

Terraform Stacks， 详解

Terraform Stacks 旨在简化大规模基础设施的配置和管理，提供一种内置的、无复杂性的扩展方式。本篇博客将介绍 Terraform Stacks 解决的挑战、其优势、使用场景、工作原理、功能特性以及未来路线图。

» Terraform Stacks 解决了哪些挑战？

使用小型模块和工作区构建可组合基础设施有很多好处。将 Terraform 代码拆分为可管理的部分有助于：

  • 限制资源变更的爆炸半径
  • 减少运行时间
  • 跨团队边界分离管理职责
  • 解决多步骤用例，例如配置 Kubernetes 集群

Terraform 能够获取代码、构建依赖关系图并将其转换为基础设施，这一能力非常强大。然而，一旦你将基础设施拆分到多个 Terraform 配置中，状态之间的隔离意味着你必须自己拼凑和管理依赖关系。

此外，在大规模部署和管理基础设施时，团队通常需要在以下多个方面使用不同的输入值多次配置相同的基础设施：

  • 云供应商账户
  • 环境（开发、预发布、生产）
  • 区域
  • 着陆区

在 Terraform Stacks 出现之前，Terraform 中没有内置的方法将这些实例作为一个单一单元来配置和管理其生命周期，这使得独立管理每个基础设施根模块变得困难。

我们知道，存在比仅仅用定制脚本和外部工具包装 Terraform 更好、更有价值的方式来解决这些挑战，因为后者需要大量工作，并且在设置和管理时容易出错且有风险。

» 什么是 Terraform Stacks？它们有哪些优势？

Stacks 帮助用户自动化并优化相互依赖的 Terraform 配置的协调、部署和生命周期管理，从而减少管理基础设施所需的时间和开销。主要优势包括：

  • 简化管理：Stacks 消除了手动跟踪和管理跨配置依赖关系的需要。共享相同生命周期的多个 Terraform 模块可以使用 Stack 中的组件组织并一起部署。
  • 提升生产力：Stacks 使用户能够通过一个简单操作快速创建和修改具有不同输入的一致基础设施设置。用户可以利用 Stack 中的部署轻松重复其基础设施，并可以设置编排规则来自动化在这些重复的基础设施实例之间推出更改。

Stacks 的目标是使用用户今天喜爱的相同 Terraform 共享模块，将基础设施即代码自然地扩展到更高层次。

» Terraform Stacks 的常见用例

以下是 Stacks 开箱即用的常见用例：

  • 将整个应用程序作为单一单元部署：将网络、存储和计算等组件作为单一单元部署，而无需担心依赖关系。Stack 配置将完整的基础设施单元描述为代码，可以交给没有高级 Terraform 经验的用户，让他们通过单个操作轻松建立复杂的基础设施部署。
  • 跨多个区域、可用区和云供应商账户部署，无需重复工作/代码：Stack 中的部署让你可以定义同一配置的多个实例，而无需复制粘贴配置或单独管理配置。当 Stack 配置发生更改时，可以将其推出到 Stack 中所有、部分或零个部署中。
  • 配置和管理 Kubernetes 工作负载：Stacks 通过允许客户在单个配置中部署 Kubernetes，而不是管理多个独立的 Terraform 配置，来简化 Kubernetes 工作负载的配置和管理。我们注意到 Kubernetes 部署通常有太多未知变量而无法正确完成计划。借助 Stacks，客户可以以更快的上市时间实现大规模的 Kubernetes 部署，而无需经历在 Terraform 中难以完成的分层方法。

要了解更多信息，请阅读 Terraform Stacks 用例文档。

» 如何使用 Terraform Stack？

Stacks 引入了一个新的配置层，位于 Terraform 模块之上，并编写为代码。

» 组件

此配置层的第一部分使用 .tfcomponent.hcl 文件扩展名声明，它告诉 Terraform 哪些基础设施或组件应成为 Stack 的一部分。你可以使用 Stack 中所谓的组件来组合和部署共享生命周期的多个模块。对于要包含在 Stack 中的每个模块，向 components.tfcomponent.hcl 配置添加一个 component 块。为每个组件指定源模块、输入和提供者。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# components.tfcomponent.hcl
component "cluster" {
  source = "./eks"
  inputs = {
    aws_region          = var.aws_region
    cluster_name_prefix = var.prefix
    instance_type       = "t2.medium"
  }
  providers = {
    aws       = provider.aws.this
    random    = provider.random.this
    tls       = provider.tls.this
    cloudinit = provider.cloudinit.this
  }
}

你无需重写任何模块，因为组件可以直接利用你现有的模块。

» 部署

此配置层的第二部分使用 .tfdeploy.hcl 文件扩展名，告诉 Terraform 在哪里以及部署多少次 Stack 中的基础设施。对于基础设施的每个实例，你添加一个具有相应输入值的 deployment 块，Terraform 将负责为你重复该基础设施。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# deployments.tfdeploy.hcl
deployment "west-coast" {
  inputs = {
    aws_region     = "us-west-1"
    instance_count = 2
  }
}

deployment "east-coast" {
  inputs = {
    aws_region     = "us-east-1"
    instance_count = 1
  }
}

当有新版本的 Stack 配置可用时，会为 Stack 中的每个部署启动计划。一旦计划完成，你可以批准 Stack 中所有、部分或零个部署的更改。

示例：Kubernetes 和命名空间组件通过三个部署在三个区域中重复。

» 部署组编排规则

随着 Stacks 使用量的增长，手动管理和批准每个部署可能成为一个重要的瓶颈。为了更有效地大规模管理部署，Stacks 具有部署组功能，它取代了公开测试版的编排规则。部署组允许你按环境、团队或应用程序对部署进行逻辑分组，然后在组级别分配自动化规则。

示例：Kubernetes 和命名空间组件在三个部署组中重复，每个组包含开发、预发布和生产环境的多个实例。

自定义部署组是一项附加功能，允许你在其配置中包含自动批准检查，这些是决定部署是否可以在无需人工干预的情况下安全批准的条件。如果满足条件，则部署组会自动获得批准。

例如，你可以编写一个检查，如果某个部署的计划不包含任何资源删除，则自动批准该部署。下面的示例展示了这种情况。它定义了一个名为 canary 的自定义部署组，其中包含一个自动批准检查，确保在自动批准之前计划中没有要删除的资源。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

deployment "canary" {
  deployment_group = deployment_group.canary
}

deployment_group "canary" {
  auto_approve_checks = [deployment_auto_approve.no_deletes]
}

deployment_auto_approve "no_deletes" {
  check {
    condition = context.plan.changes.remove == 0
    reason    = "Plan has ${context.plan.changes.remove} resources to be removed."
  }
}

每个部署组都可以拥有自己独特的检查集，从而为开发、预发布或生产等不同环境实现定制化的自动化。这意味着你不必为每个单独的部署重复配置相同的逻辑，从而实现跨组织的更快、更安全、更一致的部署。

自定义部署组在 HCP Terraform Premium 计划中可用。默认部署组在所有计划中都可用。要了解更多关于部署组编排规则的信息，请参阅此文档：为部署计划设置条件。

» 延迟变更

这是 Stacks 的一项功能，允许 Terraform 在遇到太多未知值时生成部分计划，而不会停止操作。这有助于用户更轻松地处理这些情况，从而加速特定工作负载与 Terraform 的部署。延迟变更使用户能够启用上面常见用例部分中提到的 Kubernetes 用例。

示例图片描述：Terraform 生成了一个部分计划，延迟了目前无法计划的其余资源。

考虑一个例子：将三个 Kubernetes 集群（每个集群有一个或多个命名空间）部署到三个不同的地理区域。在 Stack 中，你将使用一个组件来引用用于部署 Kubernetes 集群的模块，另一个组件用于在其中创建命名空间的模块。为了在三个地理区域重复此 Kubernetes 集群，你只需为每个地理区域定义一个部署，并为每个部署传入适当的输入，例如区域标识符。

如果你决定向每个 Kubernetes 集群添加一个新的命名空间，它将导致计划在所有三个地理区域排队。要在将更改传播到多个地理区域之前测试此更改，你可以先将命名空间添加到美国区域。在验证一切按预期工作后，接下来你可以批准欧洲区域的更改。你可以选择稍后保存亚洲区域的计划。Stack 中未在一个或多个部署中应用的更改不会阻止这些更改被计划。

观看此视频了解如何在 Terraform Stacks 中部署 Kubernetes 集群：[链接到视频]。

» 统一的 CLI 体验

开发人员可以直接从命令行创建、管理和迭代 Terraform Stacks，而无需连接 VCS。这简化了本地开发，允许工程师在使用 Stacks 进行快速实验（初始化新堆栈、创建启动配置文件、验证设置以及将源包上传到堆栈）后，再将它们集成到标准工作流程中。

对于平台团队来说，CLI 为你提供了对部署的更大控制权。你可以为 Stack 中的部分或所有部署触发计划和应用操作，从而允许你将 Terraform Stacks 集成到 CI/CD 管道中，同时仍将 VCS 用作你的真相来源。截至 GA，独立的 terraform-stacks-cli 已合并到主 Terraform CLI 中，将 Stacks 开发工作流与 Terraform 的其余部分统一起来。要了解更多关于新的 terraform stacks 命令的信息，请参阅 Terraform CLI 文档。

» 链接的 Stacks

管理大规模基础设施通常需要将基础组件（如网络、身份或着陆区）分离到它们自己的 Stacks 中。为了支持这类架构，链接的 Stacks 提供了一种直接在配置中定义和管理跨堆栈依赖关系的方法。此功能通过在上游更改被检测到时自动触发下游堆栈的更新，简化了信息流。

链接的 Stacks 有助于保持关注点分离，同时保持依赖基础设施的一致更新。这降低了复杂性和手动开销，使团队能够构建更模块化、可扩展和自动化的基础设施。

要深入了解链接的 Stacks 和其他近期增强功能，请查看我们的博客文章：HCP Terraform 新功能：链接的 Stacks、增强的标签和模块生命周期管理 GA 和我们的文档：将数据从一个 Stack 传递到另一个。

» 自托管 HCP Terraform 代理

某些基础设施必须在严格受控的环境中管理，其中安全性、合规性或网络约束要求所有 Terraform 操作都在私有网络中运行。

为了支持这些用例，Stacks 包含完整的自托管代理支持。这种支持对于需要在生产环境中跨 Stacks 使用、且网络隔离和监管约束不容妥协的企业团队特别有用。自托管代理支持能够实现：

  • 在防火墙后或在气隙环境中执行 Stack 部署
  • 符合内部合规性和审计要求
  • 为混合和本地基础设施用例提供更大的灵活性

客户还可以将代理池范围限定到特定的 Stacks，调整执行设置，以便计划和应用操作安全地在他们自己的基础设施内运行。

总体而言，Stacks 与 HCP Terraform 中已使用的执行模型保持一致，允许组织控制如何以及在何处应用敏感的基础设施更改。

» 扩展的 VCS 支持

Stacks 支持与所有主要 VCS 提供商（包括 GitHub、GitLab、Azure DevOps 服务和 Bitbucket）进行安全的企业级集成。此功能包括 VCS 连接的 IP 允许列表支持，因此客户可以确保他们的版本控制系统仅可从受信任的 HCP Terraform IP 地址访问。

» 私有注册表中的 Stack 组件配置 (GA)

在构建大规模的 Terraform Stacks 时，用户需要一种超越单个模块的集中化和标准化方式来共享基础设施最佳实践。这就是私有注册表的价值所在。它是存储组织自定义、已批准的 Terraform 模块和提供程序的中心位置。

私有注册表也可以存放已批准的 Terraform Stack 组件配置。这些配置代表了 Stack 定义中最可重用的方面，允许平台工程师发布版本化、复合的配置，其中一个组件的输出成为另一个组件的输入。

请注意，私有注册表仅存储组件配置，该配置定义了可重用模式本身，不包括部署配置中的部署特定细节。这种清晰的分离通过让应用程序开发人员以最少的精力从注册表中可靠地获取和部署这些复杂、合规的模式，从而加快了开发速度。

要了解更多关于如何编写和发布 Stack 组件配置的信息，请查看发布组件配置文档。

» RUM 可见性

你 Stacks 中的资源，以及 Stacks 和工作区的组合视图，都在 Terraform 的“使用情况”选项卡中可用。在那里，你可以查看两个关键的 Stacks 数据点：

  • 计费 Stacks 资源：显示你 Stacks 中的所有资源
  • 计费托管资源：结合 Stacks 和工作区资源，提供完整的基础设施使用情况视图

这确保了 Stacks 在你的 RUM 可见性仪表板中不是一个黑盒。

» 如何将现有的工作区迁移到 Terraform Stacks？

将现有的 Terraform 工作负载从工作区迁移到 Stacks 可能很复杂。一个关键的挑战是缺乏明确、自动化的路径来迁移现有的 Terraform 工作负载，同时保持状态完整性并最大限度地减少中断。

为了解决这个问题，现有的 Terraform 迁移工具包含了一个工作区到 Stacks 的迁移工作流（截至 2025 年 12 月处于测试阶段），该工作流支持 CLI 驱动的迁移，并自动化了过渡的关键步骤，包括：

  • 从现有工作区提取配置。
  • 生成反映工作区设置的有效 Stack 配置。
  • 将 Terraform 状态传输到新的 Stack 部署。
  • 创建并初始化新的 Stack。

通过自动化先前的手动流程，减少了操作开销，并且可以以最少的中断快速利用 Stacks 的可扩展性和组织优势。

该工作流也支持安全测试，允许用户执行试运行和验证结果，而不会影响现有的工作区，确保平稳且自信的迁移体验。

要了解更多信息，请查看工作区到 Stacks 迁移文档和教程。

» 开始使用 Terraform Stacks

Terraform Stacks 在所有基于资源管理量 (RUM) 的 HCP Terraform 计划中可用。Stacks 已准备好投入生产，并具有向后兼容的 API，因此你可以安全地将它们以及 Terraform Enterprise CLI 集成到你的 CI/CD 管道中。

你可以与现有的工作区一起逐步采用 Stacks，同时利用为大规模、多团队环境构建的功能。要了解当前支持的功能，你可以参考 HashiCorp Developer 上提供的文档和教程来帮助你入门。

我们很高兴看到 Stacks 如何帮助团队简化操作、改善协作，并充满信心地扩展基础设施管理。

comments powered by Disqus
© 2020 - 2026 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次