Sean O’Dell 2022-04-20
HashiCorp 的开源工具 Terraform 在很多方面都是基础设施即代码（Infrastructure-as-Code，IaC）领域的首选工具，用于学习、配置和维护云基础设施。
我个人与 Terraform 的旅程始于多年前，如今资源创建几乎已成为一种本能。但达到这一阶段离不开官方文档、活跃的社区以及出色的合作伙伴网络的支持。创建基础设施只是 DevOps 方程中的一部分，但由于其简单性，事情反而变得有些棘手。在规模化运行时，我们遇到了诸多挑战，包括部署的复杂性、内部与外部依赖关系、内建安全机制以及可维护性等问题。
本文将带你踏上这段旅程，并介绍一些在规模化使用 Terraform 时的最佳实践和解决方案。
本地构建
仅使用 Terraform 二进制文件并拥有目标云服务商的访问权限，你就可以在本地计算机上直接操作资源，而代码库也位于同一台机器上。这种方式使得日常的 Terraform 操作（如状态管理、导入、移动等）更加便捷。当你与团队成员协作时，也可以使用远程状态存储和状态锁定功能。如果你使用版本控制系统但没有持续集成（CI），可以借助 pre-commit-terraform 工具，在提交代码前自动运行一系列代码检查（linting）工具。
尽管本地开发非常方便，但过多的手动流程容易出错且浪费时间。想象一下多个开发者同时处理同一个流程的场景。几年前我就亲身经历过这种情况：当时我所在的团队正在 AWS 上构建基础设施和资源。我们不得不等待每个 Pull Request 合并后再重新基于最新代码进行变更，或者干脆放弃团队协作开发基础设施代码。当时的工具链导致我们只能指定一个人全权负责基础设施的创建和部署——那个人就是我！为 Terraform 模块编写单元测试是一种最佳实践，但如果每次代码变更都需要手动运行测试，就会非常耗时。相信我，我经常跳过这一步。
本地开发还存在安全方面的隐患。即使使用了像 Vault 这样的外部解决方案，状态文件仍然可能被访问，一个简单的 terraform state pull 命令就可能导致灾难性后果。还有一次，一位同事在本地编写了一些 IaC 代码，但无法将其上传到我们的 GitHub 组织仓库。出于好意，我主动提出帮他创建仓库并上传代码。不幸的是，我并不知道代码中硬编码了 AWS 的访问密钥和安全凭证。最终，我把同事的敏感数据上传到了一个公开仓库，只能自己承担后果。
构建自己的 CI/CD 流水线
旅程的下一步是将 Terraform 代码集成到你现有的（有时甚至是遗留的）持续集成与持续部署（CI/CD）工具中。通过 CI/CD，可以避免前面提到的特权访问问题，因为访问权限只需在执行层配置即可。
同时，开发人员仅需拥有只读权限。CI/CD 流水线会生成系统日志，可用于追踪每次运行的变更记录。还可以配置 Pull Request 的状态检查，以自动运行代码检查、合规性验证和单元测试。
然而，并发运行的 CI/CD 流水线可能会引发竞态条件（race conditions），导致部分流水线失败。例如，当两个 Pull Request 几乎同时合并时，会触发多个流水线并行执行。如果代码库启用了状态锁定（这是一项关键的最佳实践），第一个 Pull Request 会锁定状态文件，导致其他同时触发的流水线因无法获取锁而失败。
这个问题可以通过配置“排队运行”（queued runs）来解决，但在大多数 CI/CD 工具中实现起来颇具挑战。要构建一个功能完备的 CI/CD 流水线以支持成功的集成与部署，我们还需要考虑单元测试、模块共享以及定期漂移检测（drift detection）等问题。
正如我之前提到的，我和我的团队就曾亲身经历过上述情况。你甚至可以在 YouTube 上找到我们录制的视频，详细展示了从基础设施到应用程序的完整流程——所有内容都通过单一的流水线实现。这种方案在演示时效果很好，但若要投入生产运营，则会极其困难。尽管自定义一个属于你自己的“弗兰肯斯坦式”CI/CD 系统看似诱人，但在走上这条路之前，请务必三思而后行。
使用开源工具
有许多开源工具可以帮助实现 Terraform 自动化。为此甚至诞生了一个全新的工具类别，称为 TACOS（Terraform Automation and Collaboration Software，Terraform 自动化与协作软件）。当规模成为关注重点时，这些工具可以为 Terraform 基础设施增添额外功能。
例如，Atlantis 是最常见或最受欢迎的与 Terraform 配合使用的开源工具之一，用于增强自动化和协作能力。它是一个开源工具，使开发者能够更轻松地管理任务和操作。
其他流行的选项还包括 Terratest、Terraformer 和 Terragrunt。根据你的具体需求，市面上还有大量开源的 Terraform 项目可供选择。
虽然我热爱开源并持续为其倡导，但有时这些工具只能填补旅程中的部分空白，而托管型解决方案很快便应运而生。
使用托管解决方案
Terraform Cloud
首个进入市场的托管解决方案由 Terraform 的创建者和维护者 HashiCorp 开发并发布。由于其官方背景，新开发的 Terraform 功能通常会首先或同步在 Terraform Cloud 中实现。借助 Sentinel 等高级安全合规机制，Terraform Cloud 能够在代码部署前强制执行组织标准。
Terraform Cloud 提供的远程执行后端非常高效：你可以在本地计算机上编写 Terraform 代码，上传后直接在云端运行 plan 操作，从而轻松验证配置是否有效。
Spacelift
Spacelift 在 Terraform 支持和部署执行方面与 Terraform Cloud 几乎功能相当。你可以将 Spacelift 与 Terraform Cloud 进行比较。
在合规性方面，Spacelift 具有一定优势，部分原因在于其对 Open Policy Agent（OPA）的依赖。OPA 是一个统一的开源工具集和框架，用于在整个云原生技术栈中实施策略。如今，OPA 已成为市场上众多安全解决方案的基础。Spacelift 选择 OPA 作为其策略引擎，不仅能在解决方案内部提供策略控制，还能与众多专注于安全与合规最佳实践的厂商实现集成。
结语
你究竟该从哪里开始呢？第一步是理解你所在组织的最佳实践和技术需求。每个组织都不同——起点各异，运作原则和实践方式也各不相同，以确保 DevOps 的成功。在经历了数年的实践并与业内同行交流后，我认识到：从成本效益和人性化角度出发，采用 Terraform Cloud 或 Spacelift 这类平台来提供必要的功能、实现基础设施即代码的规模化，才是更理想的选择。这样，我们就能把更多时间留给家人、爱好，以及投身于自己钟爱的非营利组织，而不是整日为云资源的管理而忧心忡忡。