Search code examples
azureazure-front-door

Azure Front Door Configuration Changes

I have a multi-tier application that is deployed using Azure Devops. It uses the "blue green" deployment methodology. (I.e. 2 identical stacks side by side.) This works fine. The while lot is fronted by Azure Front Door such that one URL (call it "Prod") points to one application stack and another URL (call it "ProdNew") points to the other application stack.

appProd.contoso.com --> Back End Prod

appProdNew.contoso.com --> Back End ProdNew

The testers test appProdNew.contoso.com and when it all works, there is a cutover pipeline that changes the Front Door rule to do this:

appProd.contoso.com --> Back End ProdNew

(Don't worry about inflight transactions, they're all handled by some database cleverness.)

The problem is that Front Door continues to point to Back End Prod even after the config is saved. If left for a few hours (I don't know how many, but it means overnight), eventually, it does use the new Back End.

  1. Caching and Session Affinity are disabled but the problem persists.
  2. Stopping Back End Prod just results in Front Door saying the back end is down. In other words it does not even try to use the new back end.
  3. I read here https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq that "Since Front Door doesn't work at a VM/container level, so it cannot do Connection Draining". OK, I get that but connections have to time out eventually, don't they?
  4. The same site also says "Most new Front Door creates and updates take about 3 to 20 minutes to deploy across all our edge location globally. Any updates to routes or backend pools etc. are seamless and will cause zero downtime (if the new configuration is correct)." Yet, after even an hour, it still tries to use the same old back end.
  5. We have tried disabling and re-enabling the rules. But when re-enabled it still tries to use the old back end even though the rule clearly points to the new back end.

Prior to Front Door, we used DNS CNAMES and flipped those. The problem with that approach is that during the flip over, some would be using the old and some the new which presented a problem for a blue/green deployment. One of the ideas of using Front Door was to gain more control over the cutover process.

Question: are we approaching the problem in the wrong way, or is there a command we can throw at Front Door to force it to use the new back end?

Solution

  • The behaviour described in the question does not seem to be expected behaviour. Based on additional testing the following day, the moment Front Door was updated with the new backend, it started using it - even without a Cache Purge. Therefore, the problem would appear to be a "glitch" in Front Door, possibly just a delay in it applying the new configuration.