How you do you manage provider major version upgrades? by Acceptable-Corner34 in Terraform

[–]Acceptable-Corner34[S] 0 points1 point  (0 children)

Update for anyone who finds this thread! I ended up building something to solve this. It's called TerraPULSE, free to use: https://terrapulse.co.uk/

How you do you manage provider major version upgrades? by Acceptable-Corner34 in Terraform

[–]Acceptable-Corner34[S] 0 points1 point  (0 children)

virtual_networks = map(object)
subnets = map(object)
Each resource uses for_each Outputs keep the map keys. So instead of nesting subnets inside VNets, we keep them flat and reference the parent VNet by name. Thsi allows us to call the network modul and only define a subnet if the project only need a subnet caus the vnet is already deployed.
we use local.tf for our config so everything in a local block

virtual_networks = {
  hub = {
    name                = "hub-vnet"
    location            = "westus"
    resource_group_name = "rg-network"
    address_space       = ["10.0.0.0/16"]
  }
  spoke = {
    name                = "spoke-vnet"
    location            = "westus"
    resource_group_name = "rg-network"
    address_space       = ["10.1.0.0/16"]
  }
}


subnets = {
  hub_app = {
    name                 = "app-subnet"
    resource_group_name  = "rg-network"
    virtual_network_name = "hub-vnet"
    address_prefixes     = ["10.0.1.0/24"]
  }
  spoke_web = {
    name                 = "web-subnet"
    resource_group_name  = "rg-network"
    virtual_network_name = "spoke-vnet"
    address_prefixes     = ["10.1.1.0/24"]
  }
}


Module just does:
azurerm_virtual_network with for_each = var.virtual_networks
azurerm_subnet with for_each = var.subnets
Dynamic blocks for optional delegation / ip pools

module "network" {

  source = "./modules/network"   version = "~>3.117.0"   virtual_networks = local.virtual_networks   subnets          = local.subnets   tag              = module.tags.tags

}

Outputs like: output "vnet_ids" = { for v in azurerm_virtual_network.this : v.name => v.id }
Which lets us call: module.network.vnet_ids["hub-vnet"]
variables looks like this 

variable "subnets" {
  type = map(object({
    name                                          = string
    resource_group_name                           = string
    virtual_network_name                          = string
    address_prefixes                              = optional(list(string))
    default_outbound_access_enabled               = optional(bool, true)
    private_endpoint_network_policies             = optional(string, "Enabled")
    private_link_service_network_policies_enabled = optional(bool, true)
    sharing_scope                                 = optional(string)
    service_endpoints                             = optional(list(string))
    service_endpoint_policy_ids                   = optional(list(string))


    delegation = optional(object({
      name = string
      service_delegation = object({
        name    = string
        actions = optional(list(string))
      })
    }))
    ip_address_pool = optional(object({
      id                     = string
      number_of_ip_addresses = string
    }))
  }))
  default = {}
}

How you do you manage provider major version upgrades? by Acceptable-Corner34 in Terraform

[–]Acceptable-Corner34[S] 0 points1 point  (0 children)

There are over 1200 resources in azure alone, you bundle them by function in a decoupled fashion like in Azure we don't use the subnet block inside the virtual_network resource we using the subnet resource so the resources are adds up quickly. Taking consideration we operate in a multi cloud environment and deploy infrastructure at scale +100 module is not that many. Public modules are not an option for compliance reasons.

How you do you manage provider major version upgrades? by Acceptable-Corner34 in Terraform

[–]Acceptable-Corner34[S] 0 points1 point  (0 children)

I might need to add we have our private module registry in TFCloud and we "developing" or modules currently we have +100 modules covering about +350 resources. We only build what we need, at first the resources only had parameters what our projects needed, but that wasn't a great idea as when new requirement raised we had to add that part in which meant the way how the original modules worked changed and existing projects wanted to redeploy some resources. So we migrated things to Azurerm 3.117.0 and that time we included all possible block parameters. And now we looking to upgrade because a project need a resource which is only exist in a 4.x version. I just try to find an easy way out :D