1. 项目概述当Terraform遇上AI如何让基础设施即代码管理更高效在基础设施即代码IaC领域Terraform 几乎是标准答案。但任何一个资深 DevOps 工程师或云架构师都清楚管理一个成熟、复杂、尤其是从混乱中生长出来的 Terraform 项目其挑战往往不在于编写新代码而在于理清历史旧账。我最近就处理了这样一个典型场景一个跨多区域的 AWS Terragrunt 项目其状态文件、实际运行的云资源以及 HCL 配置文件三者之间完全对不上号。部分资源被纳管部分没有没人能说清到底哪些是哪些。这比从零开始还要糟糕——你面对的不是一张白纸而是一张被随意涂改过、关键信息模糊不清的草图。其中仅网络安-全组规则一项就需要核对四个环境中总计约一万行的配置。这种工作如果纯手工进行小心翼翼地比对、验证、修正花上几周时间是常态。然而借助大语言模型LLM来处理其中机械、重复的部分我将这个过程压缩到了几个小时。这并不是说 AI 能替代工程师的决策和架构思维而是它像一个不知疲倦、且严格遵循指令的助手高效地完成了那些我们明知怎么做、但做起来极其繁琐的任务。这篇文章我想分享的就是在 Terraform 工作流中LLM 真正能发挥价值的两个具体模式存量基础设施导入和基于内部规范的模块脚手架生成。核心原则只有一个给它真实的上下文它才能产出有用的工作成果给它模糊的提示你得到的只是需要二次加工的通用输出。2. 核心工作流拆解从混沌到清晰的导入实战面对一个状态、配置、实际资源三者不一致的“烂摊子”盲目执行terraform import无异于玩火。我们的首要目标是获得完整的、准确的现状图景并制定一个安全、可控的导入策略。2.1 第一步建立可信的“资源真相源”在采取任何行动之前你必须知道云端到底有什么。依赖可能存在问题的 Terraform State 或残缺的 HCL 配置是危险的。我的做法是直接通过云服务商的 API 拉取一份完整的资源清单。实操要点构建动态资源清单工具我选择用 Python 编写一个轻量级工具其核心是调用 AWS SDKBoto3来查询所有相关的资源类型。这里的关键在于“动态”和“结构化”。定义资源查询模板我为第一种资源类型例如EC2 实例编写了详细的查询代码包括如何处理分页、筛选标签、提取哪些关键属性如 ID、名称、VPC ID、标签等并将结果输出为结构化的文本如 JSON Lines。利用 LLM 进行模式扩展这是 LLM 第一个大显身手的地方。我将编写好的 EC2 实例查询代码、以及我希望的输出格式描述给 LLM然后要求它为后续的十几种资源类型如 VPC、子网、安全组、IAM 角色、RDS 实例等生成类似的查询代码。我提供的提示词类似于“以下是一个用于列出所有 EC2 实例并输出特定属性的 Python 函数。请参照此模式为 AWS 资源类型 ‘Security Group’ 编写一个类似的函数。注意安全组需要包含GroupId、GroupName、VpcId、IpPermissions入站规则和IpPermissionsEgress出站规则。请确保处理可能存在的分页。”LLM 能够快速、一致地生成语法正确、结构匹配的代码极大地避免了人工编写时可能出现的拼写错误、遗漏字段或 API 调用方式不一致的问题。整个包含 15 种核心资源类型的清单工具集在一个小时内就完成了初版。执行与整合为每种资源类型编写一个极简的 Shell 包装脚本调用对应的 Python 函数并将结果输出到独立的文件中如inventory_ec2.jsonlinventory_sg.jsonl。最终你得到的是一个基于实时 API 的、多文件组成的资源真相源。注意这个清单工具的生命周期可能很长。在完成本次导入后可以考虑将其完善加入定时运行、差异对比等功能作为日常巡检或合规检查的一部分。LLM 生成的代码在经过人工审查和简单调整后完全具备可维护性并非一次性的“快糙猛”脚本。2.2 第二步状态与配置的标准化与比对有了云端的实时清单接下来需要处理 Terraform 这边的数据State 和 HCL 配置。标准化 Terraform State原生的 Terraform 状态文件特别是远程状态不易直接解析。使用terraform state pull state.json命令将状态拉取到本地并转换为 JSON 格式。结构化 JSON 是 LLM 处理和理解信息的理想格式远比在terraform show的输出中肉眼搜寻要高效得多。编写比对脚本现在我们有三套数据A (Live): 从 AWS API 获取的实时资源清单。B (State): 从 Terraform 拉取的 JSON 状态文件代表 Terraform认为它管理的资源。C (HCL): 项目中的.tf配置文件代表工程师声明的资源理想状态。编写脚本的核心逻辑是找出差异A - B: 存在于云端但未被 Terraform 状态管理的资源即需要导入的候选。B - A: 存在于 Terraform 状态中但云端已不存在的资源即“幽灵资源”可能需要terraform state rm。B与C的差异状态与声明的配置是否一致即是否存在未应用的变更。同样编写这些比对逻辑是模式化的。你可以向 LLM 描述数据 A、B、C 的格式以及你想找出的集合差异它可以帮助你快速生成 Python 脚本的框架你只需填充具体的资源类型键值如resource_id即可。2.3 第三步处理最复杂的部分——安全组规则比对安全组Security Group通常是导入中最棘手的部分因为它的规则是嵌套的、复杂的且格式在 AWS API 和 HCL 之间差异很大。难点解析AWS API 返回的规则是一个包含复杂嵌套对象的列表如 IP 协议、端口范围、前缀列表ID等而 Terraform HCL 中的ingress/egress块是另一种声明式结构。直接进行字符串比对是行不通的。解决方案构建逻辑模型进行标准化比对我向 LLM 清晰地描述了这个问题我有两种数据源AWS API 返回的IpPermissions列表和 HCL 文件中的ingress { ... }块。两者在表示上不同例如API 中IpRanges的CidrIp字段对应 HCL 中的cidr_blocks列表。我需要一个程序能解析这两种格式将它们转换为一个统一的、可比较的中间逻辑模型例如一个包含协议、起始端口、结束端口、源/目标 CIDR 的元组然后找出哪些规则只存在于 API未管理哪些规则只存在于 HCL“幻影”规则可能配置有误或对应资源已删除。LLM 非常擅长这类格式转换和逻辑建模的任务。根据我的描述它生成了 Python 代码的骨架包括解析 AWS API 响应并扁平化规则的函数。使用hcl2或python-hcl2库解析.tf文件提取安全组资源及其规则的函数。将两者都转换为标准化Rule对象的函数。执行集合差集计算并生成清晰报告的函数。关键决策拆分巨型配置文件在开始生成导入代码之前我做出了一个重要的架构决定将包含所有安全组配置的巨型 HCL 文件约 600 行按每个安全组拆分成独立的文件。原因有三可维护性符合 Terraform 模块化最佳实践便于后续独立修改和审查。LLM 友好性让 LLM 处理一个只包含单个资源的小文件远比让它在一个大文件中定位和修改特定片段要可靠得多出错率更低。原子化操作导入和后续变更可以更精细地进行。这个决策必须由人来做因为它涉及到对项目未来维护模式的理解。在拆分完成后再让 LLM 基于新的文件结构来协助生成导入代码就顺畅多了。2.4 第四步优先级排序与导入执行面对成百上千个需要导入的资源不能一拥而上。我建立了一个简单的优先级评估模型包含四个维度依赖度有多少其他资源的硬编码 ID如安全组 ID引用了该资源依赖度高的优先。阻塞性该资源未被管理是否会阻塞其他关键工作如新环境部署复杂度导入该资源的操作复杂度如何例如导入一个 EC2 实例比导入一个包含多条规则的安全组简单。变更频率该资源是静态的基础设施如 VPC还是频繁变更的如 Auto Scaling 策略静态的优先级可以稍低。我编写脚本从 HCL 文件中grep出资源 ID 引用结合资源清单和状态文件为每个资源计算上述维度的原始数据。然后我将这些原始数据表格和我的优先级逻辑描述交给 LLM让它生成一份按优先级排序的导入清单草案。我只需要在此基础上进行最终微调即可。最终顺序是互联网网关、密钥对、CloudTrail、Secrets Manager 优先而 Lambda 和 SageMaker 等则明确推迟。导入执行与反馈循环我选择使用 Terraform 1.5 引入的import块进行声明式导入。这对 LLM 辅助工作流至关重要。生成导入块对于需要导入的资源如安全组规则其导入 ID 格式是特定且繁琐的例如sg-xxx_ingress_tcp_80_80_0.0.0.0/0。向 LLM 提供资源 ID 和规则详情让它批量生成成百上千个格式正确的import块代码准确率远高于人工。利用terraform plan作为黄金反馈执行terraform plan后Terraform 会明确告诉你哪些资源将被导入、哪些导入 ID 可能不匹配、哪些资源配置与导入状态存在差异即“漂移”。将plan输出作为 LLM 的输入这是整个流程中最强大的环节。将terraform plan的文本输出直接粘贴给 LLM并提示“以下 Terraform 计划显示这些资源的导入状态与 HCL 配置存在差异。目标是让配置与导入的资源完全匹配1:1。请根据计划输出建议需要修改的 HCL 配置。” LLM 能够精准地解读plan输出识别出是缺少了某个属性如description还是import块中的 ID 有误或是资源配置本身需要调整。它随后会给出具体的 HCL 代码修改建议。这个闭环极大地加速了调试和修正过程。实操心得terraform plan的输出是 LLM 理解 Terraform 意图的绝佳桥梁。它形式化、无歧义地描述了当前状态与目标状态的差异。将这个“差异描述”交给 LLM 去分析和提出解决方案比直接让 LLM 去猜“如何修复配置”要可靠得多。2.5 第五步验证与收尾导入全部应用后工作并未结束。必须进行双向验证以确保没有遗漏。单向验证的不足如果仅从 HCL 配置出发检查其对应的资源是否在 AWS 中存在且属性正确这只验证了“HCL 管理的资源是对的”。双向验证的必要性我们需要从 AWS 实时清单出发向外验证检查 AWS 中存在的资源是否都有对应的、正确的 HCL 配置和 State 条目防止漏导入。检查 HCL 配置中的资源是否在 AWS 中依然存在清理已删除资源的“幽灵”配置。我向 LLM 描述了这种双向验证的逻辑它帮我生成了最终的验证脚本。运行结果非常清晰105 个安全组完全一致发现 2 条规则存在于 AWS 但未在 HCL 中声明立即补充发现了 5 个对应已删除安全组的陈旧 HCL 文件安全移除。3. 模式二基于内部规范的模块脚手架生成如果说导入模式是“治理过去”那么模块脚手架生成就是“规范未来”。它的核心输入不是混乱的现状文件而是你团队内部精心编写的文档和规范。3.1 前提拥有高质量的上下文文档LLM 在这个模式中扮演的角色是一个严格遵循你既定规则的代码生成器。因此你提供的规则必须清晰、完整、无歧义。在我的实践中我准备了三个核心文档作为 LLM 的上下文仓库 README项目级公约阐述项目的层级化运营模型。例如借鉴 Azure Terraform 中“着陆区”的概念将基础设施分为“网络中心”、“共享服务”、“应用环境”等不同层级每个层级有明确的生命周期、权限边界和负责团队。这份文档定义了“什么东西应该放在哪里”的最高原则。即使是在 AWS 项目我们也沿用与 Azure 侧类似的分层逻辑这保证了跨云团队认知的一致性而非为 AWS 创造一套独特的、难以理解的分类法。模块开发指南编码规范这是最关键的文档。它详细规定了标准文件布局一个 Terraform 模块的main.tfvariables.tfoutputs.tfversions.tf应该包含什么。设置对象模式我们是否使用一个复杂的settings对象变量来组织所有配置而非一堆独立的变量。变量规则如何定义变量类型、描述、验证规则以及如何使用optional()修饰符和提供符合公司标准的默认值例如retention_days 30enable_deletion_protection true。输出规范模块应该输出哪些标准化的属性。架构决策记录解释更深层次的“为什么”。例如何时应该创建一个新模块何时应该扩展现有模块模块间如何通过数据源或远程状态进行连接这为 LLM 提供了设计意图的背景。3.2 工作流从需求到生成模块当需要为一个新的 AWS 资源例如一个 Amazon MQ 消息队列创建 Terraform 模块时工作流变得极其高效提供上下文将上述三份文档作为背景信息提供给 LLM。提出需求给出一个具体的提示如“基于我们的模块规范请为 AWS 资源aws_mq_broker创建一个完整的 Terraform 模块。该模块需要支持引擎类型ActiveMQ/RabbitMQ、实例类型、部署模式单实例/集群、加密选项、以及通过settings对象传入的标签。”审查与调整LLM 生成的模块代码会直接遵循你定义的规范正确的文件结构、使用了settings对象模式、变量都带有optional()和你们约定的默认值、输出了必要的属性。它甚至能正确引用 AWS Provider 的版本约束。节省的时间在哪里无需从记忆里回忆文件结构模板。无需翻阅 AWS Provider 文档去确认某个属性如auto_minor_version_upgrade是否可选、类型是什么。无需争论retention_in_days的默认值应该是 7 天还是 30 天因为规范里已经定了。那些通常需要 20-30 分钟来搭建的“样板代码”现在只需要 2-3 分钟就能生成一个高质量初版。3.3 人的角色架构判断与决策LLM 在这里并没有取代工程师。它接管的是已知规则下的机械实施。而以下决策必须由人来做出模块化决策这个aws_mq_broker应该是一个独立模块还是作为某个更大的“消息服务”模块的一部分层级归属这个模块应该部署在哪个层级“共享服务”层还是某个特定的“应用环境”层集成设计它如何与现有的 VPC、安全组、Secrects Manager 等模块连接LLM 可以基于文档中“网络资源在 Level 1”这样的规则将安全组放在正确的层级但它无法理解“为什么”这个 RabbitMQ 集群对业务连续性至关重要因此需要放在具有更高可用性保障的层级。模型可靠地遵循已记录的模式但它不会自行推理这些决策。资源在系统中的归属仍然需要一个理解系统的人来拍板。4. 实践中遇到的挑战与局限性LLM 并非银弹在本次实践中也暴露了一些局限性这些恰恰是使用中需要特别注意的地方。4.1 对“真实上下文”的绝对依赖这是最核心的教训。LLM 只有在“看到”真实文件时才能可靠工作。在导入场景中当我试图让它仅凭描述来推断 HCL 配置结构时它生成的代码看起来合理但与实际文件结构有微妙差异导致错误。一旦我将真实的state.json和.tf文件内容提供给它它的输出准确率立刻大幅提升。在模块生成场景中如果我的文档对“默认值规范”描述模糊LLM 会使用它从海量代码中学到的“常见”默认值这可能不符合我们内部的特定要求例如我们可能要求所有存储类资源默认开启加密而通用训练数据可能不总是这样。模型会将你文档的质量原封不动地反映出来。文档的模糊之处就是输出不确定的地方。4.2 处理复杂与不一致的配置巨型文件问题如前所述让 LLM 直接修改一个 600 行的单体 HCL 文件很容易产生错误或遗漏。将大文件拆分为符合单一职责原则的小文件不仅是软件工程的最佳实践也是让 LLM 高效工作的前提。配置漂移问题在本次多环境项目中四个环境的 Terragrunt 配置竟然存在三种不同的模式。LLM 根据其中两种模式生成的迁移脚本对第三种模式失效了。因为它没有“见过”那种变体。解决方案仍然是提供真实的、包含那种变体的配置文件作为样本。LLM 无法推断它未曾见过的变化。4.3 对复杂逻辑和超大输出的处理能力有限复杂依赖当terraform plan输出显示因复杂的资源依赖例如循环依赖、未被正确建模的隐式依赖导致的错误时LLM 的分析和建议可能流于表面无法深入理解整个依赖图并给出根本性解决方案。这仍然需要工程师的架构洞察。超大plan输出如果terraform plan的输出非常庞大例如涉及数百项变更直接将其全部扔给 LLM 可能会超出其上下文窗口或导致其注意力分散。此时需要人工进行分段或筛选只将最相关的、有问题的部分交给 LLM 分析。5. 总结LLM在Terraform工作中的定位与价值回顾这两个工作流LLM 的价值定位非常清晰它不是一个自主的 DevOps 工程师而是一个能力极强的、速度极快的初级工程师。它擅长执行明确、重复、模式化的任务根据一个范例为十几种不同的 AWS 资源类型生成结构一致的查询代码。解析两种不同格式AWS API JSON 和 HCL的数据进行逻辑转换和差异比对。根据既定规则批量生成数百个格式繁琐且容易出错的 Terraform 导入 ID。依据清晰编写的团队规范快速搭建出一个结构正确、变量定义完整、默认值合理的 Terraform 模块脚手架。而这些任务正是消耗工程师大量时间、令人疲惫且容易出错的“脏活累活”。LLM 将这些工作从小时、天级压缩到分钟、小时级让工程师能够将宝贵的认知资源集中在真正需要判断力和创造力的地方制定策略在混乱中理清头绪决定先做什么、后做什么以及为什么要这么做。做出架构决策判断模块的边界、资源的归属、系统的演进方向。定义规则与规范编写那些 LLM 所依赖的高质量上下文文档。进行最终验证与把关审查 LLM 的输出确保其符合业务和技术目标而不仅仅是语法正确。这种分工在你知道自己在做什么时非常清晰高效。如果你自己对 Terraform 和云架构的理解不深那么 LLM 仍然会生成输出但那只是“看起来自信”的输出而你却缺乏评估其正确性的能力。因此领域专业知识在使用这些工具时变得更加重要而不是更不重要。你的专业知识是导航仪LLM 是强劲的引擎。没有导航仪引擎马力再大也可能带你偏离航线。
