收益：
- 能够理解 IaC 概念和 Terraform 的工作周期（初始化、计划、应用、状态、模块）并让人工智能生成安全的 HCL 草稿
- 能够在应用之前检查计划中的每个更改并捕获意外的破坏/替换行
- 能够应用对代码保密、安全保存状态以及最小化 IAM 权限的原则
过去，设置服务器只需点击云面板即可：创建虚拟机、设置网络、添加安全规则。这种方法速度慢、容易出错且不可重复——几乎不可能第二次设置相同的环境。如今，基础设施以代码的形式进行管理。 IaC（基础设施即代码）是一种以文本文件而不是手动方式描述云资源（例如服务器、网络和数据库）的方法。这些文件位于版本控制 (Git) 中；您可以看到谁更改了什么、何时更改以及什么内容；您可以使用一个命令以完全相同的方式多次设置相同的基础设施。
最常见的 IaC 工具是 Terraform。 Terraform 采用名为 HCL（HashiCorp 配置语言 - Terraform 的配置语言）的可读语言编写的定义，将其转换为云提供商（AWS、Azure、GCP）的 API 并创建资源。 AI非常了解HCL并快速生成复杂的块。但在 IaC 中，错误的代价很高：一个错误的定义可能会毁掉整个生产数据库。这就是为什么 Terraform 中的黄金法则是在实施之前先通过“计划”查看每个更改。
Terraform 的运行时
Terraform 使用三个基本命令 - 了解这些命令是控制 AI 输出的先决条件：
- `terraform init`：启动项目，下载必要的提供程序插件。
- `terraform plan`：将当前情况与期望情况进行比较，并显示要添加什么、要更改什么、要删除什么。不执行任何操作。这是最关键的安全步骤。
- `terraform apply`：实际应用计划，创建/修改资源。
此外，有两个概念至关重要。 State（状态文件）：这是Terraform保存其管理的资源当前状态的文件；它通常存放在偏远且上锁的仓库中，以便两个人无法同时更改或销毁它。模块：可复用的配置包；例如，您可以在许多项目中使用“设置网络”模块。
提示：Terraform 输出中最危险的标志是破坏或计划输出中的 -/+（替换）行。这意味着该资源将被删除。如果您在计划中看到意外破坏，切勿申请，首先了解它出现的原因。
一步一步：用 AI 编写 IaC
- 明确所需的基础设施。具体如“eu-central-1 上的一个 VPC、两个子网、一个安全组和一个 t3.micro EC2”。
- 指定提供商和版本。哪个云、哪个 Terraform 和提供商版本？如果您不指定版本，AI 可能会返回过时/不兼容的语法。
- 制作 HCL 草案。还请求变量和输出。
- 把秘密拿出来。密码和密钥等值应存放在变量和秘密库中，而不是代码中。
- 运行“init”+“plan”。逐行读取计划输出；检查是否有意外删除。
- 从小事做起，逐步实施。首先将其应用到隔离的测试帐户/环境中。
安全性：IaC 特定风险
IaC 的威力与风险一样大。三个关键点：
- 国家档案里有秘密。 Terraform 状态有时会以明文形式保留敏感值，例如数据库密码。切勿将 State 放入公共存储库中；使用加密的、访问受限的远程后端。
- 不要在 HCL 中嵌入秘密。像password="prod123"这样的行会永久写入Git历史记录中。相反，使用变量并在运行时从环境变量 (TF_VAR_...) 或秘密保管库中给出值。
- 非常广泛的 IAM 权限。人工智能有时会生成诸如操作：“*”（允许一切）之类的块来“使其工作”。这是一个漏洞；将权限缩小到所需的最低限度。
注意：一旦秘密进入 Git 历史记录，它就会保留在过去，并且可能会被泄露，即使您删除该文件也是如此。如果误犯，立即取消并轮换秘密；仅仅删除是不够的。
风险计划标志表
计划打印输出
含义
该怎么办
+创建
将添加新资源
总体安全，但请审查
~ 就地更新
来源将在现场更改
验证影响（会出现中断吗？）
-/+ 替换
将被删除并重新创建
注意：可能会发生数据丢失
- 摧毁
资源将被破坏
停止：如果你没有预料到，就不要申请
三个迷你箱子
案例 1 — 3 小时完成 2 天的工作。一个团队打算编写 Terraform 来设置新的测试环境（VPC、子网、RDS 数据库、ECS 集群），但他们刚刚迁移到 HCL。他们向人工智能描述了架构和版本，并制作了模块化蓝图。他们根据计划验证了每个模块，并在 3 小时内将其启动并运行；他们需要花费两天的时间进行手动试错。
案例 2 — 计划被删除。工程师在没有应用人工智能生成的更新代码的情况下运行了计划。输出包含 -/+ 替换生产数据库 - AI 尝试替换不可替换的字段，这意味着删除并重新创建数据库。工程师停止apply并更改为safe方法。计划的习惯避免了一场灾难。
案例3——埋藏秘密泄密。大三的，YZ发出db_password = "S3cret!"他按原样提交了这条线并推动了它。陷入代码审查；密码立即被取消和更改，该值被移动到一个变量并从秘密金库提供。教训：HCL 中从来不存在明文秘密。
四个可复制模板
1）生成基础设施草案：
使用 Terraform（版本 ~> 1.7）在 [云：AWS] 上编写以下基础设施：[源列表]。区域 [X]。规则：- 使所有敏感值可变，不要将它们嵌入到 HCL 中。- 修复提供程序版本 (required_providers)。- 最小化 IAM 权限，不要使用“*”。- 返回 [X, Y] 作为输出。模块化地给出代码并附上解释。
2）解释计划输出：
分析下面的“terraform plan”输出。列出我：(1) 添加/更改/删除了哪些资源，(2) 存在数据丢失或中断风险的行，(3) 在申请之前我应该问的 3 个问题。计划：[输出]
3) 检查现有 HCL 的安全性：
检查以下 Terraform 代码的安全性：嵌入式机密、过于广泛的 IAM 权限、开放网络规则 (0.0.0.0/0)、未加密的存储？按照重要性和纠正的顺序写下每项发现。代码：[HCL]
4）将重复代码转换为模块：
将以下重复的 Terraform 代码转换为可重用的模块：哪些值应该是变量，模块接口应该是什么？还显示示例用法。代码：[HCL]
弱提示/强提示
弱：“使用 Terraform 创建数据库。”
结果：不清楚哪个云、哪个引擎、哪个版本、加密与否；利用遗留语法，人工智能可以提供一个公开可用的示例，将密码嵌入到代码中。
强：“使用 Terraform ~> 1.7 在 AWS 上创建 RDS PostgreSQL 15 实例。创建密码变量，不要将其嵌入代码中。存储已加密，只能从私有子网访问，不能从公共子网访问。修复提供程序版本。返回端点作为输出。”
区别：第二个提示给出了引擎、版本、加密、网络约束和秘密规则——输出是安全的并且接近产品。
常见错误
- 不制定“计划”而“申请”。 IaC 中最昂贵的错误；总是先计划。
- 将 Secret 嵌入 HCL。造成 Git 历史记录的永久泄漏。
- 存储状态不安全。未加密、未锁定的公共状态是一场灾难。
- 不修复版本。使用provider而不指定版本会导致将来突然失败。
- *`操作：广泛的权限，例如“”`。**违反了最小权限原则。
- 忽略意外的“破坏”。毫无疑问地应用计划中的删除线。
综上所述
IaC 将基础设施转变为可重复、可版本化和可审计的代码；最常见的工具是 Terraform。 AI 可以快速生成 HCL 存根，但您必须提供版本、特定于云的详细信息和安全规则。 Terraform 中的万无一失的规则：通过计划查看每个更改、查询意外删除、向代码保密并安全地保持状态。计划输出中的销毁和替换行是应该最仔细阅读的地方。
应用任务
让 AI 使用上面的“生成基础设施草图”模板生成小型基础设施（例如存储桶和访问策略）。然后：（1）使用“审查”模板检查代码中嵌入的秘密或*权限； (2) 如果可能，在测试帐户中运行 init + plan 并使用“计划解释”模板读取计划输出； (3) 注意任何意外的删除/更改。
清单
- [ ] 我在提示中添加了云、Terraform/provider 版本和加密/网络约束。
- [ ] 代码中没有明文秘密；精度值变量。
- [ ] 我将 IAM/权限范围缩小到最小权限，* 我没有使用它。
- [ ] 我在应用之前运行计划并逐行读取输出。
- [ ] 我确认计划中没有意外损坏/更换的情况。
- [ ] 我确信该状态保存在加密、锁定和受限的后端中。