You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Terraform中如何将vmc_sddc资源的动态生成属性作为nsxt Provider的输入参数?

How to Use Dynamically Generated Resource Values as Terraform Provider Inputs

Great question—this is a super common gotcha with Terraform's execution order! The core issue here is that Terraform initializes all providers before it creates any resources. When you try to pass vmc_sddc.harpoon_sddc.nsxt_reverse_proxy_url directly to the nsxt provider, that value doesn't exist yet at provider initialization time, hence the "host must be provided" error.

Luckily, there are reliable workarounds by splitting your configuration into separate execution stages. Here's the most straightforward approach:

Solution: Split Configuration into Two Stages with Remote State

Stage 1: Create the SDDC and Export the Required URL

First, build a dedicated Terraform configuration to provision your VMC SDDC and output the nsxt_reverse_proxy_url value. Store this state in a remote backend (like AWS S3, Azure Blob Storage, or Terraform Cloud) so the second stage can access it.

# stage1-sddc/main.tf
resource "vmc_sddc" "harpoon_sddc" {
  sddc_name           = var.sddc_name
  vpc_cidr            = var.vpc_cidr
  num_host            = 1
  provider_type       = "AWS"
  region              = data.vmc_customer_subnets.my_subnets.region
  vxlan_subnet        = var.vxlan_subnet
  delay_account_link  = false
  skip_creating_vxlan = false
  sso_domain          = "vmc.local"
  deployment_type     = "SingleAZ"
  sddc_type           = "1NODE"
}

# Output the NSXT proxy URL for the next stage
output "nsxt_reverse_proxy_url" {
  value     = vmc_sddc.harpoon_sddc.nsxt_reverse_proxy_url
  sensitive = true # Optional: hides the value in CLI output for security
}

Run these commands to apply this stage:

cd stage1-sddc
terraform init
terraform apply

Stage 2: Configure the NSXT Provider Using Remote State

Create a second Terraform configuration that fetches the output from Stage 1 using the terraform_remote_state data source, then uses that value to configure the nsxt provider.

# stage2-nsxt/main.tf
# Fetch the state from Stage 1
data "terraform_remote_state" "sddc" {
  backend = "s3" # Match the backend you used in Stage 1
  config = {
    bucket = "your-terraform-state-bucket"
    key    = "stage1-sddc/terraform.tfstate"
    region = "us-west-2" # Match your Stage 1 region
  }
}

# Configure the NSXT provider with the dynamically generated URL
provider "nsxt" {
  host                   = data.terraform_remote_state.sddc.outputs.nsxt_reverse_proxy_url
  vmc_token              = var.api_token
  allow_unverified_ssl   = true
  enforcement_point      = "vmc-enforcementpoint"
}

# Now you can define your NSXT resources here, e.g.:
# resource "nsxt_firewall_rule" "example" {
#   name        = "allow-ssh"
#   action      = "ALLOW"
#   ...
# }

Run these commands to apply the second stage:

cd stage2-nsxt
terraform init
terraform apply

Why This Works

By splitting the workflow into two stages, we ensure the SDDC is fully provisioned and its state is stored before we attempt to configure the NSXT provider. The terraform_remote_state data source lets us safely retrieve the dynamic value from the first stage's state, which now exists when the NSXT provider initializes.

Bonus: Automate with Terraform Cloud (Optional)

If you use Terraform Cloud, you can set up run triggers to automatically run the Stage 2 workspace whenever Stage 1 completes successfully. This removes the need to manually run each stage.

内容的提问来源于stack exchange,提问作者Tennis Smith

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.04.29 00:58:09