学习 Terraform 的初学者最常犯的错误之一，就是将本地机器当作部署服务器。

典型的工作流程如下：

terraform init
terraform plan
terraform apply

Enter fullscreen mode Exit fullscreen mode

这种做法在学习阶段完全可以接受，但当你在真实项目中与多位工程师协作时，很快就会成为问题。

考虑以下问题：

  • 是谁部署的基础设施？
  • 部署前是否经过审查？
  • 其他人能否复现部署？
  • 如果工程师的笔记本丢失或配置错误会怎样？
  • 我们如何确切知道发生了哪些更改？

这些正是为什么在专业环境中，基础设施即代码（IaC）几乎总是与持续集成和持续部署（CI/CD）流水线结合使用。

在这篇文章中，我们将使用 GitHub Actions 构建一个简单的 Terraform CI/CD 流水线。我们不仅关注 YAML 语法，还会先理解为什么每个阶段都存在，以及它们如何协同工作以实现安全、可重复的基础设施部署。

什么是 Terraform CI/CD？

Terraform CI/CD 是指每当 Terraform 代码发生变更时，自动执行基础设施验证、计划和部署的过程。

不再由开发者从笔记本手动运行 Terraform 命令，而是由 CI/CD 平台在受控环境中自动执行这些命令。

典型的工作流程如下：

Developer
      │
      ▼
Git Push
      │
      ▼
GitHub Repository
      │
      ▼
GitHub Actions
      │
      ▼
Terraform Init
      │
      ▼
Terraform Validate
      │
      ▼
Terraform Plan
      │
      ▼
Manual Approval
      │
      ▼
Terraform Apply
      │
      ▼
AWS Infrastructure

Enter fullscreen mode Exit fullscreen mode

这种方法提供了更好的一致性、可视性和安全性，同时降低了人为错误的风险。

为什么不手动运行 Terraform？

从笔记本运行 Terraform 对于个人项目来说没问题，但在团队环境中会引入多种风险。

手动部署 CI/CD 部署
需要有人记住所有命令 自动运行
容易跳过验证 强制执行验证
难以追踪部署记录 每次部署都有日志
凭证存储在开发者笔记本上 凭证安全存储
不同机器上 Terraform 版本不一致 一致的执行环境

自动化让每次基础设施变更都遵循相同的流程，无论是谁发起的变更。

我们将构建什么

我们的目标是创建两个独立的 GitHub Actions 工作流：

工作流 1 – 持续集成 (CI)

此工作流通过运行以下命令检查 Terraform 代码质量：

  • terraform fmt
  • terraform init
  • terraform validate
  • terraform plan

注意，此工作流不会创建任何基础设施。

它的职责只是告诉我们提议的变更是否安全且有效。

工作流 2 – 部署

部署工作流负责创建或更新基础设施。

它只在我们确认 Terraform 计划可接受后才会运行。

这种分离是一项重要的最佳实践，因为审查基础设施变更与审查应用代码同样重要。

项目结构

我们的仓库结构如下：

terraform-github-actions/
│
├── .github/
│   └── workflows/
│       ├── terraform-ci.yml
│       └── terraform-deploy.yml
│
├── main.tf
├── variables.tf
├── outputs.tf

Enter fullscreen mode Exit fullscreen mode

将 CI 和部署工作流分开，使它们更易于理解、维护和扩展。

理解 CI 流水线

CI 工作流负责回答一个问题：

“这段 Terraform 代码是否已准备好部署？”

为回答该问题，它会执行多项检查。

步骤 1：检查格式

Terraform 强制使用一致的编码风格。

运行：

terraform fmt -check

Enter fullscreen mode Exit fullscreen mode

有助于确保每位贡献者遵循相同的格式标准。

步骤 2：初始化 Terraform

在 Terraform 验证或计划基础设施之前，必须先下载所需的 provider 并初始化工作目录。

这通过以下命令完成：

terraform init

Enter fullscreen mode Exit fullscreen mode

步骤 3：验证配置

接下来，Terraform 会验证配置在语法上是否正确。

terraform validate

Enter fullscreen mode Exit fullscreen mode

这可以在部署前捕获缺失参数、无效引用及其他配置问题。

步骤 4：生成执行计划

最后，Terraform 会生成执行计划。

terraform plan

Enter fullscreen mode Exit fullscreen mode

该计划显示 Terraform 打算执行的操作，但不会实际做出任何更改。

例如：

  • 将要创建的资源
  • 将要更新的资源
  • 将要销毁的资源

审查此输出是基础设施即代码工作流中最重要的一环。

将 CI 与部署分离

学生常问的一个问题是：

“如果 CI 工作流已经运行了 terraform plan，为什么还需要另一个部署工作流？”

答案很简单。

CI 工作流用于验证基础设施。

部署工作流用于更改基础设施。

将这两个职责分离，能让团队更好地控制部署时机。

典型流程如下：

Push Code
     │
     ▼
CI Pipeline
     │
     ▼
Plan Generated
     │
     ▼
Engineer Reviews Changes
     │
     ▼
Deployment Triggered
     │
     ▼
Terraform Apply

Enter fullscreen mode Exit fullscreen mode

这种方法可以防止意外部署，并鼓励进行适当的变更审查。

安全管理 AWS 凭证

初学者常犯的一个错误是将 AWS 凭证硬编码在 Terraform 代码或 GitHub 工作流中。

切勿这样做。

相反，GitHub 提供了加密的仓库密钥，可在工作流执行期间安全访问。

这能确保敏感信息不会出现在源代码和版本历史中。

在后续文章中，我们将更进一步，使用 GitHub 的 OpenID Connect (OIDC) 集成替换长期 AWS 访问密钥，从而完全消除存储 AWS 凭证的需求。

接下来

在本篇文章中，我们探讨了 Terraform CI/CD 的概念，以及为什么将验证与部署分离能带来更安全的基础设施自动化。

在下一篇文章中，我们将从零开始构建第一个 GitHub Actions 工作流，逐行理解 YAML 文件，并为 AWS 项目实现 Terraform 验证和计划的自动化。

在本系列结束时，我们将拥有一个生产就绪的流水线，能够使用 GitHub Actions 和 Terraform 安全地部署基础设施。

总结

学习 Terraform 不仅仅是编写 .tf 文件。

专业的基础设施即代码建立在可重复的流程、代码审查、安全的凭证管理以及自动化部署之上。

GitHub Actions 为我们提供了实现这些实践的工具，而 Terraform 则为以代码描述基础设施提供了基础。

两者结合，使团队能够构建可靠、可扩展且可审计的云基础设施。

如果你刚开始 DevOps 之旅，掌握此工作流将是你能做的最值得的投资。

你可以在我的 GitHub 仓库中找到本文使用的完整示例：

github repo