Terraform基础设施

每一次手工配置出来的环境，一开始都好好的。你在控制台里点来点去，把设置记下来，然后继续做下一件事。接着第二个环境出现了，然后是 staging 副本，再来一个灾备地域——突然之间，你基础设施的"唯一事实来源"变成了一个谁也记不清哪个改动到底应用在哪个环境的群聊。这就是团队开始用 Terraform 的那个时刻。但"开始用"和"用得好"是两码事。Terraform 并不会替你省钱掉判断力；它只是把你已有的判断固化下来，让错误变得可复现而不是被藏起来。如果你正从"点鼠标"的工作流迁移过来，关键不是第一天学会 HCL 的所有特性，而是做出一系列会影响未来多年的、深思熟虑的架构决策。

为什么声明式基础设施胜过命令式脚本

在 Terraform 之前，运维团队写的是命令式脚本："先创建这个 VPC，再建这个子网，然后挂一个路由表。"这种脚本依赖顺序、非常脆弱——跑两次就可能失败或者重复创建资源。Terraform 采用声明式：你描述你想要的最终状态，工具自己算出怎么到达那里。aws_vpc、aws_subnet、aws_instance 这些资源块描述"应该存在什么"，而 terraform plan 会在 terraform apply 落地之前，精确展示会发生什么变化。这个 plan/apply 循环是能救你生产环境的功能，因为它把"直接跑就完事"这种冒险，变成了一份团队可以审阅、批准的可读 diff。

状态管理是另一根支柱。Terraform 用一个 terraform.tfstate 文件跟踪你的代码和线上资源之间的关系。把这个文件存在本地笔记本上，相当于给漂移和数据丢失留了一扇门，所以一旦有不止一个人碰这段代码，远程后端——比如带 DynamoDB 锁的 S3，或者 Terraform Cloud——就成了硬性要求。理解了Docker 入门指南 2026之后再去设计这些云层，你会更容易想清楚网络、计算和数据层之间的边界，而不是只写一堆语法。

选择模块、工作区和正确的分层策略

大多数团队过早地把代码模块化。在为一个"网络"或"数据库"写自定义模块之前，先问问自己：这个资源真的会在多个环境里复用吗？如果你只有一个生产环境，那么一个扁平的目录反而更干净、更好调试。先用云厂商 registry 里针对成熟模式的官方模块，只有当你第二次复制粘贴这段代码时，才把一个目录提升为模块。

工作区（workspaces）解决的是另一个相关的问题：如何用一份代码库跑 dev、staging 和 prod。简单的答案是让每个环境拥有独立的状态文件（每个环境一个目录或独立的工作区），并用输入变量来避免硬编码 VPC CIDR 或 AMI ID 之类的值。一个常见错误是多个环境共用一个状态文件，这意味着 staging 的一次 destroy 可能危及生产资源。分层也很重要——把网络改动和应用部署分开，这样某一层的改动不至于强迫另一层的所有东西做无关的重建。

务实的团队结构与工作流

Terraform 在所有权明确时运行得最好。指定一到两个人作为基础设施改动的评审人，并且要求每个 pull request 里附上 plan 输出，这样评审人能看到实际会被应用什么。把 apply 步骤接入 CI/CD，让 terraform plan 自动运行，由人类来批准 apply。这与你在DevOps 核心基础（英文）里学到的纪律一脉相承——在那里，自动化和评审才是让流水线可靠而非仅仅"快"的原因。

同时给你的代码和 provider 做版本管理。在 required_providers 块里锁定 AWS 或 GCP 的 provider 版本，先在非生产工作区测试升级，并用共享的 toolchain 文件让整个团队的 Terraform 二进制版本保持一致。这些不起眼的版本习惯，正是防止"我这台机器上明明能跑"这种灾难的关键——当整个团队的环境在你不知情时悄悄分道扬镳，这种灾难就会爆发。

不留密码进代码地处理密钥

泄露凭证最简单的方式，就是直接把它们粘进 .tf 文件然后提交。Provider 接受来自环境变量或密钥管理器的变量，现代实践是动态引用密钥而不是存储它们。在 AWS 上可以用 aws_secretsmanager_secret_version 这样的数据源，在 apply 时拉取密钥。规模较小时，把密钥放在环境变量里，或放在一个被 gitignore 掉的本地 terraform.tfvars 文件里，绝对不要加密后提交密钥文件。你的 plan 输出对仓库里有访问权限的每个人都可见，所以一个分支上泄露的密钥基本就等于要轮换了。

连通性、成本，以及 Terraform 的替代品格局

除了创建资源，Terraform 最擅长的是把网络依赖串起来：VPC 对等连接、transit gateway、安全组和负载均衡规则。关键技能是清楚地把依赖表达出来，让 Terraform 正确排序创建流程，而不是靠你猜。成本是另一个角度——能按需查看和重建环境，意味着你可以轻松拆掉不再使用的 staging 基础设施，因为销毁一个 terraform apply 出来的环境只是一条文档明确的命令，而不是在控制台里寻宝。把 Terraform 和云与 DevOps 课程的建议搭配起来的团队会发现，基础设施变成了又一个可部署的组件，而不是一个随时让发布脱轨的瓶颈。

如果你的团队已经写代码，而且更喜欢通用编程语言，Pulumi 是个很强的替代方案；如果你看重稳定、社区最大的声明式 DSL，Terraform 仍然是默认选择。很多团队出于许可上的安心会统一用 OpenTofu，同时保持完全一样的工作流。

高效学习 Terraform

克制住把每种资源类型都背下来的冲动。学五个核心模式就够了：一台带网络的 EC2/VM、一个负载均衡器加目标组、一个托管数据库、一个 S3/bucket 加 IAM 策略，以及一个触发 apply 的 CI/CD 钩子。把这些模式在各个工作区里重建几遍，你就覆盖了真实 Terraform 工作里大约八成的场景。把工具和更广的云计算基础结合起来也很重要——你不仅要会语法，还要懂你供给的这些服务本身，而这些正是本站数据工程基础（英文）和中文版数据工程基础共同培养的分析习惯。把云网络的思维模型委托给 Terraform，并不会免除你去推理自己架构的责任——它只是让你的推理变得可测试、可重复。

常见问题

Terraform 和 AWS CloudFormation，该用哪个？

如果你完全押注 AWS，CloudFormation 集成得很好、原生化，但它把你锁死在单一云厂商。Terraform 能在 AWS、GCP、Azure 和 Kubernetes 上提供统一工作流，模块生态也更大。大多数多云团队选 Terraform；只上 AWS 的单云团队则两者皆可，选哪一个都说得过去。

如何防止两个工程师同时弄坏同一个远程状态？

用状态锁。用 S3 后端时，开启 DynamoDB 锁，这样并发的 terraform apply 会干净地失败，而不是写入互相冲突的状态。Terraform Cloud 和 TFE 开箱即带这种锁。绝不要在没有锁的情况下从两台机器往同一个状态执行 apply。

什么该放进模块，什么该留在普通目录？

当你在两个或更多地方、以不同输入复用同一段代码时，才把代码提升为模块。如果一个资源只出现一次，就把它留在扁平文件里。过早建模块徒增间接层，让调试比本来应该的更难。

在 staging 上跑 terraform destroy 安全吗？

安全，而且你确实该定期这么做来节省成本——但前提是 staging 有自己的状态，并且绝不共用指向生产数据的变量。确认你的 destroy 作用域在正确的工作区里，并且任何有状态的数据都已放进托管备份，然后再拆掉它。

用了 Terraform 还需要 Ansible 或 Kubernetes 吗？

Terraform 负责供给基础设施；它不做服务器配置，也不做容器编排。通常你要把它和配置管理工具配对来做系统层配置，用 Kubernetes 来做应用编排。它们解决的是同一套技术栈里不同的层级，运营得当的平台会在各自最擅长的位置使用它们。