📚 课程目录第2章 Terraform基础回顾

2. Terraform 基础回顾：核心概念快速复习

在深入 CI/CD 集成之前，必须重新校准 Terraform 的四个核心支柱：Provider、Resource、State 与 Module。它们是所有自动化发布健康度的底层保障。以下从概念、配置示例到协作要点进行快速复习。

2.1 Provider：基础设施的 API 桥接器

Provider 是 Terraform 与目标平台之间的协议适配层。每个 Provider 封装了对应平台（AWS、Azure、GCP、Kubernetes 等）的 API 调用逻辑与资源生命周期。

属性	说明	典型配置
来源	官方或社区维护，通过 registry.terraform.io 分发	`hashicorp/aws`
版本约束	使用 `required_providers` 锁定大版本	`version = "~> 5.0"`
认证	环境变量 / 配置文件 / IAM 角色	`AWS_ACCESS_KEY_ID`
别名	同一 Provider 多区域/多账号时使用 `alias`	`provider "aws" { alias = "us-east" }`

# 标准 Provider 声明块
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

CI/CD 集成要点：Provider 版本应在 terraform.lock.hcl 中锁定，避免流水线因 Provider 小版本升级导致非预期资源变更。

2.2 Resource：基础设施的声明式单元

Resource 是 Terraform 中最基本的构建块，描述“要什么”而非“怎么做”。每个 Resource 对应一个具体的云对象（如虚拟机、子网、DNS 记录）。

# 声明一个 AWS EC2 实例
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "WebServer"
  }
}

资源地址：aws_instance.web_server，用于跨资源引用（aws_instance.web_server.id）
参数与属性：输入参数（ami）与只读属性（id、public_ip）
依赖关系：隐式依赖（通过引用自动推导）与显式依赖（depends_on）
生命周期：create_before_destroy、prevent_destroy 等元参数控制发布策略

  发布健康度关键：Resource 的 prevent_destroy = true 可保护关键数据库或存储卷不被流水线误删；create_before_destroy 用于零停机发布。

2.3 State：基础设施的真实来源

State 文件（terraform.tfstate）是 Terraform 的核心数据存储，记录所有已管理资源的当前状态、元数据与依赖关系。它是 Terraform 判断“创建/更新/删除”的唯一依据。

State 特性	说明	CI/CD 注意事项
本地 vs 远程	本地文件仅适合单机实验；远程 State 是团队协作基础	流水线必须使用远程 State（S3 + DynamoDB / Terraform Cloud）
状态锁定	防止并发执行导致状态损坏	DynamoDB 或 Terraform Cloud 提供锁定机制
敏感数据	State 可能包含密码、密钥等明文	启用 State 加密（如 S3 SSE）并限制访问权限
状态迁移	`terraform state mv` / `rm` 用于重构	避免在流水线中直接操作 State，应通过 PR 评审

# 远程 State 配置示例（S3 + DynamoDB）
terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

常见陷阱：不要在流水线中直接使用 terraform apply -auto-approve 操作本地 State。多人协作时，本地 State 会导致状态漂移和资源冲突。始终使用远程后端。

2.4 Module：可复用的基础设施封装

Module 是 Terraform 实现代码复用与抽象的核心机制。一个 Module 可以包含多个 Resource、Provider 配置、变量与输出，形成标准化的基础设施组件。

# 调用社区或内部 Module
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["ap-northeast-1a", "ap-northeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = false
}

来源类型：本地路径（./modules/vpc）、Git 仓库（git::https://...）、Terraform Registry
版本管理：Registry 模块使用 version 约束；Git 模块使用 ref 参数锁定 tag/commit
输入输出：variable 定义输入，output 暴露结果供根模块使用
模块树：根模块 → 子模块 → 嵌套模块，形成层级化基础设施代码

CI/CD 集成建议：将共享 Module 存放在独立 Git 仓库，通过 ref = "v1.2.0" 或 version = "~> 1.2" 锁定版本。流水线中只引用已发布的 Module 版本，避免直接引用 main 分支。

2.5 四者协作：一次完整的 Terraform 执行流程

初始化：terraform init 下载 Provider 插件与 Module 源码
验证：terraform validate 检查语法与内部引用
计划：terraform plan 对比 State 与配置，生成变更计划
应用：terraform apply 调用 Provider API 执行变更，并更新 State
销毁：terraform destroy 按依赖顺序删除所有 Resource

在 CI/CD 流水线中，Plan 阶段是发布健康度的核心检查点——通过解析 Plan 输出，可以自动检测非预期的资源增删改，从而阻断风险变更。