Terraform跨文件夹调用模块输出值的实现方法咨询

Absolutely! Terraform is built to handle exactly this kind of cross-directory resource dependency, so you can absolutely reference outputs from your VPC setup in the networking folder to deploy EC2 instances into the right subnets. Let’s break down the two main approaches depending on how you manage your infrastructure:

1. Recommended: Reference Networking as a Local Module (Co-Managed Infrastructure) #

If you plan to manage both your networking layer and EC2 instances together (or at least want their Terraform configurations linked), this is the cleanest approach:

Step 1: Define Outputs in the Networking Directory #

First, you need to expose the subnet IDs (and any other VPC-related values you need) as outputs in the networking folder. Create an outputs.tf file there (or add to your existing config) to export the values:

# networking/outputs.tf
output "public_subnet_ids" {
  description = "List of IDs for public subnets in the VPC"
  value       = module.vpc.public_subnet_ids # Replace with your actual VPC module's output name
}

output "private_subnet_ids" {
  description = "List of IDs for private subnets in the VPC"
  value       = module.vpc.private_subnet_ids
}

Note: If your vpc-tst.tf directly defines resources instead of using a module, replace module.vpc.* with the actual resource attributes (e.g., aws_subnet.private.*.id).

Step 2: Import the Networking Module in prd/instances.tf #

In your prd/instances.tf, add a module block pointing to the networking directory, then use its outputs when defining your EC2 instance:

# prd/instances.tf
# Import the networking module to access its outputs
module "networking" {
  source = "../networking" # Relative path from prd/ to networking/

  # If your networking module requires variables, pass them here (match what's in networking/variables.tf)
  # Example:
  # vpc_cidr_block = "10.0.0.0/16"
}

resource "aws_instance" "application_server" {
  ami           = "ami-0c55b159cbfafe1f0" # Update to your region's preferred AMI
  instance_type = "t2.micro"

  # Use the first private subnet from the networking module's outputs
  subnet_id = module.networking.private_subnet_ids[0]

  # Add other required config (security groups, tags, etc.)
  tags = {
    Name = "Prd-Application-Server"
  }
}

Quick Checks for This Approach #

• Run terraform init in the prd directory after adding the module to initialize the dependency
• Ensure the relative source path is correct (since prd and networking are siblings under tm-project/, ../networking works)
• If you use Terraform workspaces, make sure both directories are using the same workspace to avoid state mismatches

2. Alternative: Use Remote State (Independent Networking Deployment) #

If you deploy your networking layer separately (e.g., it’s managed by a different team or applied independently), you can pull outputs from its remote state file using the terraform_remote_state data source:

# prd/instances.tf
data "terraform_remote_state" "networking" {
  backend = "s3" # Match your backend type (s3, azurerm, gcs, etc.)

  config = {
    bucket = "your-terraform-state-bucket"
    key    = "networking/terraform.tfstate" # Path to the networking state file in your bucket
    region = "us-east-1" # Your bucket's region
  }
}

resource "aws_instance" "application_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  # Pull subnet ID from the remote networking state
  subnet_id = data.terraform_remote_state.networking.outputs.private_subnet_ids[0]
}

Just make sure the remote state is accessible to the prd Terraform configuration (correct permissions, backend config matches).

Either way, you’ll be able to deploy your EC2 instances directly into the subnets defined in your networking folder—this is exactly how Terraform’s modular design is intended to work!

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