2. Terraform 核心概念：Provider、Resource、Data Source、State、Plan、Apply、Destroy

Terraform 的核心工作流围绕七个关键概念展开。理解这些概念是构建可靠基础设施即代码（IaC）管线的基石。本章将逐一拆解每个概念的角色、交互方式及在 CI/CD 自助服务中的实际意义。

2.1 概念总览与关系图

下图展示了 Terraform 核心组件之间的数据流与生命周期关系。Provider 作为桥梁连接目标平台，Resource 和 Data Source 是声明式配置的实体，State 文件作为真实世界的映射，而 Plan / Apply / Destroy 构成操作循环。

2.2 Provider：基础设施的桥梁

Provider 是 Terraform 与目标平台（云服务商、Kubernetes、数据库等）交互的插件。每个 Provider 负责理解对应平台的 API，并将 Terraform 的通用声明转换为平台特定的 API 调用。

Provider 名称	典型用途	认证方式
hashicorp/aws	管理 EC2、S3、VPC、RDS 等 AWS 资源	环境变量 / 共享凭证文件 / IAM 角色
hashicorp/azurerm	管理 Azure 虚拟机、存储、网络	Azure CLI / 服务主体 / 托管标识
hashicorp/google	管理 GCP Compute Engine、GKE、Cloud Storage	服务账号 JSON 密钥 / 默认凭据
hashicorp/kubernetes	管理 K8s 命名空间、Deployment、Service	kubeconfig 文件 / 集群内配置

# Provider 声明示例
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

2.3 Resource：基础设施的构建块

Resource 是 Terraform 中最核心的声明单元。每个 Resource 块对应一个真实的基础设施对象，例如一台虚拟机、一个 DNS 记录或一个数据库实例。Resource 的语法结构决定了资源的类型、名称和配置参数。

# Resource 定义示例：创建 AWS EC2 实例
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name        = "WebServer"
    Environment = "production"
  }
}

Resource 块的关键属性：

• 资源类型（aws_instance）：由 Provider 定义，决定资源的行为。
• 资源名称（web_server）：Terraform 模块内的唯一标识符，用于引用和依赖管理。
• 配置参数：特定于资源类型的属性，如 AMI ID、实例类型、标签等。
• 元参数：count、for_each、depends_on、lifecycle 等，控制资源的行为模式。

2.4 Data Source：读取外部信息

Data Source 允许 Terraform 读取由外部或 Terraform 之外创建的资源信息。它不会创建或修改资源，仅用于查询现有基础设施的状态，并将结果暴露给配置中的其他部分使用。

# Data Source 示例：查询现有 VPC
data "aws_vpc" "default" {
  default = true
}

# 在 Resource 中引用 Data Source
resource "aws_security_group" "web_sg" {
  name   = "web-sg"
  vpc_id = data.aws_vpc.default.id
}

2.5 State：基础设施的真实映射

State 文件（terraform.tfstate）是 Terraform 的核心状态存储。它记录了所有被管理资源的元数据、属性值和依赖关系。State 是 Terraform 能够进行增量更新和资源协调的基础。

State 特性	说明	CI/CD 影响
资源映射	将配置中的资源名称映射到真实资源 ID	确保多次 Apply 不会重复创建资源
依赖图	记录资源创建/销毁的顺序依赖	并行执行时保证操作顺序正确
性能优化	缓存已查询的属性值，减少 API 调用	加速 Plan 和 Apply 的执行
敏感数据	可能包含密码、密钥等明文信息	必须使用远程后端加密存储

2.6 Plan：预览变更

terraform plan 命令读取配置文件并与当前 State 进行对比，生成一份详细的执行计划。计划中会列出所有将要创建、更新或销毁的资源，以及变更的属性差异。

# 执行 Plan 命令
terraform plan -out=tfplan

# 输出示例（简化）
Plan: 1 to add, 0 to change, 0 to destroy.

Changes:
  # aws_instance.web_server will be created
  + resource "aws_instance" "web_server" {
      + ami           = "ami-0c55b159cbfafe1f0"
      + instance_type = "t3.micro"
      + tags          = {
          + "Name" = "WebServer"
        }
    }

Plan 在 CI/CD 自助服务中的核心价值：

• 安全审查：在 Apply 之前，团队成员可以审查计划，确认变更符合预期。
• 成本控制：通过计划中的资源类型和数量，预估基础设施成本变化。
• 自动化门禁：在 Merge Request 中自动生成 Plan 注释，作为审批流程的一部分。

2.7 Apply：执行变更

terraform apply 命令执行由 Plan 生成的变更。它会按依赖顺序创建、更新或删除资源，并在操作完成后更新 State 文件。

# 使用 Plan 文件执行 Apply
terraform apply tfplan

# 直接 Apply（不推荐生产使用）
terraform apply -auto-approve

2.8 Destroy：清理资源

terraform destroy 命令用于销毁所有由当前配置管理的资源。它会生成一个销毁计划，然后按依赖顺序逐一删除资源。

# 销毁所有资源
terraform destroy -auto-approve

# 销毁特定资源（使用 -target）
terraform destroy -target=aws_instance.web_server

Destroy 在自助服务中的典型场景：

• 临时环境清理：开发/测试环境在合并 PR 后自动销毁，节省成本。
• 资源回收：自助服务平台允许用户一键销毁不再需要的基础设施。
• 灾难恢复演练：定期销毁并重建环境，验证基础设施的可恢复性。

2.9 核心概念对比总结

概念	方向	是否修改资源	依赖 State	CI/CD 典型阶段
Provider	配置 → API	否（仅插件）	否	初始化阶段
Resource	声明 → 创建	是	是	Apply 阶段
Data Source	查询 → 读取	否	否	Plan / Apply 阶段
State	持久化存储	否（仅记录）	—	全阶段
Plan	对比 → 预览	否	是	审查阶段
Apply	执行 → 变更	是	是	部署阶段
Destroy	执行 → 删除	是	是	清理阶段

2.10 自助服务场景下的工作流示例

以下是一个典型的自助服务管线中 Terraform 核心概念如何协同工作的流程：

1. 用户提交配置：开发者在 Git 仓库中提交包含 Provider、Resource 和 Data Source 的 .tf 文件。
2. CI 触发 Plan：CI 系统运行 terraform init（下载 Provider 插件），然后执行 terraform plan，将计划输出为注释或工件。
3. 人工审批：团队负责人审查 Plan 输出，确认变更安全且符合预期。
4. CI 执行 Apply：审批通过后，CI 运行 terraform apply，创建/更新资源，并将结果写入远程 State。
5. 环境销毁：当环境不再需要时，用户触发 terraform destroy，CI 执行清理并更新 State。