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

terraform-engineer

部署与运维

查看项目

更新于 10-15 08:47

技能介绍

用途

Terraform Engineer 是一个基础设施即代码（IaC）专家技能，专注于使用 Terraform 和 OpenTofu 进行云资源供给。其目标是设计模块化、可扩展的基础设施，并配合恰当的状态管理、远程后端和 GitOps 驱动的自动化流水线。

主要能力

该技能覆盖以下方面：

  • 供给新的云基础设施，例如 VPC、EKS、RDS。
  • 将单体 Terraform 代码重构为可复用模块。
  • 为基础设施实施 GitOps（如 Atlantis、Terraform Cloud）。
  • 管理远程状态、状态锁定和后端配置。
  • 编写自定义 provider 或复杂 HCL 逻辑（循环、条件）。
  • 将现有手工基础设施迁移或导入到 Terraform。

使用方式

资料中给出的典型工作流包括：

  1. 生产级 AWS VPC（模块化）：通过 versions.tf 定义依赖与版本约束，在 main.tf 中调用社区模块（如 terraform-aws-modules/vpc/aws），并在 outputs.tf 中输出 VPC ID。
  2. 导入现有基础设施：识别资源 ID，编写对应的 Terraform 代码，运行 terraform import（或使用 TF 1.5+ 的 import 块），再通过 terraform plan 反复调整代码直至报告“No changes”。

资料还给出了状态管理策略的决策框架：个人使用本地状态（不推荐用于生产）；小团队使用远程状态加锁定（AWS 用 s3 + DynamoDB，Azure 用 azurerm）；企业使用托管状态与运行（Terraform Cloud、spacelift、env0）；GitOps 使用 PR 驱动的运行（自托管 Atlantis）。

适用场景

资料列举了三个示例场景：

  • 多云端到端着陆区：创建 VPC、IAM、安全组的可复用模块，使用 S3 后端与 DynamoDB 锁定实现远程状态，加入变量校验与前置条件，实现成本估算与预算告警，并设置 Terraform Cloud 进行状态管理。
  • 基于 EKS 的 Kubernetes 平台：创建带托管节点组的 EKS 模块，实现 RBAC 与服务账户，加入网络策略与安全组，配置 Vault 集成的密钥管理，并设置监控与可观测性。
  • 遗留基础设施迁移：使用 terraform import 导入现有资源，创建对应配置，使用 state mv 重组资源，验证导入期间无变更，并将 Terraform 确立为唯一事实来源。

最佳实践

资料中列出的最佳实践包括：

  • 状态管理：始终使用远程状态（S3、GCS、Terraform Cloud）；启用状态锁定以防止并发修改；按环境隔离状态；启用状态版本备份。
  • 模块开发：单一职责，每个模块只做好一件事；锁定模块版本；记录输入、输出与行为；发布前测试模块。
  • 代码质量：一致使用 terraform fmt；运行 terraform validate；使用 tflint 检查 provider 特定问题；使用 tfsec/checkov 进行安全扫描。
  • 协作：所有变更合并前经过代码审查；使用工作区进行环境隔离；使用变量文件而非硬编码；记录重要输出。

限制与注意事项

资料中明确列出的反模式与风险包括：

  • 单体状态文件：一个 main.tf 控制 VPC、数据库、EKS 和大量微服务，会导致爆炸半径大、性能受 API 速率限制影响、锁定阻塞协作。正确做法是拆分状态，并用 terraform_remote_state 数据源读取其他层的输出。
  • 硬编码环境：使用 vpc-prod.tf、vpc-dev.tf 等重复代码文件，会导致环境漂移和双重维护。正确做法是使用工作区配合 var.environment、tfvars 文件或模块复用。
  • 忽略 .gitignore：提交 .terraform/ 目录或 terraform.tfvars（含密钥）会导致仓库膨胀和安全泄露。标准 .gitignore 应包含 .terraform/、.tfstate、.tfstate.backup、*.tfvars，但 .terraform.lock.hcl 应提交。
  • 状态管理反模式：使用本地状态、在 Terraform 之外手工变更、无状态锁定、手工编辑状态文件。
  • 模块反模式：单体模块、硬编码值、模块版本混乱、过深的模块嵌套。
  • 资源反模式：资源泛滥、生命周期锁定、过度使用 ignore_changes、状态中明文密钥。
  • 代码组织反模式：扁平结构、重复代码、未格式化 HCL、缺少文档。

资料还指出，遇到以下红旗应升级给安全工程师：provider 块中硬编码 AWS 密钥、状态文件存储在 git 中（terraform.tfstate）、安全组允许 0.0.0.0/0 访问 SSH/RDP、S3 桶默认公开。

质量检查清单

资料给出的检查项包括：代码质量方面运行 terraform fmt -recursive、terraform validate、tflint，并用 terraform-docs 生成 README；安全方面不使用明文密钥（使用 KMS/Vault/Secrets Manager）、所有存储启用加密（EBS、S3、RDS）、锁定公开访问（S3 Block Public Access）；可靠性方面配置带锁定的远程后端、固定 provider 与 Terraform 版本（如 ~> 5.0）、测试 destroy provisioner 或为数据库启用保护。

工具对比

资料中简要对比了 Terraform 与其他工具：Terraform 使用 HCL（声明式），适合行业标准与庞大生态；Pulumi 使用通用编程语言（TS/Py），适合不喜欢 HCL、需要动态逻辑的开发者；Crossplane 使用 K8s 自定义资源，适合控制平面与自助服务平台；CloudFormation 使用 YAML/JSON，适合 AWS 纯粹主义者（原生漂移检测）。