纯Terraform环境下多项目依赖管理及变更触发实现方案咨询

Hi，针对你提到的VPC和EKS两个独立Terraform项目的依赖管理需求——既要让EKS能获取VPC的输出值，又要保证两个项目独立部署、控制影响范围，还要在流水线里自动检测变更触发更新，我来给你拆解下纯Terraform的可行方案，正好你考虑的两种思路都能落地，我分别讲下细节和适配流水线的方法：

哦对了，先提个小细节：你VPC项目里的subnet_2_id输出写错啦，value应该是aws_subnet.main2.id，不然会输出两个相同的子网ID，这个得修正下哦。

一、使用Terraform Remote State数据源（最原生的纯Terraform方案） #

这是Terraform官方推荐的跨项目共享状态的方式，完全不需要额外工具，完美适配你想要的纯Terraform场景。

1. 先给VPC项目配置远程状态存储 #

首先得确保你的VPC项目把状态存储到远程后端（AWS环境下最常用的就是S3+DynamoDB做状态锁，防止多人操作冲突），比如在VPC项目里创建backend.tf：

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket" # 替换成你的S3桶名
    key            = "vpc/terraform.tfstate"
    region         = "us-east-1" # 替换成你的AWS区域
    dynamodb_table = "your-terraform-lock-table" # 替换成你的DynamoDB锁表名
  }
}

部署VPC项目后，它的输出（vpc_id、子网ID等）就会存在这个远程状态文件里。

2. 在EKS项目中直接引用VPC的远程状态 #

在EKS项目的main.tf里添加data "terraform_remote_state"块，直接读取VPC的远程状态输出，这样连变量都不用定义了：

data "terraform_remote_state" "vpc" {
  backend = "s3"
  config = {
    bucket = "your-terraform-state-bucket"
    key    = "vpc/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_eks_cluster" "example" {
  name     = "example"
  role_arn = "arn:myawsrole/accnt"
  vpc_config {
    subnet_ids = [
      data.terraform_remote_state.vpc.outputs.subnet_1_id,
      data.terraform_remote_state.vpc.outputs.subnet_2_id
    ]
  }

  depends_on = [
    aws_iam_role_policy_attachment.example-AmazonEKSClusterPolicy,
    aws_iam_role_policy_attachment.example-AmazonEKSVPCResourceController,
  ]
}

3. 流水线里检测变更触发更新 #

在你的CI/CD流水线（比如GitHub Actions、GitLab CI）里，可以这么配置：

• 单独维护VPC项目的部署流水线：只有当VPC的代码有变更时，才运行terraform apply，更新远程状态
• EKS项目的流水线：先执行terraform plan，如果输出里显示有资源需要更新（比如子网ID变化导致EKS集群的VPC配置要更新），就自动触发terraform apply；或者你也可以用脚本对比EKS项目当前状态和VPC远程状态的输出值，一旦发现不一致就触发部署。

二、使用AWS SSM Parameter Store存储输出（适合跨工具/跨团队场景） #

如果你的场景需要更灵活的共享（比如其他非Terraform工具也要用到这些VPC信息），用SSM参数存储是个不错的选择，纯Terraform也能轻松实现。

1. 在VPC项目中把输出写入SSM #

修改VPC项目的main.tf，添加aws_ssm_parameter资源，把需要共享的输出写入SSM参数：

resource "aws_ssm_parameter" "vpc_id" {
  name  = "/terraform/vpc/main/id"
  type  = "String"
  value = aws_vpc.main.id
}

resource "aws_ssm_parameter" "subnet_1_id" {
  name  = "/terraform/vpc/main/subnet_1_id"
  type  = "String"
  value = aws_subnet.main1.id
}

resource "aws_ssm_parameter" "subnet_2_id" {
  name  = "/terraform/vpc/main/subnet_2_id"
  type  = "String"
  value = aws_subnet.main2.id
}

部署VPC项目后，这些值就会存在SSM里，而且当VPC资源有变更时，SSM参数会自动更新。

2. 在EKS项目中读取SSM参数 #

在EKS项目里用data "aws_ssm_parameter"读取这些参数值：

data "aws_ssm_parameter" "subnet_1_id" {
  name = "/terraform/vpc/main/subnet_1_id"
}

data "aws_ssm_parameter" "subnet_2_id" {
  name = "/terraform/vpc/main/subnet_2_id"
}

resource "aws_eks_cluster" "example" {
  name     = "example"
  role_arn = "arn:myawsrole/accnt"
  vpc_config {
    subnet_ids = [
      data.aws_ssm_parameter.subnet_1_id.value,
      data.aws_ssm_parameter.subnet_2_id.value
    ]
  }

  depends_on = [
    aws_iam_role_policy_attachment.example-AmazonEKSClusterPolicy,
    aws_iam_role_policy_attachment.example-AmazonEKSVPCResourceController,
  ]
}

3. 流水线里检测变更触发更新 #

在流水线里可以这么操作：

• VPC项目部署完成后，用AWS CLI获取SSM参数的版本号，或者直接记录当前参数值，存储在流水线的缓存或变量里
• EKS项目的流水线先检查SSM参数的当前值和上次部署时记录的值是否一致，如果不一致，就执行terraform plan和apply；或者直接执行terraform plan，Terraform会自动检测到SSM参数的变化并生成变更计划，你可以设置流水线自动执行apply当有变更时。

两种方案的对比 #

• Remote State方案：最贴合Terraform原生生态，不需要额外的AWS资源（除了状态存储的S3和DynamoDB），配置简单，适合纯Terraform的单一团队场景，依赖关系清晰。
• SSM方案：更灵活，支持跨工具共享，比如运维脚本、其他云服务都能读取这些参数，但需要额外维护SSM资源，还要注意权限配置（确保EKS项目的执行角色有读取SSM参数的权限）。

不管选哪种方案，都能满足你“独立部署控制影响范围”的需求：VPC项目可以单独部署，EKS项目只有在依赖的VPC输出变化时才需要更新，流水线里通过terraform plan或者参数对比就能自动检测变更并触发更新。

备注：内容来源于stack exchange，提问作者motatoes