Terraform：IaC 全攻略

为什么需要 Terraform：把点按操作变成可审查的代码

传统方式下，云资源靠控制台点选或临时脚本创建：没有版本记录、没有代码评审，环境之间配置逐步漂移，账号与区域增多后人肉运维必然失守。而临时脚本是命令式流程，只描述“怎么做”不描述“变成什么样”，重复执行会产生重复资源。这个问题在微服务与 AI 算力集群规模扩大后尤其致命——几十台 GPU 节点的手工交付耗时长且不可复现。

Terraform 采用声明式思路：你在 .tf 文件中描述目标状态，工具负责“如何达成”。核心工作流是 init → plan → apply：plan 输出变更清单（新增/修改/删除），审查通过后 apply 才执行；destroy 可一键清理。幂等性保证同一份配置反复执行结果一致。terraform.tfstate 状态文件记录真实资源与配置的映射关系，是后续 diff 和增量变更的依据。

与 Ansible（面向配置变更、无状态）和 Pulumi（用通用编程语言）相比，Terraform 用专门 DSL 把“基础设施拓扑”本身做成可版本化、可 diff、可协作的产物。它的 Provider 生态横跨 3000+ 平台，多云覆盖广度在同类工具中最大，这也是它成为 IaC 代名词的主要原因。

安装与环境配置：3 步就绪

步骤一：安装二进制。 macOS 推荐 Homebrew；Windows 可用 Chocolatey（choco install terraform）或 winget install HashiCorp.Terraform；Linux（Debian/Ubuntu）建议添加 HashiCorp 官方 apt 仓库，这样升级走系统包管理器，避免手动管理 PATH。也可以直接下载官方 zip 解压到 /usr/local/bin。

步骤二：配置云厂商凭据。 Terraform 本身不保存云账号密码。AWS 用 aws configure 生成 ~/.aws/credentials，或设置 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY 环境变量，Provider 会读取标准 SDK 凭据链。给 IAM 用户配最小权限即可，不要用账号根密钥。

步骤三：验证与补全。 运行 terraform version 确认安装成功；terraform -install-autocomplete 开启命令行 Tab 补全，提升日常效率。

# macOS：Homebrew 安装brew tap hashicorp/tapbrew install hashicorp/tap/terraform # Ubuntu/Debian：官方 apt 仓库wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpgecho "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.listsudo apt update && sudo apt install terraform -y # 验证terraform version

快速上手：15 分钟在 AWS 创建第一台 EC2

最小可用流程是“写配置 → init → plan → apply → destroy”。先在空目录创建 main.tf，内容包含 required_providers（锁定 aws provider 为 ~> 5.0）、provider 块（指定区域）、一个 data 源查找最新的 Amazon Linux AMI（镜像 ID 按区域自动解析，避免硬编码失效镜像）、一个 aws_instance 资源和一个 output 输出实例 ID。

1. 执行 mkdir terraform-demo && cd terraform-demo，将下方 main.tf 保存到该目录。

2. 准备 AWS 凭据：aws configure 或设置环境变量，确认 IAM 用户具备 EC2 读写权限。

3. 运行 terraform init：下载 aws provider 插件并生成 .terraform.lock.hcl 依赖锁文件。

4. 运行 terraform fmt 统一格式，再运行 terraform validate 做语法与内部引用校验。

5. 运行 terraform plan 查看执行计划，确认它只创建 1 个实例、不会动其他资源。

6. 运行 terraform apply，输入 yes 确认后创建资源。

7. 查看 output 输出的实例 ID，到 AWS 控制台核对；验证完运行 terraform destroy 清理，避免持续计费。

进阶技巧：把可复用的网络、计算逻辑抽到 modules/ 目录形成自定义模块；多套环境用 -var-file=dev.tfvars、prod.tfvars 区分参数，同一份代码交付不同环境。

# main.tfterraform {  required_providers {    aws = {      source  = "hashicorp/aws"      version = "~> 5.0"    }  }} provider "aws" {  region = "ap-northeast-1"} data "aws_ami" "amazon_linux" {  most_recent = true  owners      = ["amazon"]   filter {    name   = "name"    values = ["al2023-ami-2023.*-x86_64"]  }} resource "aws_instance" "web" {  ami           = data.aws_ami.amazon_linux.id  instance_type = "t2.micro"   tags = {    Name = "terraform-demo"  }} output "instance_id" {  value = aws_instance.web.id}

核心能力详解：4 大支柱

支柱一：声明式配置与执行计划。 HCL 语法描述期望状态而非操作步骤。plan 会列出每个资源的 create/update/delete 三类变更，-out 参数可将计划存入文件供 show 复查；-target 只影响指定资源，缩小变更爆炸半径；plan -detailed-exitcode 以退出码（0 无差异、1 报错、2 有差异）供 CI 脚本消费，是后面漂移检测的基础。

支柱二：状态管理。 terraform.tfstate 是真实世界与配置的映射，记录资源 ID、全部属性与元数据。生产环境必须使用远程后端（S3、Azure Storage、GCS、Consul 等），并配合 DynamoDB 等锁机制防止并发 apply 互相覆盖；state mv、state rm、import 负责调整资源归属和纳管存量资源。

支柱三：依赖图与并行执行。 Terraform 会自动分析资源间引用关系（被引用的资源即依赖）构建有向无环图，图中无依赖的节点并行创建（默认并发 10，-parallelism 可调）。无法从引用推导的隐式依赖用 depends_on 显式声明，避免“安全组还没建好就挂到实例上”的竞态。

支柱四：模块与 Provider 生态。 module 把 VPC、Kubernetes 集群等单元封装成可复用组件，支持输入变量、输出值与版本约束；Terraform Registry 承载 3000+ Provider 与海量公开模块；for_each/count 实现批量创建与条件逻辑，如按可用区循环创建子网。

生产部署与监控：从上线到运维

部署方式一：远程状态后端。 生产环境严禁本地状态文件。用 S3 存储 + DynamoDB 锁是最成熟的免费方案：S3 开启加密与版本控制，DynamoDB 表提供乐观锁，防止多成员同时执行 apply 造成状态损坏。后端在上线第一天就配置，后期迁移成本高。

部署方式二：CI/CD 集成。 在 GitHub Actions 或 GitLab CI 中，对每个 Merge Request 自动执行 terraform plan 并把结果作为评论展示；人工 review 通过后再由具备高权限的流水线执行 apply。Atlantis 是专为 Terraform 设计的 PR 自动化工具，直接在 PR 内完成 plan/apply 对话。dev/staging/prod 用不同 backend key 与不同 tfvars 文件隔离。

部署方式三：策略与安全。 用 checkov、tfsec 对配置做静态扫描（检查公网暴露、加密缺失等）；密钥通过 Vault、AWS SSM 或环境变量注入，禁止明文写在 .tf 文件；模块与 Provider 固定版本范围，升级走测试环境验证。生产账号的 IAM 策略按“创建资源所需最小权限”收敛，避免 Terraform Runner 权限过大。

可观测性。 漂移检测是 IaC 的核心运维动作：定时执行 terraform plan -detailed-exitcode，退出码 2 表示实际资源与配置不一致，触发告警工单；云厂商审计日志（如 CloudTrail）可回溯每次资源的变更来源；HCP Terraform 提供 Run 历史、状态版本对比与策略检查，适合需要治理能力的团队。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>坑 1：把 tfstate 提交进 Git。状态文件含数据库口令、私钥等明文敏感值，且并发修改会损坏；必须用远程后端并做访问控制。</li><li>坑 2：无状态锁直接上生产。多人/多流水线同时 apply 会互相覆盖状态，导致资源与实际脱节；务必用 DynamoDB 等后端起锁。</li><li>坑 3：手动编辑 tfstate 或控制台手改资源。状态与真实资源不一致后，下次 plan 会出现意外重建或删除；用 import 和 state 命令矫正，别手改。</li><li>坑 4：Provider 版本写死 latest 或不锁版本。升级可能引入破坏性变更造成资源替换；提交 .terraform.lock.hcl 并在 required_providers 中用 ~> 限定。</li><li>坑 5：用 provisioner（local-exec/remote-exec）做配置管理。官方明确这是最后手段；容器内装软件应优先用 user-data、镜像构建或 Ansible。</li><li>坑 6：生产环境跳过 plan 审查直接 auto-approve。plan 的 diff 是防呆网，能提前暴露替换/删除类高危变更；CI 中把 apply 与 plan 分离并加人工审批。</li></ul>

terraform {  backend "s3" {    bucket         = "my-company-tfstate"    key            = "prod/network/terraform.tfstate"    region         = "ap-northeast-1"    encrypt        = true    dynamodb_table = "terraform-state-lock"  }}

版本迭代

Terraform 从 0.x 走向 1.x 经历了语言稳定到工程化成熟的过程：1.0（2021）确立升级兼容性承诺，1.6（2023）完成许可切换并引入测试框架，1.8 起围绕 S3 后端、临时资源、OIDC 身份认证等企业级能力持续增强。截至当前，正式发布主线为 1.11.x。

AI 应用场景

常见误区

面试题