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

2. Terraform 基础回顾：HCL 语法、Provider 配置、资源与数据源、状态文件管理

在深入跨云资源池编排之前，必须夯实 Terraform 的核心基础。本章将系统回顾 HCL 语法、Provider 配置、资源与数据源声明，以及状态文件管理——这些是构建任何生产级基础设施即代码（IaC）的基石。

2.1 HCL 语法核心要素

HCL（HashiCorp Configuration Language）是 Terraform 的专用配置语言，设计目标为人类可读且机器可解析。其核心语法结构包括块（Block）、参数（Argument）和表达式（Expression）。

语法元素	示例	说明
块（Block）	`resource "aws_instance" "web" { ... }`	由关键字、标签（可选）和花括号包裹的主体构成
参数（Argument）	`ami = "ami-0c55b159cbfafe1f0"`	键值对形式，赋值使用 `=`
标识符（Identifier）	`web`、`vpc_id`	资源名称、变量名等，字母/数字/下划线组成
注释	`#` 或 `//` 或 `/* */`	单行与多行注释均支持
字符串插值	`"${var.region}"`	在字符串中引用变量或表达式结果

最佳实践：始终使用 terraform fmt 命令自动格式化 HCL 代码，确保团队风格一致，避免因缩进或空格导致的解析歧义。

2.2 Provider 配置：连接云平台

Provider 是 Terraform 与目标云平台（AWS、Azure、GCP 等）交互的桥梁。每个 Provider 负责定义资源类型、API 调用逻辑和认证方式。

# 声明所需 Provider 及其版本约束
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

# 配置 AWS Provider（使用环境变量认证）
provider "aws" {
  region = "us-east-1"
}

# 配置 Azure Provider
provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
}

Provider 配置的关键点：

版本约束：使用 ~> 5.0 表示允许 5.x 系列内的最新补丁版本，避免意外升级引入破坏性变更。
多 Provider 实例：通过 alias 字段创建同一 Provider 的多个配置，用于多区域或多账号场景。
认证优先级：静态凭证 → 环境变量 → 共享凭证文件 → 云平台默认链。

安全警告：切勿将云平台密钥（Access Key / Secret Key）硬编码在 .tf 文件中。优先使用环境变量、Vault 或 CI/CD 系统的机密管理服务。

2.3 资源与数据源：声明式基础设施

资源（Resource） 是 Terraform 管理的核心对象，代表云平台上的具体组件（虚拟机、网络、存储桶等）。数据源（Data Source） 用于查询云平台已有的基础设施信息，供其他资源引用。

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

  tags = {
    Name = "WebServer-${var.environment}"
  }
}

# 数据源声明：查询现有 VPC
data "aws_vpc" "default" {
  default = true
}

# 引用数据源属性创建安全组
resource "aws_security_group" "web_sg" {
  name   = "web-sg-${var.environment}"
  vpc_id = data.aws_vpc.default.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

资源与数据源的核心差异：

特性	资源（Resource）	数据源（Data Source）
生命周期	创建、更新、删除	只读查询
状态文件影响	写入状态文件	不写入状态文件（仅缓存）
典型用途	管理新基础设施	引用已有基础设施属性
依赖关系	可被其他资源引用	可被资源引用

  跨云资源池场景：在服务目录中，数据源常用于动态获取不同云平台的可用区列表、最新镜像 ID 或现有网络拓扑，避免硬编码。

2.4 状态文件管理：基础设施的真相来源

Terraform 状态文件（terraform.tfstate）是基础设施的“真相来源”，记录了所有已管理资源与其在云平台上的实际 ID 之间的映射关系。状态文件管理直接决定团队协作和数据安全。

2.4.1 状态文件的核心作用

资源映射：将 HCL 代码中的资源逻辑名称（如 aws_instance.web_server）绑定到云平台的实际资源 ID。
性能优化：避免每次 terraform plan 都全量调用云平台 API 列举所有资源。
依赖解析：通过状态文件中的属性值计算资源间的依赖顺序。

2.4.2 远程状态存储最佳实践

生产环境必须使用远程后端（Backend）存储状态文件，避免本地文件丢失或多人覆盖。

# 使用 AWS S3 作为远程后端（推荐）
terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

后端类型	适用场景	状态锁支持
S3 + DynamoDB	AWS 原生，高可用	是（DynamoDB）
Azure Storage Account	Azure 环境	是（Blob Lease）
GCS	GCP 环境	是（Object Versioning）
Terraform Cloud	团队协作，免费额度	是（内置）

关键风险：状态文件可能包含明文敏感信息（如数据库密码、密钥对）。务必启用后端加密（encrypt = true），并限制对状态文件的访问权限。

2.4.3 状态文件操作命令

terraform state list：列出状态文件中所有资源。
terraform state show <资源地址>：查看特定资源的详细属性。
terraform state mv <源> <目标>：重命名或移动资源在状态中的位置。
terraform state rm <资源地址>：从状态中移除资源（不删除实际基础设施）。
terraform import <资源地址> <云平台ID>：将已有基础设施导入状态管理。

2.5 本章小结

HCL 语法提供了声明式的基础设施描述能力；Provider 配置建立了与云平台的认证通信；资源与数据源分别负责创建和查询基础设施；状态文件则是整个 IaC 体系的“记忆中枢”。掌握这些基础，才能进一步构建跨云资源池的 CI/CD 服务目录。