Avoid cyclic when referencing an output of a resource within the same resource

Terraform
1

Hey,

I have a resource that creates a container apps on Azure such:

resource “azurerm_container_app” “api” {
name = “my-app”
…
env [{name: “vertification_code”, value: ref-to-custom_domain_verification_id}]
}

with an output such:

output “custom_domain_verification_id” {
value = azurerm_container_app.api.custom_domain_verification_id
}

This causes cyclic, I understand that there’s a need to wait for the resource to be created first, what’s the best practice to handle such a case?

Best,
Asaf

2

Hi @asaf,

What I understand from this is that when creating your azurerm_container_app you want to populate a value in an env block in that resource with the value of the custom_domain_verification_id which itself is an attribute that is exported by the azurerm_container_app (And not known until apply time)

Unfortunately you are not going to be able to achieve this, with this approach. You can’t populate the resource with something that is unknown until the resource is deployed (Hence the cyclic dependency).

The ausid / customDomainVerificationId is the same for app app services on the same subscription but is not available until you have deployed at least one app service (microsoft.web/sites) related resource ( webapp: Way to get ‘Custom Domain Verification ID’ for web app · Issue #14142 · Azure/azure-cli · GitHub) and is not easily obtainable without running script/query outside of Terraform.

If you really need the asuid to be populated into the environment block in the resource that generated the ausid then the following approach may work in your module (I have done similar in the past with success for other app services resources)

  1. Create azurerm_container_app resource using AzureRM provider as you indicate, but without the env block.

  2. Ensure the azurerm_container_app resource has a lifecycle Meta-Argument ignore changes argument for the env block.

  3. Create an azapi_update_resource using the azapi provider which updates the azurerm_container_app resource with just the env block which can now contain values referenced from your azurerm_container_app resource. This referencing should ensure there is an implicit dependency between the resources (otherwise you would need an explicit dependency)

#2 is required to prevent subsequent runs detecting the change made by #3 to the resource created in #1.

Note that now you are constrained to managing that env block for that resource using the azapi_update_resource instead of doing it ‘inline’ within the azurerm_container_app

HTH

Happy Terraforming

4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.