1

Facing an issue related to deployment of Azure App Service resources. We have an already existing app service in subscription A with a custom domain XYZ. Now we are trying to create a new app service in subscription B with the same domain name XYZ. We have added the appropriate asuid TXT records in the DNS Zone for the mapping of the domain to the new app service. By that I mean there is a asuid.XYZ TXT record with the verification ids of both the app services. This is required to bind multiple apps to the same domain as per docs.

Now in our ARM releases we are facing the following failure : Hostname 'XYZ' conflicts with an already existing hostname.

As per the app service documentation, it should be possible to assign multiple apps the same custom domain so that we can migrate without downtime. I did find some links stating that if the deployment units for the apps are same, this custom domain assignment will give a conflict as above. Eg. Migrate an active DNS name - Azure App Service | Microsoft Learn

But this seems totally out of our ability to control via deployments?? Is there something we are missing or someone has any more idea about how to resolve this ?

Pragun
  • 122
  • 2
  • 7
  • I have a feeling that Azure has changed something recently - we used to do this frequently, and are running into this issue today. I will check with support. – ScottE Mar 02 '23 at 23:13
  • @ScottE Were you able to get some resolution on your end ? – Pragun Mar 06 '23 at 15:32
  • sorry, I didn't have any luck. I did confirm that Alex AIT is correct in that there must be a conflict with the deployment units. I create a new app service in a different resource group, and did not have this issue. I do think something changed in Azure, however. – ScottE Mar 07 '23 at 16:03
  • We are running into this problem now when deploying a second copy of the app service to a completely different region... so it definitely it in a different deployment unit, and still getting this problem. Has anyone gotten around this? It seems like something has changed because we used to be able to do this. – Amanda Kitson Jun 06 '23 at 21:21
  • @AmandaKitson We weren't able to get some resolution even after talking to azure support. In the end we took the approach of disabling the existing service and then deploying the new ones :( In your case though since the regions are different this should not be happening from what I understand, so you might want to reach out to support to see if they can investigate this. – Pragun Jun 11 '23 at 11:12

1 Answers1

0

From the documentation you mentioned:

When you create two apps in the same resource group and the same region, Azure puts them in the same deployment unit. However, there's no way to make sure that the opposite is true. In other words, the only way to create a plan in a different deployment unit is to keep creating a plan in a new resource group or region until you get a different deployment unit.

If you create a new AppService Plan in a different resource group, you will have a very high chance of getting a different deployment unit.

It might not be guaranteed. But I did a quick check and across 56 AppService Plans in different resource groups I did not get a single overlapping deployment unit.

What you can also do is create the AppService Plan in a new resource group until you get the desired new deployment unit, and then move the AppService Plan into your desired resource group. It will stay in the same deployment unit.

Alex AIT
  • 17,361
  • 3
  • 36
  • 73
  • We actually tried this. Since the subscriptions are different the resource groups of these app services are also different. Still we deleted and redeployed the new one but we are still getting the same issue. It feels un-intuitive to just keep retrying and hope it gets resolved, that's why posted this question wondering if there is a concrete workaround for this. – Pragun Feb 22 '23 at 10:49
  • @Pragun Did you check if they have the same internal values for the web space? – Alex AIT Feb 22 '23 at 11:07
  • Yes it appears the deployment units are same for both. This might be the reason for the conflict, but how to mitigate this so that the new app has a different unit ? – Pragun Feb 22 '23 at 11:48
  • @Pragun I would suggest to create the new Appservice plan in a resource group that has a different name. Maybe there is some hashing that determines the scale unit, I don't know. If everything else fails you can always temporarily switch your domain to a different region and then back again, though that is obviously not ideal. – Alex AIT Feb 22 '23 at 12:43