Intro
Sitecore is an experience platform that supports multisite. That means, one Azure App Service with Sitecore instance can host several websites. For example, Sitecore Experience Accelerator (SXA) module can be used in order to create and manage multiple websites quickly and easily.
Those websites can have different hostnames/domains.
In this article, I will describe the challenges that I faced during implementation and the way I found to configure Azure Front Door (AFD) to route traffic so that Sitecore will be able to resolve websites correctly.
You are welcome to post your opinion, describe your experience and let me know in case you think there is something that should be done differently.
Legend
Let's consider the following use case:
- We have one CD Web App that hosts 2 web sites with hostnames: "www-prod.sc.sitcre.de" and "www-prod.sc.cospespe.de"
- Within Sitecore CD configuration, we have <site> record for each website with appropriate hostName parameter.
- Default SSL certificate for AFD frontend HTTPS connection is used (AFD Managed Certificate)
- In the domain registry, we pointed both DNS names (mentioned in the #1) by CNAME record to Azure Front Door host. It looks for example like on the image below.
Problem #1. Frontend -> App Service routing
One of the biggest issues I faced was the fact that I was not able to assign custom domains to my Web Apps due to the fact that I needed to use at least 2 separate Content Delivery (CD) app services.
It is not possible to assign a custom domain to a web app in Azure in case it is already assigned to another one.
Without a custom domain assigned, there are issues routing request sent to a custom AFD Frontend/domain to App Service backend without an appropriate custom domain assigned (the App Service can be only available through vanilla hostname appservicename.azurewebsites.net)
Note: if you have only one website hosted on a CD web app, you can easily assign a custom domain to that app service and keep things simple.I definitely tried to use the standard approach and add a backend to backend pool with already tweaked host header:
Unfortunately, I failed to reach my website with that configuration. As I mentioned above, I have not assigned a custom domain to that CD web app and that was an issue.
So I got this response:
In order to fix it, I need to make sure AFD reaching ma CD web app using the right domain (which in my case is only mywebsite.azurewebsites.net).
In order to achieve this, a backend in the backend pool should be equal to the default web app hostname (mywebsites.azurewebsites.net):
Problem #2. Sitecore website resolving
After fixing the problem #1 CD starts responding, however requesting both websites provides the same response page. This time the problem is in website resolving. Sitecore is resolving website e.g. using Host header.
AFD routing the request to the vanilla host name (mywebsite.azurewebsites.net), so the Host header equals to that one.
The resolution for this problem is to rewrite Host header on CD web app.
AFD by default sends original host header (the one that was originally requested by the visitor in browser line) in X-Forwarded-Host header. That means we just need to update Host header with the value from X-Forwarded-Host.
This can be done in Azure App Service by using transformation in applicationHost.
There is even an extension that can be installed in Kudu of CD web app:
Problem #3. Getting a valid certificate for AFD custom domain
There are 2 options to get SSL certificate:
1. generate AFD managed certificate
2. upload your own certificate
Because of the fact that a custom domain is not assigned to the backend web app, certificate subject name validation should be turned off to avoid warning in browser.
Problem #4. How long AFD changes are propagated
Changes to AFD configuration need some time, so after a change to the routing rule or backend configuration keep calm and wait some time (from my experience 7-10 minutes) to get changes propagated.
More useful information can be found in this article
Comments
Post a Comment