如何基于 Terraform Workspace 实现多环境隔离？ - 问题详情 - 创脉思

解读

在国内云原生落地场景中，“一套代码、多套环境”是合规与降本的双重要求。Terraform Workspace 是官方推荐的多环境手段，它通过同一套 .tf 文件 + 不同 state 文件实现逻辑隔离，避免传统“文件夹拷贝”带来的配置漂移。面试官想确认你是否能把 Workspace 与 Google Cloud SQL 的项目级隔离、网络隔离、IAM 隔离、计费隔离结合起来，给出可落地的中国方案，而非仅仅背诵 terraform workspace new 命令。

知识点

Workspace 本质：backend 里为每个环境生成独立 tfstate，key 前缀为 env:/<workspace>/，保证华东/华北地域团队并发写不冲突。
变量分层：用 terraform.tfvars.d/<workspace>.tfvars 覆盖 instance_tier、disk_size、availability_type、database_version；通过 google_client_config 获取当前地域，自动拼出符合中国备案要求的实例名如“gd-sql-prod-01”。
Project 映射：国内多项目下，每个环境单独一个 GCP Project（便于走国内账单主体），用 workspace 名作为 project_id 后缀，例如“demo-sql-<workspace>”，通过 data “google_projects” 过滤并设置 provider alias，满足金融客户“生产项目必须独立账单”的审计要求。
网络隔离：
- dev 环境使用 Public IP + 授权网络白名单（办公网出口），降低 VPC 成本；
- staging 使用 Private Service Connect + 共享 VPC，模拟生产网络路径；
- prod 使用 Private IP + 专用 VPC + 自定义路由，并开启 SQL Proxy 私网接入，符合等保 2.0 对数据库“禁止公网直连”条款。
IAM 隔离：借助 workspace 变量 “env_type”，在 prod 环境下给 cloudsql.admin 角色加 “条件属性：request.time < 18:00+08:00”，实现**“下班时间禁止高危操作”**的国内运维规范。
State 加锁：GCS backend 开启统一存储桶 + 对象版本 + 华东多区域，并配置“uniform_bucket_level_access”与“bucket_policy_only”，防止因跨境复制导致的合规风险。
敏感数据：用 google_secret_manager_secret 存放 root 密码，workspace 名作为 secret_id 后缀，确保 dev 无法读取 prod 密码；同时开启 CMEK（Customer Managed Encryption Key），密钥轮换周期 90 天，满足《个人信息保护法》对“敏感数据加密密钥定期更换”要求。
CI/CD 集成：在 Cloud Build 或 GitLab-Runner 中，用 “terraform workspace select ${CI_COMMIT_REF_SLUG}” 动态匹配分支，实现 feature 分支自动创建销毁临时环境，节省 30% 以上测试资源。

答案

步骤一：初始化后端

terraform {
  backend "gcs" {
    bucket = "demo-terraform-state-cn"
    prefix = "cloudsql/env"
  }
}

步骤二：创建并切换工作区

terraform workspace new prod
terraform workspace select prod

步骤三：定义环境变量文件
env/prod.tfvars

project_id          = "demo-sql-prod"
region              = "cn-north1"
tier                = "db-n1-standard-4"
disk_size           = 200
availability_type   = "REGIONAL"
deletion_protection = true
backup_enabled      = true

步骤四：主文件根据 workspace 名动态赋值

locals {
  env = terraform.workspace
}
module "cloudsql" {
  source              = "./modules/cloudsql"
  project_id          = var.project_id
  region              = var.region
  tier                = var.tier
  disk_size           = var.disk_size
  availability_type   = var.availability_type
  deletion_protection = local.env == "prod" ? true : false
  ip_configuration = {
    ipv4_enabled    = local.env == "dev" ? true : false
    private_network = local.env != "dev" ? data.google_compute_network.vpc.id : null
    require_ssl     = local.env == "prod" ? true : false
  }
}

步骤五：应用

terraform plan  -var-file="env/${TF_WORKSPACE}.tfvars"
terraform apply -var-file="env/${TF_WORKSPACE}.tfvars"

通过以上配置，同一套代码在 dev/staging/prod 三个工作区生成三套独立 state，分别落在不同 project、不同网络、不同 IAM 边界，实现逻辑与物理双重隔离，且满足国内等保、备案、账单独立三大合规要求。

拓展思考

如果企业已用 Anthos Config Management 做 GitOps，可把 workspace 名注入 ConfigMap，让 Config Controller 自动为每个环境生成 CloudSQL 自定义资源，实现**“Terraform 不落地”**的声明式治理。
面对跨国容灾需求，可结合 Cross-region Replication 与 workspace 变量 “primary_region”，在 prod 工作区里一键创建上海→香港异步只读实例，并通过 CMEK 密钥多区域授权解决跨境密钥合规问题。
国内大客户常要求**“灰度发布”**，可在 prod workspace 内部再切 “blue/green” 子工作区，利用 Cloud SQL 实例克隆 + 标记流量实现零停机数据库版本升级；灰度完成后再 terraform state mv 回 prod，保证回滚窗口 < 5 分钟。