适配ADO流水线的AWS通用Terraform目录结构优化问询

结合你的环境划分需求，推荐一套模块化+分层管理的目录结构，既能复用共享资源，又能通过ADO单参数快速指定环境部署，同时给你流水线方案的选择建议。

目录结构设计 #

terraform-aws-infra/
├── modules/                # 抽离可复用的Terraform组件
│   ├── vpc/                # 包含VPC、子网、路由表、安全组等网络资源
│   ├── eks/                # EKS集群、节点组、IAM角色等组件
│   ├── s3/                 # S3桶及版本控制、加密配置
│   └── rds/                # RDS实例、参数组、备份策略等
├── shared-nonprod/         # nonprod环境共享资源栈（VPC/EKS/S3）
│   ├── main.tf             # 调用vpc、eks、s3模块，定义共享资源
│   ├── variables.tf        # 共享资源的变量声明（比如VPC网段）
│   └── terraform.tfvars    # nonprod共享资源的具体配置
├── environments/           # 各环境专属资源栈
│   ├── dev/
│   │   ├── main.tf         # 只调用rds模块，引用shared-nonprod的VPC/EKS资源
│   │   ├── variables.tf
│   │   └── terraform.tfvars# dev环境RDS的专属配置（实例类型、账号密码）
│   ├── sit/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   ├── uat/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   ├── nft/
│   │   ├── main.tf         # 调用vpc、eks、s3、rds模块，全量独立资源
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── prod/
│       ├── main.tf         # 同nft，全量独立资源配置
│       ├── variables.tf
│       └── terraform.tfvars
└── ado-pipeline-templates/ # ADO流水线yaml模板（可选集中存放）
    └── deploy-infra.yml

适配ADO单参数部署的关键配置 #

1. 流水线参数化 #

在ADO流水线里定义一个名为target_environment的参数，可选值设为dev、sit、uat、nft、prod。流水线根据这个参数走不同的部署逻辑：

• 如果参数是dev/sit/uat：
  1. 先检查shared-nonprod的资源是否已部署（可以通过Terraform状态文件判断，或者加个前置步骤自动部署shared层）
  2. 切换到environments/${{ parameters.target_environment }}目录，执行terraform init、plan、apply
• 如果参数是nft/prod：
  直接切换到对应环境目录，执行完整的Terraform操作（因为这俩环境是独立全量资源，不需要依赖shared层）

2. 状态文件管理 #

用AWS S3存Terraform状态文件，每个栈用独立的状态文件，避免互相影响：

• shared-nonprod：s3://你的状态桶名/nonprod/shared/terraform.tfstate
• dev：s3://你的状态桶名/nonprod/dev/terraform.tfstate
• nft：s3://你的状态桶名/nft/terraform.tfstate
• prod：s3://你的状态桶名/prod/terraform.tfstate
  记得开S3版本控制和服务器端加密，防止状态文件丢失或泄露。

3. 流水线阶段拆分 #

把ADO流水线拆成几个阶段，更可控：

• 初始化：安装指定版本的Terraform，配置AWS访问凭证
• 状态校验：针对nonprod下属环境，确认shared层状态存在；针对nft/prod，确认状态桶配置正确
• 变更预览：执行terraform plan，输出变更内容，prod环境这里一定要加人工审核步骤
• 部署执行：通过审核后，执行terraform apply完成资源部署

流水线方案选择：单流水线还是独立流水线？ #

优先选单流水线（带参数化）的情况 #

• 各环境的部署流程基本一致，只是配置不同
• 想减少流水线维护成本，统一管理模板
• dev/sit/uat/nft这些环境不需要严格的隔离部署流程

建议用独立流水线的情况 #

• prod环境变更风险极高，需要专属的权限控制、多级审批、部署窗口
• nft作为类生产环境，需要和prod保持完全一致的独立部署流程，不跟nonprod混在一起
• 不同环境需要不同的监控、告警机制

如果选单流水线，一定要给prod/nft加额外的人工审批环节，同时通过ADO权限设置，限制不同角色能触发的环境参数（比如普通开发只能触发dev/sit，运维才能触发nft/prod）。

额外优化点 #

• 把所有环境通用的配置（比如AWS区域、资源标签规范）抽成根目录的common.tfvars，每个环境部署时用terraform -var-file=../../common.tfvars引用，减少重复配置
• 给每个模块写个简单的README，说明输入输出参数，方便团队其他人理解使用
• 在ADO流水线里加terraform validate和terraform fmt步骤，确保代码规范，避免低级错误

内容的提问来源于stack exchange，提问作者RavitejaDanda