Terraform-provider-azurerm: Front Door deploy fails with multiple front ends using Front Door certificates

[PaulWilford]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.12.24
provider.azurerm v2.1.0

Affected Resource(s)

• azurerm_frontdoor

Terraform Configuration Files

resource "azurerm_frontdoor" "main" {
  name                                         = var.webapp_url
  location                                     = "global"
  resource_group_name                          = azurerm_resource_group.main.name
  enforce_backend_pools_certificate_name_check = false

  routing_rule {
    name               = "httpToHttpsRedirect"
    accepted_protocols = ["Http"]
    patterns_to_match  = ["/*"]
    frontend_endpoints = ["${var.friendly_name}FrontEnd","${var.friendly_name}SecondaryFrontEnd"]
    redirect_configuration {
      redirect_protocol = "HttpsOnly"
      redirect_type     = "Found"
    }
  }

  routing_rule {
    name = "forwardToWebApp"
    accepted_protocols = ["Https"]
    patterns_to_match  = ["/*"]
    frontend_endpoints = ["${var.friendly_name}FrontEnd"]
    forwarding_configuration {
      backend_pool_name             = var.backend_pool_name
      forwarding_protocol           = "HttpsOnly"
      cache_use_dynamic_compression = "false"
    }
  }

  routing_rule {
    name = "forwardToWebAppSecondary"
    accepted_protocols = ["Https"]
    patterns_to_match  = ["/*"]
    frontend_endpoints = ["${var.friendly_name}SecondaryFrontEnd"]
    forwarding_configuration {
      backend_pool_name             = var.backend_pool_name
      forwarding_protocol           = "HttpsOnly"
      cache_use_dynamic_compression = "false"
    }
  }

  backend_pool_load_balancing {
    name = "${var.friendly_name}LoadBalancer"
  }

  backend_pool_health_probe {
    name = "${var.friendly_name}HealthProbe"
    protocol = "Https"
  }

  backend_pool {
    name = var.backend_pool_name
    backend {
      host_header = "${var.webapp_url}.azurewebsites.net"
      address     = "${var.webapp_url}.azurewebsites.net"
      http_port   = 80
      https_port  = 443
    }

    load_balancing_name = "${var.friendly_name}LoadBalancer"
    health_probe_name   = "${var.friendly_name}HealthProbe"
  }

  frontend_endpoint {
    name                                    = "${var.friendly_name}FrontEnd"
    host_name                               = var.main_url
    custom_https_provisioning_enabled       = true
    web_application_firewall_policy_link_id = var.waf_policy_id
    custom_https_configuration {
      certificate_source = "FrontDoor"
    }
  }

  frontend_endpoint {
    name                                    = "${var.friendly_name}SecondaryFrontEnd"
    host_name                               = var.secondary_url
    custom_https_provisioning_enabled       = true
    web_application_firewall_policy_link_id = var.waf_policy_id
    custom_https_configuration {
      certificate_source = "FrontDoor"
    }
  }
}

Debug Output

Panic Output

Expected Behavior

When creating two frontend endpoints, each with custom DNS and Front Door provided SSL certificate, both should be created.

Actual Behavior

• The deploy fails with the following error:
  'Error: retrieving Front Door Frontend Endpoint "" (Resource Group ""): frontdoor.FrontendEndpointsClient#Get: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded'

• The state is tainted

It is possible to work around this by deploying with only one endpoint, and then adding the second. I think the provider may be trying to create both in parallel but the Front Door is queuing (or ignoring) the second request and the lack of response to the second request causes a timeout internally. The certificate issue taking ~10-15 mins per endpoint is probably also not helping.

Steps to Reproduce

1. Create custom DNS CNAMEs for 2 new endpoints in public DNS
2. Create resource to be built with 2 front end endpoints using the custom DNS defined
3. terraform apply

Important Factoids

References

• #0000

[GregoryFrance]

I have the same issue with provider.azurerm v2.4.0

[VTorstai]

Also when you import the FrontDoor, it will leave the "fronted_endpoits" blank if you have multiple fronted endpoints.

  routing_rule {
        accepted_protocols = [
            "Https",
        ]
        enabled            = true
        frontend_endpoints = [
            "",
        ]
        id                 = "/subscriptions/xx/resourcegroups/ccc/providers/Microsoft.Network/Frontdoors/yyy/RoutingRules/Front-fonts"
        name               = "Front-fonts"
        patterns_to_match  = [
            "/f/*",
        ]

        forwarding_configuration {
            backend_pool_name                     = "Front"
            cache_enabled                         = false
            cache_query_parameter_strip_directive = "StripAll"
            cache_use_dynamic_compression         = false
            forwarding_protocol                   = "HttpsOnly"
        }

Terraform v0.12.24
provider.azurerm v2.4.0

[manojsgh]

Do we have any update on this. I am trying to create five front end points. getting timed-out while applying certificate. Any workaround would be appriciated.

retrieving Front Door Frontend Endpoint "frontendpoint01" (Resource Group "rg-sharedsvc-001"): frontdoor.FrontendEndpointsClient#Get: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

[kingsleyadam]

I was also getting the exact same. The work-around, for now, would be to downgrade the azurerm provider to 2.0. Version 2.0 seems to work for me, thankfully I put my frontdoor infrastructure into it's own repo, but I won't be able to upgrade to any newer version of the azurerm provider until this is fixed.

I have multiple frontend endpoints with custom https configuration and a certificate pulled from Azure KeyVault.

[manojsgh]

@kingsleyadam thanks after degrading the version it worked. Thanks for the work around.

[vpetersen]

I have the same issue with 2.8.0

[johnnyhuy]

The way we've mitigated this is to deploy each frontend endpoint at a time via commenting them out one at a time. This also didn't taint Front Door resource so that we can continue to add more endpoints.

[johnnyhuy]

Also found out that we can terraform untaint azurerm_frontdoor.{name} Front Door on the first go. Then after subsequent runs you'll result in multiple endpoints.

Though this obviously doesn't solve the upstream problem.

[vpetersen]

This is still an issue with the lastest release.

[harsh-vm]

We are hitting the same issue. Any updates on this please?

[smishr04]

Facing same issue , FrontDoor provisioning fails when creating multiple front-ends with custom https configuration ... Any info on when we will have the fix please?

[smishr04]

We followed this https://www.terraform.io/docs/providers/azurerm/r/frontdoor_custom_https_configuration.html and wrote a new module for just certificate binding and it resolved our issue....

[Cedric-Bravo]

We have the same issue since we upgrade to Terraform v0.12.21+ provider.azurerm v2.8.0
Using a separate resource referring to endpoint index is not acceptable for us. Code is hardest to maintain and to automate (we use bootstrap program to automate TF code creation).
Since it worked before, it's a major functional regression with a high impact on our deployment velocity.
Because of the high delay needed to deploy endpoint we have to reconsider the use of Front Door Managed Certificate (one of the best feature of the product) to use our own certificate.