1. 课程导入与平台愿景

在传统的基础设施交付模式中，运维或平台团队往往通过手工点击控制台、编写一次性脚本或维护大量环境专属的 Terraform 配置来创建云资源。随着业务规模扩大，这种方式会迅速暴露出三个典型问题：环境之间配置漂移、变更过程不可审计、同类资源重复定义。模块化基础设施平台的核心价值，正是把“资源创建”从一次性操作升级为可复用、可组合、可版本化的产品能力。

可以把 Terraform 在平台工程中的定位理解为“基础设施的编译与装配层”。它向下对接云厂商 API、Kubernetes、DNS、IAM 等真实资源，向上为业务团队提供经过验证的模块接口。平台团队不再直接替业务创建每一台数据库或每一个 VPC，而是交付一组标准模块和调用规范，让业务团队通过声明式配置自助申请基础设施。这样既保留了 Terraform 的幂等性和状态管理能力，又把平台约束固化在模块内部。

本课程围绕一个贯穿始终的实战项目展开：为一家虚构的电商公司构建“多环境微服务基础设施平台”。该平台需要支持开发、预发、生产三套环境，每套环境包含网络、计算、数据库、缓存、对象存储和可观测性组件。业务团队通过调用平台模块，在几分钟内获得一套符合安全基线和命名规范的基础设施，而不是从零编写数百行 HCL。

为了理解模块化平台与普通 Terraform 用法的区别，可以先看一个最小对比。假设需要创建三套环境各自的对象存储桶，非模块化写法通常会在三个目录中复制几乎相同的 resource "aws_s3_bucket" 块，仅修改名称和标签；模块化写法则把存储桶的通用属性、加密策略、生命周期规则和标签规范封装为一个模块，调用方只传入环境名和业务名。下面是一个模块调用的示例结构：

module "app_bucket" {
  source      = "../../modules/s3-bucket"
  environment = var.environment
  app_name    = "order-service"
  versioning  = true
  lifecycle_days = 90
}

这个示例中，source 指向平台团队维护的模块路径，environment 和 app_name 是调用方必须提供的输入变量，versioning 与 lifecycle_days 是可选参数。模块内部会根据这些输入生成符合平台规范的资源名称、标签、加密配置和生命周期策略。调用方不需要知道底层使用了哪些资源，只需要理解模块的输入输出契约。

课程整体学习路径分为四个阶段。第一阶段建立模块化思维，理解根模块、子模块、输入变量、输出值和状态文件之间的关系。第二阶段进入工程化实践，学习模块目录结构、版本管理、远程状态、工作空间与环境隔离。第三阶段聚焦平台能力建设，包括模块注册表、策略即代码、自动化测试、CI/CD 流水线和自助服务门户。第四阶段完成综合实战，把前三个阶段的能力整合为可运行的多环境平台，并加入故障排查与成本治理。

在正式进入模块编写之前，需要先建立一张平台全景图。下图展示了业务团队、平台模块、Terraform 执行层和云资源之间的数据流与依赖关系。图中左侧是模块消费方，中间是平台团队维护的模块仓库与流水线，右侧是 Terraform 通过 Provider 操作的真实云资源。理解这张图有助于后续章节中定位每个组件的作用。

从图中可以看到，平台团队的核心产出不是某一次资源创建结果，而是模块仓库和流水线。业务团队通过模块接口表达需求，Terraform 执行层负责把声明转换为真实资源。状态文件记录了当前基础设施的快照，审计日志记录了谁在什么时间执行了什么变更。这条链路中的每一个环节，都会在后续章节中展开。

在开始动手之前，建议先明确本课程的约定。所有示例使用 AWS Provider 作为主要演示对象，但模块化思想同样适用于阿里云、腾讯云、Azure 或 Kubernetes。示例中的区域、实例规格、存储容量和标签值均为教学假设，实际使用时需要根据云账号、合规要求和成本预算调整。课程中的命令和配置片段可以直接参考，但不要未经审查就应用到生产环境。