Terraform depends_on with modules

Question

I'm new at terraform and I created a custom azure policies on module structure. each policy represents a custom module. One of the modules that I have created is enabling diagnostics logs for any new azure resource created. but, I need a storage account for that. (before enabling the diagnostics settings how can I implement "depends_on"? or any other methods? I want to create first the storage account and then the module of diagnostics settings. on the main.tf (where calling all the other modules) or inside the resource (module)?

Thanks for the help!! :)

this below code represents the main.tf file:

//calling the create storage account name

module "createstorageaccount" {

source = "./modules/module_create_storage_account"
    depends_on = [
    "module_enable_diagnostics_logs"
  ]

}

this one represents the create storage account module

resource "azurerm_resource_group" "management" {


  name     = "management-rg"
  location = "West Europe"
}

resource "azurerm_storage_account" "test" {
  name                     = "diagnostics${azurerm_resource_group.management.name}"
  resource_group_name      = "${azurerm_resource_group.management.name}"
  location                 = "${azurerm_resource_group.management.location}"
  account_tier             = "Standard"
  account_replication_type = "LRS"

  tags = {
    environment = "diagnostics"
  }
}

    depends_on = [
    "module_enable_diagnostics_logs"
  ]

Answer 1

In most cases, the necessary dependencies just occur automatically as a result of your references. If the configuration for one resource refers directly or indirectly to another, Terraform automatically infers the dependency between them without the need for explicit depends_on.

This works because module variables and outputs are also nodes in the dependency graph: if a child module resource refers to var.foo then it indirectly depends on anything that the value of that variable depends on.

For the rare situation where automatic dependency detection is insufficient, you can still exploit the fact that module variables and outputs are nodes in the dependency graph to create indirect explicit dependencies, like this:

variable "storage_account_depends_on" {
  # the value doesn't matter; we're just using this variable
  # to propagate dependencies.
  type    = any
  default = []
}

resource "azurerm_storage_account" "test" {
  name                     = "diagnostics${azurerm_resource_group.management.name}"
  resource_group_name      = "${azurerm_resource_group.management.name}"
  location                 = "${azurerm_resource_group.management.location}"
  account_tier             = "Standard"
  account_replication_type = "LRS"

  tags = {
    environment = "diagnostics"
  }

  # This resource depends on whatever the variable
  # depends on, indirectly. This is the same
  # as using var.storage_account_depends_on in
  # an expression above, but for situations where
  # we don't actually need the value.
  depends_on = [var.storage_account_depends_on]
}

When you call this module, you can set storage_account_depends_on to any expression that includes the objects you want to ensure are created before the storage account:

module "diagnostic_logs" {
  source = "./modules/diagnostic_logs"
}

module "storage_account" {
  source = "./modules/storage_account"

  storage_account_depends_on = [module.diagnostic_logs.logging]
}

Then in your diagnostic_logs module you can configure indirect dependencies for the logging output to complete the dependency links between the modules:

output "logging" {
  # Again, the value is not important because we're just
  # using this for its dependencies.
  value = {}

  # Anything that refers to this output must wait until
  # the actions for azurerm_monitor_diagnostic_setting.example
  # to have completed first.
  depends_on = [azurerm_monitor_diagnostic_setting.example]
}

If your relationships can be expressed by passing actual values around, such as by having an output that includes the id, I'd recommend preferring that approach because it leads to a configuration that is easier to follow. But in rare situations where there are relationships between resources that cannot be modeled as data flow, you can use outputs and variables to propagate explicit dependencies between modules too.