This is a working template for deploying Azure Front Door together with Rules Engine rules.
Basically, there's currently an unavoidable circular dependency:
- Routing Rules are part of the Front Door
- Rules Engines are sub resources (which require the FrontDoor to exist before you can deploy them)
- For Rules Engines to work, the Routing Rules have to reference them ...
Obviously you can't reference the Rules Engine configuration on initial deploy, because it doesn't exist yet.
My work-around is to have a first-time-only clean deployment that creates the FrontDoor, and from then on to always create the RoutingRules before configuring the FrontDoor (which may then contain RoutingRules which reference the RulesEngine(s).
New-AzResourceGroupDeployment -ResourceGroupName YourRG -TemplateFile FrontDoor.bicep -FrontDoorName YourUniqueName -FirstTimeCleanDeployment:$true
If you deploy it the first time without setting FirstTimeCleanDeployment
true, it will fail, so you can't forget to pass it the first time. Unfortunately, I have not yet found a way to prevent redeploying with FirstTimeCleanDeployment
true -- which would wipe the configuration before recreating it.
Note: In my example FrontDoorActual.bicep
file there's only a single backend and frontend and the only rule engine is just there to allow Cross-Origin requests, but it's just an example and I didn't want to make it too complicated. The idea is that you could take the FrontDoorClean.bicep
template and use it the way I am here, but write your own FrontDoorActual.bicep
to actually configure your front door.
Of course, we really just need Microsoft to fix this. Perhaps by making the RulesEngine independent of the FrontDoor.