Support for Rules Engine in azurerm_frontdoor

[satonaoki]

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

Description

Rules Engine for Azure Front Door is now GA.

Could you add support for Rules Engine in azurerm_frontdoor?

• Rules Engine for Azure Front Door and Azure CDN is now generally available
• What is Rules Engine for Azure Front Door?

New or Affected Resource(s)

• azurerm_frontdoor

Potential Terraform Configuration

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

References

[dossy]

8208

[tckb]

no updates on this yet? -- this seems to be a bit basic necessity for using frontdoor.

[WodansSon]

@satonaoki Thank you for opening this issue and I am sorry for the delay. I am currently working on implementing this as a separate resource to work in conjunction with the existing Front Door resource in Terraform. There has been a lot of churn in various aspects of Azure as of late which I am currently working through, but I should have this resource complete in the next few weeks or so, pending no further issue pop up which may cause this to be pushed out a bit.

[wes-novack]

Hello @WodansSon ! Thank you for working to implement this in the Terraform provider. Any update as to when this might become available? My current project needs a Front Door Rules Engine defined in Terraform.

[dhananjaya94]

@WodansSon , delighted to have the new provider, our current project also needs a front door rules engine defined in terraform.

[dhananjaya94]

@tombuildsstuff any ETA on providing the new resource ?

[dhananjaya94]

Azure Front Door + Rules engine leads to cyclic dependancy when implemented with ARM also. Seems this to be a limitation with Azure APIs. https://stackoverflow.com/questions/63707676/how-to-deploy-front-door-with-rules-engine-within-single-arm-template

[akshaychopra5207]

Any ETA for Rule engine?

[akshaychopra5207]

Azure Front Door + Rules engine leads to cyclic dependancy when implemented with ARM also. Seems this to be a limitation with Azure APIs. https://stackoverflow.com/questions/63707676/how-to-deploy-front-door-with-rules-engine-within-single-arm-template

Did arm template deployment worked with nested template for rule engine as per your answer in the mentioned link?

[akshaychopra5207]

Guys we have created production azure frontdoor with Terraform but due to no rule engine support we cant create routing rule with rule engine defined and terraform overrides the created routing rule from portal which can cause downtime. How to have proper deployment of frontdoor without any downtime with rule engine defined?

[dhananjaya94]

Any ETA for Rule engine?

No ETA was provided on this from Microsoft saying that it's required to make API changes from their end.

[dhananjaya94]

Azure Front Door + Rules engine leads to cyclic dependancy when implemented with ARM also. Seems this to be a limitation with Azure APIs. https://stackoverflow.com/questions/63707676/how-to-deploy-front-door-with-rules-engine-within-single-arm-template

Did arm template deployment worked with nested template for rule engine as per your answer in the mentioned link?

No, Had to do a hack with the Azure CLI

[Cedric-Bravo]

Any update for Rule engine support for Front Door ? Rule engine can be used to significantly reduce the number of routing rules needed and Routing rule are very expensive (around 9$/month). In complex site configuration, using rule engine can save a lot.

[timja]

@WodansSon do you have any update? Thanks :)

[krohm]

@WodansSon , @olohmann , this is a crucial enhancment we are waiting for. Is there any ETA you can give us?

[tombuildsstuff]

👋

As per the community note above, I've marked some of the "me too" / "when will this become available" comments as off-topic - whilst I appreciate this is a high demand feature, we ask that you add a 👍 to this issue if you're looking for support for this. Whilst the "me too" (or "when will this be fixed" / "any update") comments are well intentioned (and we want to get to this as soon as possible) - this ends up causing more notifications which take time away from PR's.

I'll ask @WodansSon to post an update when he gets time, but for the moment as far as I'm aware the status is unchanged from in this comment - it's currently blocked based on other priorities, plus the circular reference issue mentioned above which needs to be resolved during implementation.

Thanks!

[ttlnd]

You could split the feature in 2.

1. Just make sure it works to add a REC for routing rules - (IMPORTANT)
2. Full support for REC

Right now terraform removes REC from routing rules without letting you know

[Carlos-724]

The question from now is how much "👍" do we need ;D Can't wait to use this feature.

[aeirola]

Wondering if the new Azure Front Door Standard/Premium (https://docs.microsoft.com/en-us/azure/frontdoor/standard-premium/) has something to do with the current front door not receiving important feature support like the rules engine.

I don't think any deprecation has been announced for the current front door, but hard to imagine that azure would want to provide two front doors in the long term.

[saoullabit]

Please ... me too this is a killing feature !

[admsteck]

FWIW, we worked around this by adding a "null_resource" that has a "local-exec" provisioner to run a powershell script that sets up the rules engine and ties it to the front door. The provisioner has to be on a separate null resource because any updates to the front door will remove the link to the rules engine and the provisioner will only run on resource creation. We set the triggers on the null resource to ensure it runs every time.

[joaomoreno]

Thanks for the hints @admsteck. For others who are stuck here, this is a snippet of how to preserve the rules engine if the Front Door gets updated:

resource "null_resource" "fd_routing_engine" {
  provisioner "local-exec" {
    command = "az config set extension.use_dynamic_install=yes_without_prompt && az network front-door routing-rule update --front-door-name NAME --resource-group RESOURCE_GROUP --name ROUTING_NAME --rules-engine ENGINE_NAME"
  }
}

[ericjohnson2]

Update: this functions to keep terraform in sync with Front Door, but there will be a gap in time where the rule is not in place due to terraform updating Front Door and the local-exec re-adding the rule. If your service relies on a rule to complete requests - tread carefully.

expanding on the above example, I have added a trigger and depends_on to ensure correct order of execution along with multiple routes needing a rules_engine. This is necessary for something like a CORS rules with multi-origin scenario and caching or if you have lots of routes. This could probably be looped as well.

resource "null_resource" "fd_routing_route1" {
  triggers = {
    always_run = timestamp()
  }
  provisioner "local-exec" {
    command = "az network front-door routing-rule update --front-door-name NAME --resource-group RESOURCE_GROUP --name ROUTING_NAME --rules-engine ENGINE_NAME"
  }
  # forces execution to go after front door
  depends_on = [
    azurerm_frontdoor.example_frontdoor
  ]
}

resource "null_resource" "fd_routing_route2" {
  triggers = {
    always_run = timestamp()
  }
  provisioner "local-exec" {
    command =  "az network front-door routing-rule update --front-door-name NAME --resource-group RESOURCE_GROUP --name ROUTING_NAME --rules-engine ENGINE_NAME"
  }
  # forces execution to go after front door and prevents conflicting commands
  depends_on = [
    azurerm_frontdoor.example_frontdoor,
    null_resource.fd_routing_route1
  ]
}

[heoelri]

@satonaoki Thank you for opening this issue and I am sorry for the delay. I am currently working on implementing this as a separate resource to work in conjunction with the existing Front Door resource in Terraform. There has been a lot of churn in various aspects of Azure as of late which I am currently working through, but I should have this resource complete in the next few weeks or so, pending no further issue pop up which may cause this to be pushed out a bit.

@WodansSon is this something you're still working on? I'm not sure if anything has changed on the ARM API side and if it's nowadays possible to do the assignments via API/sdk, but even if not, I definitely see some value in at least having the option to define the rules engine rules via TF and, worst case, use the workaround described above to do the assignments.

I gave it a shot here: https://github.com/heoelri/terraform-provider-azurerm/tree/feature/frontdoor-rulesengine and have implemented ~50% of the needed functionality.

Let me now if you think it makes sense or not.

[ericjohnson2]

is this closed by https://github.com/hashicorp/terraform-provider-azurerm/pull/13249?

[aidapsibr]

@ericjohnson2 The following is still TODO from #13249

• Figure out if the association can be done via ARM
• Adding support for routeConfigurationOverride
• Adding support for MatchProcessingBehavior

[aidapsibr]

I also want to not that rules match_condition negate_condition is true by default which is very unexpected.

rule {
  name = "HstsHeader"
  match_condition {
    variable = "RequestScheme"
    operator = "Equal"
    value = ["HTTPS"]
  }

Unintuitively this results in a Not Equal rule.

[ericjohnson2]

I also noticed there is a blank docs space for selector?

https://github.com/hashicorp/terraform-provider-azurerm/pull/13249/files#diff-686c982dc5a6e9decbcb220f834a45c6bf38cf681e81466282055cd8babf2a3dR121

edit: negate_condition also defaults to true (as stated above) which could be specified in the docs as well edit2: is a PR just to fix docs okay? I have no problem opening one to clarify a bit

[joaomoreno]

Update: this functions to keep terraform in sync with Front Door, but there will be a gap in time where the rule is not in place due to terraform updating Front Door and the local-exec re-adding the rule. If your service relies on a rule to complete requests - tread carefully.

I've submitted a PR to fix this issue and avoid the local-exec workaround altogether, appreciate any thumbs up: https://github.com/hashicorp/terraform-provider-azurerm/pull/13911

[kethahel99]

What about overriding routing information in the rules engine based on request header values?

[kethahel99]

Is here any update on this? overriding routing information as an action.

Currently only requestheader and responseheader actions are supported in the provider

[JamesDLD]

1. Just asked a review to a ready PR (I mean that tests are ok) in order to create "routeConfigurationOverride": https://github.com/hashicorp/terraform-provider-azurerm/pull/15104
2. Did open in parallel a new PR (not ready yet) that aims to identity changes done outside Terraform : https://github.com/hashicorp/terraform-provider-azurerm/pull/16537

[bubbletroubles]

Since the PR was not approved, I've got a workaround for this.

Deploy the FrontDoor using the AzureRM provider. Configure the rules engine using the azapi provider - sample block below

resource "azapi_resource" "test" {
  type = "Microsoft.Network/frontDoors/rulesEngines@2020-05-01"
  parent_id = azurerm_frontdoor.example.id
  name = "myengine"
  body = jsonencode({
    "properties" = {
      "rules" = [
        {
          "name"     = "test",
          "priority" = 0,
          "action" = {
            "routeConfigurationOverride" = {
              "redirectType"      = "Found",
              "redirectProtocol"  = "HttpsOnly",
              "customHost"        = "customhost.org",
              "customPath"        = "",
              "customFragment"    = null,
              "customQueryString" = null,
              "@odata.type"       = "#Microsoft.Azure.FrontDoor.Models.FrontdoorRedirectConfiguration"
            },
            "requestHeaderActions"  = [],
            "responseHeaderActions" = []
          },
          "matchConditions"         = [],
          "matchProcessingBehavior" = "Continue"
        }
      ]
    }
  })
}

[kethahel99]

Thanks @bubbletroubles , I'll try this out

[WodansSon]

The legacy Frontdoor resources have been retired and are no longer being developed.

[simongh]

so tough luck, front door will never work with Terraform? Does that mean we can expect non-legacy resources anytime soon?

To be fair, Microsoft don't seem that interested in supporting Front door either. Their documentation doesn't match the api, or is incorrect & obtuse.

---edit => I've just found the new resources under cdn. I didn't think to look there.

[michaelamattes]

I've you are interrested we've tried to solve the actuall missing support for mapping RulesEngine to Routing Rule and the Override Option in our FrontDoor Module https://registry.terraform.io/modules/T-Systems-MMS/frontdoor. We've solved this with template deployments and null resources with specific triggers.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.