4. 冷启动场景定义：从零开始创建基础设施目录，无存量状态文件，首次 Apply 的挑战
冷启动（Cold Start）是 Terraform 服务目录生命周期中最特殊、也最脆弱的阶段。此时，代码仓库中只有目录模板与配置文件，而远程云平台（AWS、Azure、GCP）上尚未创建任何对应资源，本地或远端也不存在任何 .tfstate 状态文件。首次 terraform apply 不仅要完成资源创建，还必须通过资源边界校验与审批记录写入的双重关卡。
4.1 冷启动的典型特征
| 特征维度 | 冷启动状态 | 热启动（增量变更）状态 |
|---|---|---|
| 状态文件 | 不存在，terraform init 后从空后端开始 |
已存在，terraform plan 可读取完整状态 |
| 远程资源 | 目标云账号中无对应资源 | 已有部分或全部资源 |
| 资源边界 | 边界规则首次生效，无历史基线可对比 | 可基于已有状态做增量边界检查 |
| 审批记录 | 需创建第一条审批记录，并关联初始资源清单 | 追加增量变更记录 |
| 失败回滚 | 无状态可回退，需手动清理已创建的部分资源 | 可通过 terraform destroy 或回退到上一版本状态 |
4.2 首次 Apply 的核心挑战
冷启动场景下，terraform apply 面临四个相互交织的挑战，任何一个环节出错都可能导致目录初始化失败。
- 资源边界预检盲区：由于没有存量状态，
terraform plan无法通过data.terraform_remote_state或本地状态对比来验证资源命名、标签、区域等边界规则。边界策略必须依赖外部数据源（如 CMDB、策略引擎 API）或硬编码在模板中。 - 审批记录与资源创建的顺序依赖：部分组织要求先写入审批记录（如 ServiceNow 变更单），再执行资源创建。冷启动时，审批记录本身可能也需要先创建对应的数据库表或 API 资源，形成循环依赖。
- 部分创建后的状态不一致：如果 Apply 中途失败（如 VPC 创建成功但子网创建失败），由于没有完整状态文件，
terraform apply无法自动识别已创建的资源，重试时可能报“资源已存在”错误。 - 后端状态锁初始化：冷启动时，如果使用远程状态后端（如 S3 + DynamoDB），必须先确保后端基础设施（S3 存储桶、DynamoDB 表）已存在。这通常需要 bootstrap 流程，增加了首次 Apply 的前置条件。
⚠️ 常见陷阱： 很多团队在冷启动时直接执行
terraform apply -auto-approve，跳过了 terraform plan 的人工审核。在无存量状态的情况下，plan 输出中的资源边界违规无法被自动捕获，可能导致创建出不符合企业标准的资源，后续整改成本极高。
4.3 冷启动流程中的资源边界与审批记录交互
下图展示了冷启动场景下，从模板提交到首次 Apply 完成的核心交互流程，重点突出资源边界校验与审批记录写入的时序关系。
4.4 冷启动的推荐前置检查清单
在首次执行 terraform apply 之前，建议逐项确认以下条件，以降低冷启动失败风险。
- 后端基础设施就绪：确认远程状态后端（S3 存储桶、DynamoDB 锁表）已通过 bootstrap 流程创建，且 Terraform 后端配置正确。
- 边界策略数据源可用：如果资源边界规则依赖外部 API（如标签策略、命名规范服务），确保这些服务在冷启动时可正常访问并返回预期结果。
- 审批记录目标系统连通：确认审批记录写入目标（如数据库、CMDB、变更管理系统）的表结构或 API 端点已初始化，避免写入失败导致 Apply 中断。
- 最小权限凭证验证：使用只包含目录所需最小权限的云账号凭证执行
terraform plan，提前发现权限不足问题，避免在 Apply 阶段才暴露。 - 空运行计划审核：即使无存量状态，也应人工审核
terraform plan输出的资源名称、区域、计费属性等关键字段，确保与目录模板预期一致。
💡 最佳实践： 在冷启动阶段，建议将
terraform apply 拆分为两步：先执行 terraform plan -out=tfplan 生成计划文件，再由人工或自动化审批系统审核计划文件内容。审核通过后，使用 terraform apply tfplan 执行。这种方式可以在无状态的情况下保留一份可追溯的变更计划。
4.5 冷启动失败后的恢复策略
当首次 Apply 部分失败时，由于没有完整状态文件，不能直接使用 terraform destroy 回滚。以下是三种推荐的恢复策略。
| 策略 | 适用场景 | 操作步骤 | 风险等级 |
|---|---|---|---|
| 手动导入状态 | 已创建资源较少（<5 个），且资源类型支持 terraform import |
1. 使用 terraform import 逐个导入已创建资源2. 执行 terraform plan 确认剩余资源3. 重新执行 terraform apply |
中 |
| 手动清理 + 重试 | 已创建资源可安全删除（如开发环境） | 1. 通过云控制台或 CLI 删除已创建资源 2. 清空本地 .terraform 目录3. 重新执行 terraform init 和 terraform apply |
低 |
| 状态文件重建 | 已创建资源较多，且无法手动导入 | 1. 使用 terraform state pull 获取空状态2. 手动编辑状态文件，添加已创建资源的占位信息 3. 执行 terraform plan 验证一致性 |
高 |
📌 课程实验提示： 在本课程的后续实验章节中，你将亲手模拟一次冷启动场景：从空状态开始，配置资源边界策略（如强制标签和命名规范），写入审批记录，然后执行首次 Apply。实验将故意引入一个边界违规，让你体验冷启动失败后的恢复流程。