Back to Details

manage-iacm

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Manage IaCM

管理IaCM

Configure Terraform workspaces, drift detection, change approval workflows, and cost estimation in Harness Infrastructure as Code Management.
在Harness基础设施即代码管理中配置Terraform工作区、漂移检测、变更审批工作流和成本估算。

Instructions

操作说明

Step 1: Establish Scope

步骤1：确定范围

Confirm the user's org, project, cloud provider, and environments.
Call MCP tool: harness_list
Parameters:
  resource_type: "project"
  org_id: "<organization>"
确认用户的组织、项目、云提供商和环境。
Call MCP tool: harness_list
Parameters:
  resource_type: "project"
  org_id: "<organization>"

Step 2: Identify the IaCM Task

步骤2：确定IaCM任务

Determine which workflow the user needs:
  1. Workspace and State Management -- Workspace structure, remote state, RBAC, module registry
  2. Drift Detection -- Continuous drift scanning with remediation workflows
  3. Change Approval Workflows -- Risk-based approval tiers for infrastructure changes
  4. Cost Estimation -- Pre-deployment cost impact analysis using Infracost
判断用户需要的工作流类型：
  1. 工作区与状态管理 -- 工作区结构、远程状态、RBAC、模块注册表
  2. 漂移检测 -- 具备修复工作流的持续漂移扫描
  3. 变更审批工作流 -- 针对基础设施变更的基于风险的审批层级
  4. 成本估算 -- 使用Infracost进行部署前成本影响分析

Step 3: Configure Workspaces and State Management

步骤3：配置工作区与状态管理

Gather from the user:
  • Cloud provider (AWS, GCP, Azure, multi-cloud)
  • Environments to manage (dev, staging, prod)
  • Workspace naming convention (e.g., {project}-{env}-{region})
  • State backend preference (S3+DynamoDB, GCS+Firestore, Azure Blob, Harness built-in)
Design workspace structure:
  • One workspace per environment per account
  • Remote state backend with encryption at rest and state locking
  • State backup with versioning and configurable retention
  • RBAC: Developer=plan only, Senior Dev=plan+apply to dev, Team Lead=staging, DevOps=all with prod approval
Configure module registry:
  • Semantic versioning for modules
  • Security scanning before module publication (Checkov, tfsec, Terrascan)
  • Approval workflow for new module versions
向用户收集以下信息：
  • 云提供商（AWS、GCP、Azure、多云）
  • 需管理的环境（开发、预发布、生产）
  • 工作区命名规范（例如：{project}-{env}-{region}）
  • 状态后端偏好（S3+DynamoDB、GCS+Firestore、Azure Blob、Harness内置）
设计工作区结构：
  • 每个账户的每个环境对应一个工作区
  • 具备静态加密和状态锁定功能的远程状态后端
  • 带有版本控制和可配置保留期的状态备份
  • RBAC权限：开发人员=仅执行plan，资深开发人员=可在开发环境执行plan+apply，团队负责人=可操作预发布环境，DevOps=可操作所有环境且生产环境需审批
配置模块注册表：
  • 模块采用语义化版本控制
  • 模块发布前进行安全扫描（Checkov、tfsec、Terrascan）
  • 新版本模块需经过审批工作流

Step 4: Set Up Drift Detection

步骤4：设置漂移检测

Gather from the user:
  • Environments to monitor
  • Scan frequency (hourly, every 6 hours, daily)
  • Resources to exclude from drift scanning
Configure drift detection:
  • Compare actual cloud resources against Terraform state on schedule
  • Detect additions, deletions, and modifications outside Terraform control
  • Classify drift by severity: critical (security group changes, IAM), warning (tags, descriptions), info (metadata)
Remediation workflows:
  • Auto-remediate low-risk drift (tag corrections, description updates)
  • Alert and create ticket for medium-risk drift
  • Page on-call for critical drift (security-related changes)
向用户收集以下信息：
  • 需监控的环境
  • 扫描频率（每小时、每6小时、每日）
  • 需排除在漂移扫描外的资源
配置漂移检测：
  • 按计划将实际云资源与Terraform状态进行对比
  • 检测Terraform管控之外的资源新增、删除和修改
  • 按严重程度分类漂移：严重（安全组变更、IAM）、警告（标签、描述）、信息（元数据）
修复工作流：
  • 自动修复低风险漂移（标签修正、描述更新）
  • 针对中风险漂移发送警报并创建工单
  • 针对严重漂移（安全相关变更）通知值班人员

Step 5: Design Change Approval Workflows

步骤5：设计变更审批工作流

Gather risk categories from the user:
  • Low risk (e.g., tag changes, scaling adjustments) -- auto-apply after peer review
  • Medium risk (e.g., new resources, config changes) -- team lead approval
  • High risk (e.g., security groups, IAM, database changes) -- security team + CAB approval
  • Emergency (break-glass) -- post-implementation review required
Call MCP tool: harness_create
Parameters:
  resource_type: "pipeline"
  org_id: "<organization>"
  project_id: "<project>"
  body:
    pipeline:
      name: "terraform-change-approval"
      identifier: "terraform_change_approval"
      stages:
        - stage:
            name: Plan
            type: CI
            spec:
              # terraform plan + output change summary
        - stage:
            name: Cost Estimate
            type: CI
            spec:
              # infracost diff
        - stage:
            name: Approval
            type: Approval
            spec:
              # risk-based approval routing
        - stage:
            name: Apply
            type: CI
            spec:
              # terraform apply
向用户收集风险类别：
  • 低风险（例如：标签变更、扩容调整）-- 同行评审后自动应用
  • 中风险（例如：新增资源、配置变更）-- 团队负责人审批
  • 高风险（例如：安全组、IAM、数据库变更）-- 安全团队+CAB审批
  • 紧急情况（应急通道）-- 需事后进行回顾审查
Call MCP tool: harness_create
Parameters:
  resource_type: "pipeline"
  org_id: "<organization>"
  project_id: "<project>"
  body:
    pipeline:
      name: "terraform-change-approval"
      identifier: "terraform_change_approval"
      stages:
        - stage:
            name: Plan
            type: CI
            spec:
              # terraform plan + output change summary
        - stage:
            name: Cost Estimate
            type: CI
            spec:
              # infracost diff
        - stage:
            name: Approval
            type: Approval
            spec:
              # risk-based approval routing
        - stage:
            name: Apply
            type: CI
            spec:
              # terraform apply

Step 6: Estimate Infrastructure Costs

步骤6：估算基础设施成本

When asked for cost estimation:
  • Identify the workspace and pending Terraform changes (PR or plan output)
  • Run Infracost analysis on the plan
Present a cost report with:
  • Current monthly cost vs. projected monthly cost
  • Per-resource cost breakdown for new/modified resources
  • Cost optimization recommendations (right-sizing, reserved instances)
  • Budget impact assessment
当用户请求成本估算时：
  • 确定工作区和待处理的Terraform变更（PR或plan输出）
  • 对plan运行Infracost分析
呈现成本报告，包含：
  • 当前月度成本 vs 预计月度成本
  • 新增/修改资源的按资源成本明细
  • 成本优化建议（合理配置、预留实例）
  • 预算影响评估

Examples

示例

  • "Set up Terraform workspaces for our AWS environments" -- Configure workspace structure with state management and RBAC
  • "Enable drift detection for production infrastructure" -- Set up scheduled scanning with severity classification and remediation
  • "Create an approval workflow for infrastructure changes" -- Design risk-based approval tiers with security review for high-risk changes
  • "How much will this Terraform change cost?" -- Run Infracost analysis and present cost impact report
  • "Configure our Terraform module registry" -- Set up versioned module registry with security scanning
  • "为我们的AWS环境设置Terraform工作区" -- 配置带有状态管理和RBAC的工作区结构
  • "为生产基础设施启用漂移检测" -- 设置带有严重程度分类和修复功能的定时扫描
  • "为基础设施变更创建审批工作流" -- 设计基于风险的审批层级，高风险变更需安全团队审核
  • "这个Terraform变更会花费多少钱？" -- 运行Infracost分析并呈现成本影响报告
  • "配置我们的Terraform模块注册表" -- 设置带有安全扫描的版本化模块注册表

Performance Notes

性能注意事项

  • Workspace naming conventions should be established early -- renaming workspaces requires state migration.
  • Drift detection scans should avoid peak hours to minimize API rate limit conflicts.
  • Cost estimation accuracy depends on Infracost having pricing data for all resource types in use.
  • Change approval workflows should include a break-glass path for emergencies -- blocking all changes can be as dangerous as no controls.
  • 应尽早确定工作区命名规范 -- 重命名工作区需要迁移状态。
  • 漂移检测扫描应避开高峰时段，以减少API速率限制冲突。
  • 成本估算的准确性取决于Infracost是否拥有所用所有资源类型的定价数据。
  • 变更审批工作流应包含紧急情况的应急通道 -- 阻止所有变更可能和没有管控一样危险。

Troubleshooting

故障排除

State Locking Conflicts

状态锁定冲突

  • Check for stuck locks from failed runs -- use 
    terraform force-unlock
    cautiously
  • Verify the state backend (DynamoDB, Firestore) is accessible from the runner
  • 检查是否存在因运行失败导致的锁定残留 -- 谨慎使用
    terraform force-unlock
  • 验证状态后端（DynamoDB、Firestore）可被运行器访问

Drift Detection False Positives

漂移检测误报

  • Exclude resources managed by auto-scaling groups or Kubernetes operators
  • Add ignore rules for metadata fields that change frequently (last-modified timestamps)
  • Verify the scan is running against the correct workspace/state file
  • 排除由自动扩缩容组或Kubernetes控制器管理的资源
  • 为频繁变更的元数据字段（最后修改时间戳）添加忽略规则
  • 验证扫描针对的是正确的工作区/状态文件

Cost Estimation Missing Resources

成本估算遗漏资源

  • Infracost may not support all resource types -- check supported resource list
  • Ensure the Terraform plan output includes all changed resources
  • Custom modules may need explicit cost annotations
  • Infracost可能不支持所有资源类型 -- 查看支持的资源列表
  • 确保Terraform plan输出包含所有变更的资源
  • 自定义模块可能需要明确的成本注释