Terraform多环境工作目录管理与状态后端隔离实战

Terraform工作目录与多环境架构设计

Terraform基础设施即代码管理多套环境（dev/staging/prod）时，工作目录（Workdir）和状态文件（State）的隔离是最基础也是最关键的架构决策。状态文件包含资源的真实ID和属性映射，一旦混用将导致生产环境被误删或覆盖。主流的多环境管理模式有两种：目录隔离模式和Workspace隔离模式。目录隔离模式为每个环境创建独立的Terraform配置目录，各自维护独立的state文件；Workspace模式在同一目录下通过Terraform Workspace切换隔离状态。

目录隔离模式更适合生产环境，因为状态文件物理隔离、权限边界清晰、CI/CD流水线天然匹配各环境目录。Workspace模式适合个人开发或小型项目，但状态文件共享同一后端路径，误操作风险较高。

目录隔离模式的配置结构

infra/
├── modules/                  # 共享模块
│   ├── vpc/
│   ├── ec2/
│   └── rds/
├── envs/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── backend.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   │   └── ... (同结构)
│   └── prod/
│       └── ... (同结构)
└── shared/                   # 跨环境共享资源

各环境的main.tf通过模块引用保持配置逻辑一致，仅通过变量差异化：

# envs/dev/main.tf
module "vpc" {
  source     = "../../modules/vpc"
  cidr_block = var.vpc_cidr
  env        = "dev"
  az_count   = 2
}

module "ec2" {
  source        = "../../modules/ec2"
  instance_type = var.instance_type
  subnet_ids    = module.vpc.private_subnet_ids
  env           = "dev"
}

# envs/prod/main.tf - 同结构，变量不同
module "vpc" {
  source     = "../../modules/vpc"
  cidr_block = var.vpc_cidr
  env        = "prod"
  az_count   = 3
}

远程状态后端配置与隔离策略

状态后端配置是目录隔离的核心。各环境使用独立的S3路径或Azure Blob容器，确保状态文件绝对隔离：

# envs/dev/backend.tf
terraform {
  backend "s3" {
    bucket         = "tf-state-yunthe"
    key            = "dev/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "tf-lock-dev"
  }
}

# envs/prod/backend.tf
terraform {
  backend "s3" {
    bucket         = "tf-state-yunthe"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "tf-lock-prod"
  }
}

S3后端的encrypt参数确保状态文件加密存储，dynamodb_table配置状态锁防止并发操作冲突。每个环境使用独立的DynamoDB锁表，避免锁竞争。

跨环境变量差异化与tfvars管理

# envs/dev/terraform.tfvars
vpc_cidr       = "10.0.0.0/16"
instance_type  = "t3.medium"
db_instance    = "db.t3.medium"
max_capacity   = 2
min_capacity   = 1
enable_monitoring = true

# envs/prod/terraform.tfvars
vpc_cidr       = "10.1.0.0/16"
instance_type  = "m6i.xlarge"
db_instance    = "db.r6g.xlarge"
max_capacity   = 10
min_capacity   = 3
enable_monitoring = true
multi_az       = true
backup_retention = 30

敏感变量如数据库密码、API密钥不应写入tfvars文件，而是通过环境变量或Vault注入：

# 通过环境变量传入敏感值
export TF_VAR_db_password="$(vault read -field=password secret/prod/db)"

# variables.tf中标记为sensitive
variable "db_password" {
  type      = string
  sensitive = true
}

CI/CD流水线中的Terraform多环境自动化

多环境Terraform的CI/CD流水线需要严格的环境门控。dev环境可自动plan加apply，staging需要人工审批，prod必须双人审批：

# GitHub Actions示例
name: Terraform Deploy
on:
  push:
    paths:
      - 'infra/**'

jobs:
  terraform-plan:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        env: [dev, staging, prod]
    steps:
      - uses: actions/checkout@v4
      - name: Terraform Init
        run: terraform -chdir=infra/envs/${{ matrix.env }} init
      - name: Terraform Plan
        run: terraform -chdir=infra/envs/${{ matrix.env }} plan -out=tfplan

  prod-apply:
    needs: terraform-plan
    if: github.ref == 'refs/heads/main'
    environment: production
    runs-on: ubuntu-latest
    steps:
      - name: Terraform Apply
        run: terraform -chdir=infra/envs/prod apply -auto-approve

流水线关键安全策略：prod环境的apply操作必须绑定GitHub Environment审批保护规则，至少一名reviewer确认后方可执行。plan输出必须经过人工审查，重点关注资源销毁和强制替换操作。state文件损坏是Terraform运维中最棘手的问题，定期备份S3版本控制是必备措施。