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

2. Terraform 基础回顾：安装、Provider 配置、资源声明与状态管理

在深入高可用熔断限流自动化部署之前，必须夯实 Terraform 的核心基础。本章将系统回顾 Terraform 的安装方式、Provider 配置、资源声明语法以及状态文件管理机制，为后续的复杂架构编排打下坚实基础。

2.1 Terraform 安装与环境准备

Terraform 采用单一二进制分发，支持主流操作系统。推荐使用版本管理器 tfenv 或直接下载官方二进制包。

操作系统	安装方式	命令/步骤
macOS	Homebrew	`brew install terraform`
Linux (Ubuntu/Debian)	apt + HashiCorp 仓库	`curl -fsSL https://apt.releases.hashicorp.com/gpg \| sudo apt-key add -` `sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"` `sudo apt-get update && sudo apt-get install terraform`
Windows	Chocolatey	`choco install terraform`
跨平台	tfenv (版本管理)	`git clone https://github.com/tfutils/tfenv.git ~/.tfenv` `echo 'export PATH="$HOME/.tfenv/bin:$PATH"' >> ~/.bashrc` `tfenv install 1.6.6`

版本选择建议：生产环境建议锁定 Terraform 版本 ≥ 1.5.x，以利用 import 块和 check 块等新特性。使用 terraform version 验证安装。

2.2 Provider 配置：连接基础设施的桥梁

Provider 是 Terraform 与目标平台（AWS、Azure、阿里云、Kubernetes 等）交互的插件。每个 Provider 负责定义资源类型和 API 调用逻辑。

2.2.1 Provider 声明语法

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    alicloud = {
      source  = "aliyun/alicloud"
      version = "~> 1.209.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.23"
    }
  }
}

provider "alicloud" {
  region = var.region
  # 优先使用环境变量 ALICLOUD_ACCESS_KEY / ALICLOUD_SECRET_KEY
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

  关键点：
  source 格式为 [registry.namespace]/[provider-type]，默认从 Terraform Registry 拉取。
version 约束使用 ~> x.y.z 允许补丁版本升级，避免大版本意外变更。
Provider 的认证凭据优先通过环境变量注入，避免硬编码在 .tf 文件中。

2.2.2 Provider 初始化流程

terraform init：下载 Provider 插件到 .terraform/ 目录，生成锁定文件 .terraform.lock.hcl。
terraform providers：查看当前配置中所有 Provider 及其版本约束。
terraform providers lock：在 CI/CD 环境中预生成锁定文件，确保一致性。

2.3 资源声明：定义基础设施的原子单元

资源（Resource）是 Terraform 中最核心的配置块，代表一个基础设施对象，例如一台 ECS 实例、一个 SLB 监听、一个 Kubernetes Deployment。

2.3.1 资源块语法

resource "alicloud_slb" "ha_lb" {
  load_balancer_name = "ha-meltdown-lb"
  address_type       = "intranet"
  load_balancer_spec = "slb.s2.small"
  master_zone_id     = "cn-hangzhou-g"
  slave_zone_id      = "cn-hangzhou-h"

  tags = {
    Environment = "production"
    Component   = "gateway"
  }
}

resource "kubernetes_deployment" "rate_limiter" {
  metadata {
    name      = "rate-limiter"
    namespace = "meltdown-system"
  }

  spec {
    replicas = 3

    selector {
      match_labels = {
        app = "rate-limiter"
      }
    }

    template {
      metadata {
        labels = {
          app = "rate-limiter"
        }
      }

      spec {
        container {
          image = "registry.example.com/rate-limiter:v2.1.0"
          name  = "rate-limiter"
          port {
            container_port = 8080
          }
        }
      }
    }
  }
}

2.3.2 资源声明最佳实践

命名规范：资源名称（第二个参数）使用小写字母和下划线，体现业务语义，如 public_alb、redis_cache。
依赖隐式表达：Terraform 通过表达式引用自动构建依赖图，无需显式 depends_on（仅在特殊循环依赖时使用）。
count 与 for_each：使用 count 创建固定数量的同类资源；使用 for_each 从 map 或 set 创建差异化资源。

常见陷阱：不要在资源块内硬编码敏感信息（密码、密钥）。使用 variable 结合 sensitive = true 或引用 Vault/Secrets Manager 数据源。

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

Terraform 状态文件（terraform.tfstate）记录了已管理资源的元数据、属性值和依赖关系。它是 Terraform 判断“当前状态”与“期望状态”差异的唯一依据。

2.4.1 状态文件的核心作用

作用	说明
映射绑定	将 `.tf` 文件中的资源声明与云平台上的真实资源 ID 关联
性能优化	避免每次 `plan` 都全量调用云 API 列举所有资源
依赖解析	存储资源属性的输出值，供其他资源引用（如 `alicloud_slb.ha_lb.id`）
协同锁定	远程状态后端（如 OSS、Consul）支持状态锁定，防止并发冲突

2.4.2 远程状态后端配置

生产环境必须使用远程状态存储，避免本地文件丢失或团队协作冲突。

terraform {
  backend "oss" {
    bucket         = "terraform-state-prod"
    prefix         = "meltdown-system/"
    key            = "ha-infra.tfstate"
    region         = "cn-hangzhou"
    encrypt        = true
    acl            = "private"
  }
}

  状态管理黄金法则：
  永远不要手动编辑 .tfstate 文件。
使用 terraform state list 查看状态中的资源列表。
使用 terraform state rm 从状态中移除资源（不销毁实际资源）。
使用 terraform import 将已有资源纳入 Terraform 管理。

2.5 本章小结

安装：推荐使用 tfenv 管理多版本，生产环境锁定 ≥ 1.5.x。
Provider：每个 Provider 对应一个云平台，通过 required_providers 声明版本，terraform init 完成下载。
资源声明：使用 resource 块定义基础设施对象，通过表达式引用实现隐式依赖。
状态文件：必须使用远程后端（OSS/S3/Consul）存储，启用状态锁定，禁止手动编辑。