Terraform 核心概念回顾
在进入模块化设计与 CI/CD 服务目录之前，必须牢固掌握 Terraform 的三大核心抽象：Provider、Resource 与 Data Source。这三者构成了所有基础设施即代码（IaC）声明的基础单元。同时，状态文件管理与标准工作流是确保环境可复现、可审计的关键机制。
Provider、Resource、Data Source
Terraform 通过 Provider 与外部 API 交互，每个 Provider 提供一组 Resource 和 Data Source。Resource 负责创建、更新、删除基础设施对象；Data Source 则用于查询现有基础设施的只读信息，供其他配置引用。
| 概念 | 作用 | 声明方式 | 典型示例 |
|---|---|---|---|
| Provider | 定义与目标平台（云、SaaS、本地）的连接 | provider "aws" { region = "us-east-1" } |
AWS、Azure、GCP、Kubernetes |
| Resource | 管理基础设施对象的生命周期（CRUD） | resource "aws_instance" "web" { ... } |
虚拟机、VPC、安全组、DNS 记录 |
| Data Source | 查询现有资源的只读属性 | data "aws_ami" "ubuntu" { ... } |
AMI ID、子网列表、K8s 集群信息 |
关键区别： Resource 会创建真实对象并产生状态变更；Data Source 仅在 plan/apply 时读取数据，不会修改任何基础设施。在服务目录环境中，Data Source 常用于获取共享 VPC、基线 AMI 或合规策略 ID。
状态文件管理
Terraform 状态文件（terraform.tfstate）是基础设施的实时映射。它记录了每个 Resource 的属性和元数据，是 Terraform 判断“当前状态”与“期望状态”差异的唯一依据。
- 本地状态：默认存储在项目目录，适合个人实验，不适用于团队协作。
- 远程状态：推荐用于生产环境，将状态文件存储在 S3、Azure Storage、GCS 或 Terraform Cloud 等后端，支持状态锁定与版本历史。
- 状态锁定：防止并发执行导致状态损坏，DynamoDB（AWS）或 CosmosDB（Azure）常作为锁表。
安全警告： 状态文件可能包含明文密码、密钥或连接字符串。切勿将
.tfstate 提交到版本控制。始终启用远程后端的加密传输与静态加密。
Terraform 工作流：init / plan / apply / destroy
Terraform 采用声明式工作流，四个核心命令构成了基础设施的完整生命周期。在 CI/CD 服务目录环境中，每个命令对应流水线中的一个独立阶段。
| 命令 | 阶段 | 作用 | CI/CD 中的典型用途 |
|---|---|---|---|
terraform init |
初始化 | 下载 Provider 插件、初始化后端、加载模块 | 流水线启动时执行，确保环境一致 |
terraform plan |
计划 | 对比状态文件与配置，生成执行计划 | Pull Request 触发，人工审核变更 |
terraform apply |
应用 | 执行计划中的变更，创建/更新/删除资源 | 合并到主分支后自动执行 |
terraform destroy |
销毁 | 删除所有被管理的资源 | 环境回收、临时分支清理 |
工作流最佳实践： 在服务目录场景中，
plan 阶段应输出可读的变更摘要并自动评论到 PR 中；apply 阶段必须使用 -auto-approve 标志实现无人值守执行；destroy 仅用于临时环境，生产环境禁止自动销毁。
# 标准 Terraform 工作流示例
# 1. 初始化
terraform init
# 2. 生成执行计划
terraform plan -out=tfplan
# 3. 应用计划（生产环境建议人工审核后执行）
terraform apply tfplan
# 4. 销毁资源（仅限临时环境）
terraform destroy -auto-approve理解 Provider、Resource、Data Source 的声明式关系，掌握状态文件的安全管理策略，并熟练运用 init/plan/apply/destroy 工作流，是后续构建模块化服务目录的基石。下一层我们将把这些概念应用到多环境、多团队的 CI/CD 流水线设计中。