Terraform基础：安装配置、CLI命令、工作流程
Terraform 作为 HashiCorp 公司推出的基础设施即代码（IaC）工具，其核心价值在于将云资源、本地服务、SaaS 平台等基础设施的创建、更新与销毁，转化为可版本化、可评审、可自动化的声明式配置文件。理解 Terraform 的安装方式、CLI 命令体系以及核心工作流程，是掌握该工具的第一步，也是构建后续复杂编排能力的地基。本章将围绕这三个维度展开，帮助读者建立从“工具就绪”到“状态流转”的完整认知。
2.1 安装与配置：从二进制到 Provider 初始化
Terraform 的安装方式因操作系统而异，但核心原则一致：获取官方二进制文件，配置环境变量，并确保网络可达以获取 Provider 插件。对于 Linux 或 macOS 用户，推荐使用包管理器（如 Homebrew、apt）或直接从 releases.hashicorp.com 下载预编译二进制。Windows 用户则可通过 Chocolatey 或手动解压 ZIP 包并添加至 PATH。
安装完成后，验证版本是第一步：
# 验证安装
terraform version
# 查看帮助信息
terraform -help
# 查看子命令帮助
terraform plan -help配置层面的核心是 Provider 的初始化。Terraform 通过 required_providers 块声明依赖，执行 terraform init 时，它会根据锁定文件（.terraform.lock.hcl）下载指定版本的 Provider 插件。这里需要特别注意：Provider 版本锁定是生产环境稳定性的关键，避免因插件升级导致配置行为变化。
| 安装方式 | 适用系统 | 优点 | 注意事项 |
|---|---|---|---|
| 包管理器 | Linux/macOS | 自动处理依赖与升级 | 版本可能滞后，需确认兼容性 |
| 二进制下载 | 全平台 | 版本精确可控 | 需手动配置 PATH |
| Docker 镜像 | CI/CD 环境 | 隔离性好，可重复 | 需挂载工作目录与凭证 |
| asdf / tfenv | 开发机 | 多版本切换灵活 | 需额外安装版本管理工具 |
required_version 约束 Terraform 版本范围，例如 required_version = "~> 1.5.0"，避免因版本差异导致状态文件不兼容。
2.2 CLI 命令体系：四大命令族与高频操作
Terraform CLI 命令可划分为四大族：生命周期命令（init/plan/apply/destroy）、状态管理命令（state/refresh）、辅助命令（fmt/validate/console）以及高级命令（import/taint/workspace）。理解命令之间的依赖关系，比死记硬背参数更重要。
生命周期命令是日常操作的主干，其执行顺序和逻辑如下：
- init：初始化工作目录，下载 Provider 和模块，配置后端（Backend）。这是所有操作的前置条件。
- validate：校验配置文件的语法和内部一致性，不访问远端 API。
- plan：生成执行计划，对比当前状态与期望状态，展示将要创建、修改或删除的资源。
- apply：执行计划中的变更，实际调用云厂商 API 完成资源操作。
- destroy：销毁由当前配置管理的基础设施资源。
状态管理命令在排障和资源迁移时尤为重要。例如，当手动在云控制台修改了资源属性后，需要执行 terraform refresh 更新本地状态文件；当需要将资源从一处迁移到另一处时，terraform state mv 可以调整状态中的资源地址。
# 常用状态操作示例
terraform state list # 列出所有被管理的资源
terraform state show aws_instance.web # 查看特定资源的详细属性
terraform state rm aws_instance.web # 从状态中移除资源（不销毁实际资源）
terraform state mv aws_instance.web aws_instance.web_new # 重命名资源地址terraform.tfstate 文件是极度危险的操作。状态文件是 Terraform 对现实世界资源的唯一映射，任何手动修改都可能导致资源被误删或重复创建。务必使用 terraform state 子命令进行安全操作。
2.3 工作流程：从代码到基础设施的闭环
Terraform 的核心理念是“声明期望状态，工具负责收敛”。一个标准的工作流程包含以下环节：编写配置 → 初始化 → 计划预览 → 人工审批 → 应用变更 → 状态更新 → 持续迭代。在团队环境中，这个流程通常与 Git 分支策略和 CI/CD 流水线结合，形成“GitOps”模式。
以创建一台 AWS EC2 实例为例，完整流程如下：
# main.tf
provider "aws" {
region = "ap-southeast-1"
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
tags = {
Name = "web-server"
}
}执行流程：
- Step 1：
terraform init初始化，输出显示 Provider 已下载。 - Step 2：
terraform plan生成计划，显示 “Plan: 1 to add, 0 to change, 0 to destroy”。 - Step 3：
terraform apply执行变更，输入yes确认。 - Step 4：验证输出，
terraform show查看资源属性。
在真实生产环境中，apply 通常需要经过审批门禁。例如，在 CI 流水线中，plan 阶段自动执行并生成 JSON 报告，由技术负责人审核后触发 apply 任务。这种“计划与执行分离”的模式，有效降低了误操作风险。
terraform workspace 区分开发/生产环境，通过 terraform plan -out=plan.tfplan 保存计划文件，再由 CI 系统在审批通过后执行 terraform apply plan.tfplan，确保执行内容与审批内容完全一致。
2.4 常见误区与复盘
初学者在使用 Terraform 时，常陷入以下误区，这里逐一剖析并给出规避建议。
| 误区 | 典型表现 | 后果 | 正确做法 |
|---|---|---|---|
| 忽略状态文件管理 | 将 tfstate 提交到 Git | 状态冲突、敏感信息泄露 | 使用远程后端（S3/OSS）+ 状态锁 |
滥用 terraform destroy | 在非生产环境随意销毁 | 数据永久丢失 | 使用 terraform plan -destroy 预览后再执行 |
| 手动修改资源后不同步 | 在控制台改安全组规则 | 下次 apply 被覆盖 | 通过 terraform import 纳入管理 |
| 忽略 Provider 版本锁定 | 未使用 lock.hcl | 升级后行为不一致 | 提交 lock.hcl 并定期审查升级 |
| 将所有资源放在单一 main.tf | 文件超过 1000 行 | 可读性差、变更影响范围大 | 使用模块化设计，按业务域拆分 |
复盘总结：Terraform 的优雅之处在于它将基础设施的“最终状态”固化为代码，但这份优雅需要纪律来守护。团队应建立明确的代码评审规范，要求每次变更必须附带 plan 输出；同时，定期进行 terraform validate 和 terraform fmt -check 作为 CI 的静态检查关卡。对于状态文件，务必启用版本控制和加密，并配置 DynamoDB 或 Consul 实现锁机制，防止并发执行导致状态损坏。