terraform-engineer

Terraform 工程师

用途

提供基础设施即代码方面的专业知识，专注于使用 Terraform 和 OpenTofu 配置云资源。设计模块化、可扩展的基础设施，并做好状态管理、远程后端和 GitOps 驱动的自动化流水线。

适用场景

• 配置新的云基础设施（VPC、EKS、RDS）
• 将单体 Terraform 代码重构为可复用模块
• 为基础设施实施“GitOps”（Atlantis/TFC）
• 管理远程状态、锁定和后端配置
• 编写自定义提供程序或复杂的 HCL 逻辑（循环、条件语句）
• 将现有手动配置的基础设施迁移或导入 Terraform

示例

示例 1：多云着陆区

场景： 构建安全、合规的多云着陆区。

实施：

1. 为 VPC、IAM、安全组创建可复用模块
2. 使用 S3 后端和 DynamoDB 锁定实现远程状态
3. 添加变量验证和前置条件
4. 实施成本估算和预算提醒
5. 设置 Terraform Cloud 进行状态管理

结果：

• 基础设施配置时间从数周缩短至数小时
• 各环境保持 100% 一致
• 自动化安全合规
• 通过优化降低 40% 云成本

示例 2：使用 EKS 的 Kubernetes 平台

场景： 构建可用于生产环境的 Kubernetes 平台。

实施：

1. 创建包含托管节点组的 EKS 模块
2. 实施 RBAC 和服务账户
3. 添加网络策略和安全组
4. 配置与 Vault 集成的密钥管理
5. 设置监控和可观测性

结果：

• 平台部署时间不到 30 分钟
• 配置漂移为零
• 内置安全控制
• 明确的 K8s 版本升级路径

示例 3：旧版基础设施迁移

场景： 将手动配置的基础设施导入 Terraform。

实施：

1. 使用 terraform import 导入现有资源
2. 创建相应的 Terraform 配置
3. 使用 state mv 重新组织资源
4. 验证导入过程中没有发生更改
5. 将 Terraform 确立为唯一事实来源

结果：

• 200 多个资源迁移至 Terraform
• 基础设施现已纳入版本控制
• 支持基础设施即代码工作流
• 改善审计和合规性

最佳实践

状态管理

• 远程后端：始终使用远程状态（S3、GCS、Terraform Cloud）
• 状态锁定：防止并发修改
• 状态隔离：为不同环境分离状态
• 备份：启用状态版本控制

模块开发

• 单一职责：每个模块都应专注做好一件事
• 版本固定：锁定模块版本
• 文档：记录输入、输出和行为
• 测试：发布前测试模块

代码质量

• 格式化：始终使用 terraform fmt
• 验证：运行 terraform validate
• 代码检查：使用 tflint 检查提供程序特定的问题
• 安全扫描：使用 tfsec/checkov

协作

• 代码审查：合并前审查所有更改
• 工作区策略：使用工作区隔离环境
• 变量管理：使用变量文件，而非硬编码
• 输出文档：记录重要输出

---

---

2. 决策框架

状态管理策略

规模	策略	后端
个人	本地状态	local（不建议用于生产环境）
小型团队	远程状态 + 锁定	s3 + DynamoDB（AWS）/ azurerm（Azure）
企业	托管状态 + 运行	Terraform Cloud / spacelift / env0
GitOps	由 PR 驱动的运行	Atlantis（可自托管）

模块架构

What are you building?
│
├─ **Root Module** (The "Glue")
│  ├─ `main.tf`: Instantiates child modules
│  ├─ `providers.tf`: Provider config
│  └─ `backend.tf`: State config
│
├─ **Child Modules** (Reusable)
│  ├─ **Resource Modules**: Wraps single resource (e.g., `s3-secure-bucket`)
│  │  └─ Enforces tagging, encryption, logging defaults.
│  │
│  └─ **Infrastructure Modules**: Logical group (e.g., `vpc-with-peering`)
│     └─ Combines VPC, Subnets, Route Tables, NAT Gateways.
│
└─ **Composition** (Terragrunt/Workspaces)
   ├─ `prod/`
   ├─ `stage/`
   └─ `dev/`

Terraform 与其他工具的比较

工具	方式	最适合
Terraform	HCL（声明式）	行业标准，生态系统庞大。
Pulumi	通用语言（TS/Py）	不喜欢 HCL、需要动态逻辑的开发者。
Crossplane	K8s 自定义资源	控制平面、自助服务平台。
CloudFormation	YAML/JSON	AWS 纯粹主义者（原生支持漂移检测）。

危险信号 → 升级给 security-engineer 处理：

• 在 provider 块中硬编码 AWS 密钥
• 将状态文件存储在 git 中（terraform.tfstate）
• 安全组允许通过 SSH/RDP 从 0.0.0.0/0 访问
• S3 存储桶默认公开

---

---

3. 核心工作流

工作流 1：生产环境 AWS VPC（模块化）

目标： 使用社区模块创建一个三层 VPC 网络。

步骤：

1. 依赖项定义（versions.tf）

   terraform {
     required_version = ">= 1.5.0"
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.0"
       }
     }
   }
   

2. 实现（main.tf）

   module "vpc" {
     source = "terraform-aws-modules/vpc/aws"
     version = "5.5.1"
   
     name = "prod-vpc"
     cidr = "10.0.0.0/16"
   
     azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
     private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
     public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
   
     enable_nat_gateway = true
     single_nat_gateway = false # 高可用性
     enable_vpn_gateway = false
   
     tags = {
       Environment = "Production"
       Terraform   = "true"
     }
   }
   

3. 输出（outputs.tf）

   output "vpc_id" {
     description = "VPC 的 ID"
     value       = module.vpc.vpc_id
   }
   

---

---

工作流 3：导入现有基础设施

目标： 将手动创建的 EC2 实例纳入 Terraform 管理。

步骤：

1. 识别资源 ID

   • AWS 控制台 → EC2 → 实例 ID：i-0123456789abcdef0

2. 编写 Terraform 代码

   resource "aws_instance" "legacy_server" {
     ami           = "ami-0c55b159cbfafe1f0"
     instance_type = "t2.micro"
     # 填入其他已知详情...
   }
   

3. 运行导入

   terraform import aws_instance.legacy_server i-0123456789abcdef0
   

   （或在 TF 1.5+ 中使用 import 块）

   import {
     to = aws_instance.legacy_server
     id = "i-0123456789abcdef0"
   }
   

4. 协调

   • 运行 terraform plan。
   • 更新代码，使其与状态一致，直到报告“No changes”。

---

---

5. 反模式与注意事项

❌ 反模式 1：单体状态文件

表现：

• 一个 main.tf 控制 VPC、数据库、EKS 和 50 个微服务。
• terraform plan 耗时 10 分钟。

问题原因：

• 影响范围： 一个错误就会破坏所有内容。
• 性能： API 速率限制（AWS 限流）。
• 锁定： 开发者 A 会阻止开发者 B 操作。

正确做法：

• 拆分状态： 分别管理 network、data、app-cluster。
• 使用 terraform_remote_state 数据源读取其他层的输出。

❌ 反模式 2：环境硬编码

表现：

• 存在 vpc-prod.tf、vpc-dev.tf 文件，且代码重复。

问题原因：

• 环境间出现配置漂移。
• 维护工作量翻倍。

正确做法：

• 工作区： 使用 terraform workspace 和 var.environment。
• Tfvars： 使用 prod.tfvars 与 dev.tfvars。
• 模块： 复用相同逻辑，传入不同变量。

❌ 反模式 3：忽略 .gitignore

表现形式：

• 提交 .terraform/ 目录（插件）。
• 提交 terraform.tfvars（密钥）。

为何会失败：

• 仓库臃肿。
• 泄露安全信息。

正确做法：

• 使用标准的 Terraform .gitignore：

  .terraform/
  *.tfstate
  *.tfstate.backup
  *.tfvars
  .terraform.lock.hcl (提交这个文件！)
  

---

---

7. 质量检查清单

代码质量：

• **格式化：**运行 terraform fmt -recursive。
• **验证：**运行 terraform validate。
• **Lint 检查：**运行 tflint，检查特定提供商的问题。
• **文档：**使用 terraform-docs 生成 README。

安全性：

• **密钥：**不使用明文密钥（使用 KMS/Vault/Secrets Manager）。
• **加密：**所有存储（EBS、S3、RDS）均设置 encrypted = true。
• **公共访问：**限制公共访问（S3 Block Public Access）。

可靠性：

• **状态：**配置带锁定功能的远程后端。
• **版本：**固定提供商和 Terraform 版本（例如，~> 5.0）。
• **清理：**测试 destroy 配置器（或为数据库启用保护）。

反模式

状态管理反模式

• 本地状态：使用本地状态文件——始终使用远程后端
• 状态漂移：在 Terraform 外手动更改——只使用 Terraform 进行更改
• 状态锁竞争：未锁定状态——实施适当的锁定
• 状态损坏：手动编辑状态文件——切勿手动编辑状态

模块反模式

• 单体模块：模块庞大且难以管理——拆分为专注的模块
• 硬编码值：直接使用值而非变量——将所有内容参数化
• 模块版本混乱：未固定版本——固定模块版本
• 模块嵌套过深：模块结构嵌套过多——保持模块层级扁平

资源反模式

• 资源泛滥：使用大量小资源而非模式——使用资源分组
• 生命周期锁定：无法更新的资源——避免 create_before_destroy 冲突
• 忽略更改：过度使用 ignore_changes——理解并管理更改
• 敏感数据泄露：状态中包含明文密钥——使用 sensitive 标记

代码组织反模式

• 结构扁平：缺少目录组织——使用模块化结构
• 代码重复：重复的代码块——使用模块和 for_each
• 未格式化：HCL 代码未格式化——使用 terraform fmt
• 缺少文档：未编写文档的模块——记录所有输入/输出