SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场terraform-module-creator

terraform-module-creator

部署与运维

查看项目

更新于 10-16 04:06

技能介绍

用途

Terraform Module Creator 用于帮助用户从真实的基础设施需求出发，设计和创建 Terraform 模块。它的目标不只是生成 Terraform 文件，而是帮助判断模块是否值得存在、定义清晰的模块职责、塑造干净的接口，并避免过度工程化。最终产出应是可以理解、可维护、在实践中真正有用的 Terraform 模块。

主要能力

  • 判断某个需求是否真的应该做成模块，而不是直接使用普通 Terraform 资源。
  • 区分 building block 模块（聚焦单一基础设施组件的可复用单元）与 composition 模块（组合多个相关资源的高层模式），并优先推荐 building block 模块。
  • 定义模块边界：模块拥有什么、期望消费者提供什么、哪些内容应留在模块之外、哪些依赖应传入而非内部创建。
  • 设计变量与输出：只暴露消费者真正需要设置的输入，使用清晰命名、合理默认值，对枚举型变量（SKU、tier、kind）和名称格式约束添加 validation {} 块；输出只返回可能被使用的值，对包含密钥的输出标记 sensitive = true，并优先输出 principal_id（托管标识）而非连接字符串。
  • 推荐文件结构，并始终创建 examples/basic/ 示例目录，示例是独立可运行的 Terraform 根模块，包含自己的 main.tf、variables.tf、outputs.tf、versions.tf 和 README.md。
  • 生成 .terraform-docs.yml 与 README.md，README 中的输入输出表由 terraform-docs 生成，而非手写。
  • 对具有依赖关系的可选变量（例如 private_endpoint.enabled = true 需要 subnet_id）添加 lifecycle { precondition {} } 块，在创建资源前清晰暴露配置错误。
  • 在生成 versions.tf 前查询 azurerm 最新版本并作为最低约束。
  • 提供评审模式与重构模式：评审已有模块或草稿，或从重复 Terraform 代码中抽取模块，并在重命名或重构资源时建议添加 moved {} 块以避免破坏性变更。

使用方式

该技能按固定流程执行：

  1. 理解需求：调用 azure-azureterraformbestpractices、azure-get_azure_bestpractices、azure-documentation、azure-wellarchitectedframework，获取 Azure Terraform 最佳实践、CAF 命名规范、私有终结点 DNS 区域名称、服务特性行为以及 WAF 支柱建议。
  2. 决定模块类型：调用 mcp_terraform_search_modules 查看现有模块，调用 mcp_terraform_get_module_details 审查其接口，仅作参考而非直接采用。
  3. 定义模块边界。
  4. 设计接口：调用 mcp_terraform_search_providers 按服务 slug 查找资源文档，再用 mcp_terraform_get_provider_details 获取完整参数参考。
  5. 推荐文件结构。
  6. 生成模块：调用 mcp_terraform_get_latest_provider_version(namespace="hashicorp", name="azurerm") 获取最新版本。
  7. 批判性评审结果。

在调用任何 Azure MCP 工具前，需先用 learn=true 或 tool_search_tool_regex 做发现调用，确认准确工具名，不要硬编码可能变化的名称。

验证命令：

terraform fmt -check -recursive .
terraform init -backend=false && terraform validate
tflint --init && tflint
terraform-docs .

运行前需确认工具可用（terraform -version、terraform-docs --version、tflint --version）。若工具缺失，应输出安装命令并停止，不得静默跳过验证步骤。

前置条件

需本地安装以下工具：

  • Terraform：核心 IaC 工具，用于 init、validate、fmt。安装：brew install hashicorp/tap/terraform
  • terraform-docs：从模块源码生成 README 输入输出。安装：brew install terraform-docs
  • tflint：静态分析，捕获废弃参数和 provider 特定问题。安装：brew install tflint
  • tflint-ruleset-azurerm：Azure 专用 tflint 规则，通过 .tflint.hcl 配置。

最低版本：Terraform ≥ 1.2（lifecycle precondition/postcondition 所需）、terraform-docs ≥ 0.16、tflint ≥ 0.50。

适用场景

  • 用户希望从需求或场景创建新的 Terraform 模块。
  • 重复出现的 Terraform 模式可能需要成为共享模块。
  • 团队需要帮助塑造模块输入、输出和范围。
  • 平台团队希望定义可复用的 Terraform 模式，同时避免不必要的抽象。
  • 评审是否使用普通 Terraform 资源比引入新模块更好。
  • 创建需要符合平台标准和运维预期的 Azure 相关 Terraform 模块。

核心原则

  • KISS：模块应易于理解、消费和支持。
  • 有判断的 DRY：减少有意义的重复，但不为抽象而抽象。
  • 清晰职责：模块应良好解决一个连贯问题。
  • 实用复用：为真实重复需求构建模块，而非假设的未来场景。
  • 可读接口：变量、输出、默认值和命名应显而易见且可预测。
  • 可运维支持：团队应能理解模块做什么以及如何使用，而无需对抗不必要的复杂性。
  • 安全合理的默认值：在能减少重复劳动和不一致时保持主见，但不隐藏关键行为。

限制

  • 该技能面向 Azure 场景，依赖 Azure MCP Server 与 HashiCorp Terraform Registry MCP。
  • 需要本地安装 Terraform、terraform-docs、tflint 等工具，否则无法完成验证步骤。
  • 不假设新建自定义模块总是最佳答案；若模块不合理，应明确说明。
  • 不应在模块内创建 VNet 或 DNS 区域。
  • 关于具体收费、价格、平台支持范围等事实，资料未提供。