I am setting up load balancing on Azure websites. In reviewing the documentation at https://our.umbraco.org/Documentation/Getting-Started/Setup/Server-Setup/Load-Balancing/flexible#scheduling-and-master-election, I have a question about the umbracoApplicationUrl and the domain names. We have set up 2 websites: abcd-front.azurewebsites.net (for the front-end) and abcd-master.azurewebsites.net (for the backend) (not their real names). abcd-master has 1 instance; abcd-front has 1 instance now, but is on a separate Azure App Service plan, and can be scaled out.
The documentation states that:
Flexible Load Balancing will automatically elect a "Scheduling server" to perform the above services. This means that all of the servers will need to be able to resolve the URL of either: itself, the Master server, the internal load balancer or the public address.
and that:
By default, Umbraco will set the "umbracoApplicationUrl" to the address made by the first accepted request when the AppDomain starts. It is assumed that this address will be a DNS address that the server can resolve.
For example, if a public request reached the load balancer on "www.mysite.com", the load balancer may send the request on to the servers with the original address: "www.mysite.com" so by default the "umbracoApplicationUrl" will be "www.mysite.com". However, load balancers may route the request internally under a different DNS name such as "f02.mysite.local" which by default would mean the "umbracoApplicationUrl" is "f02.mysite.local". In any case the elected "Scheduling server" must be able to resolve this address.
We use IIS URL Rewrite module to do a canonical redirect so that all requests get redirected to the primary domain. I guess we need to disable this for the master website so that editors/admins don’t get redirected, but for the frontend website, will that cause a problem for the scheduler to reach the different servers?
A couple more questions: I also would like to know how best to block public access to the master server (I have an idea of how to accomplish this, but would like to hear others). Finally, how should we prevent admins/editors from accessing the backoffice via the frontend website?
I also would like to know how best to block public access to the
master server (I have an idea of how to accomplish this, but would
like to hear others).
I would recommend using digest auth in this: https://github.com/nabehiro/HttpAuthModule It'll be similar to how UaaS blocks access to the non-production environments. What's nice is that it also has a web.config application settings on/off switch, which means you can make the value sticky in the Azure portal.
Finally, how should we prevent admins/editors from accessing the
backoffice via the frontend website?
I'd recommend having a redirect from livesite.com/umbraco/$ go to stagemaster.azurewebsites.net/umbraco/ The $ (i.e. match ender) is important since you still need to allow ajax api stuff on your live site, and all that ajax goes to livesite.com/umbraco/....
Not sure if I completely understand your first one, but hopefully the above helps you some!
In the case you describe you'll likely want to set the umbracoApplicationUrl to specifically the front end (public) Url as described in the documentation:
Depending on just how you'll treat your front-end Web App instances, you might also consider making the front ends "slaves." Essentially then the front ends will be read only and in that case you'll set the umbracoApplicationUrl to the Url for the master server - so you'll just need to make sure the front ends can reach this Url. There are docs and sample code for that approach here https://our.umbraco.org/documentation/Getting-Started/Setup/Server-Setup/load-balancing/flexible-advanced
I believe @Shola's suggestions for configuring auth for your master server and rewrite rule config are solid - and proven as well.
Also, not directly to a question you asked but a package that can leverage some of the benefits of Azure Web Apps is the Azure CDN Toolkit.
As with all load-balancing we can't stress enough the importance of testing, then testing some more. And we strongly recommend you create a stage/test environment that is an exact replica of your live environment so you can diagnose issues and verify changes in a "safer" way.
It's worth noting that umbracoApplicationUrl should always contain the "/umbraco" (I often forget this).
For example, my front end web app is on the domain "https://www.mydomain.com" and my backoffice web app is on the domain
"https://admin.mydomain.com" therefore umbracoApplicationUrl should be set to "https://admin.mydomain.com/umbraco" for both web apps
I'm still unclear on how the different instances get notified. Are they polling for updates from the master? I haven't scaled out yet but I've implemented the redirects and they seem to be working.
@Shola, thanks for the tip on the HttpAuthModule. I've been using a simple one and was looking something like that.
@Paul, I haven't yet set the umbracoApplicationUrl - not sure I need to? Also, I've been meaning to use Azure Logger package for that other project we are hoping to launch soon, but just haven't had time. We've borrowed ideas for the CDN toolkit for that before it as launched. @Jeavon - great stuff!
Any tips on testing? Is there a way to target different server instances with Azure websites? Fortunately this is a fairly simple site, so I don't expect any suprises... (knock on wood).
DNS for Flexible Load-balancing on Azure Websites
I am setting up load balancing on Azure websites. In reviewing the documentation at https://our.umbraco.org/Documentation/Getting-Started/Setup/Server-Setup/Load-Balancing/flexible#scheduling-and-master-election, I have a question about the umbracoApplicationUrl and the domain names. We have set up 2 websites: abcd-front.azurewebsites.net (for the front-end) and abcd-master.azurewebsites.net (for the backend) (not their real names). abcd-master has 1 instance; abcd-front has 1 instance now, but is on a separate Azure App Service plan, and can be scaled out.
The documentation states that:
and that:
We use IIS URL Rewrite module to do a canonical redirect so that all requests get redirected to the primary domain. I guess we need to disable this for the master website so that editors/admins don’t get redirected, but for the frontend website, will that cause a problem for the scheduler to reach the different servers?
A couple more questions: I also would like to know how best to block public access to the master server (I have an idea of how to accomplish this, but would like to hear others). Finally, how should we prevent admins/editors from accessing the backoffice via the frontend website?
I would recommend using digest auth in this: https://github.com/nabehiro/HttpAuthModule It'll be similar to how UaaS blocks access to the non-production environments. What's nice is that it also has a web.config application settings on/off switch, which means you can make the value sticky in the Azure portal.
I'd recommend having a redirect from
livesite.com/umbraco/$go tostagemaster.azurewebsites.net/umbraco/The $ (i.e. match ender) is important since you still need to allow ajax api stuff on your live site, and all that ajax goes tolivesite.com/umbraco/....Not sure if I completely understand your first one, but hopefully the above helps you some!
@Alex
In the case you describe you'll likely want to set the
umbracoApplicationUrlto specifically the front end (public) Url as described in the documentation:Depending on just how you'll treat your front-end Web App instances, you might also consider making the front ends "slaves." Essentially then the front ends will be read only and in that case you'll set the
umbracoApplicationUrlto the Url for the master server - so you'll just need to make sure the front ends can reach this Url. There are docs and sample code for that approach here https://our.umbraco.org/documentation/Getting-Started/Setup/Server-Setup/load-balancing/flexible-advancedI believe @Shola's suggestions for configuring auth for your master server and rewrite rule config are solid - and proven as well.
For logging have a look at the Azure Logger package .
Also, not directly to a question you asked but a package that can leverage some of the benefits of Azure Web Apps is the Azure CDN Toolkit.
As with all load-balancing we can't stress enough the importance of testing, then testing some more. And we strongly recommend you create a stage/test environment that is an exact replica of your live environment so you can diagnose issues and verify changes in a "safer" way.
It's worth noting that umbracoApplicationUrl should always contain the "/umbraco" (I often forget this).
For example, my front end web app is on the domain "https://www.mydomain.com" and my backoffice web app is on the domain "https://admin.mydomain.com" therefore umbracoApplicationUrl should be set to "https://admin.mydomain.com/umbraco" for both web apps
Thanks Shola, Paul and Jeavon!
I'm still unclear on how the different instances get notified. Are they polling for updates from the master? I haven't scaled out yet but I've implemented the redirects and they seem to be working.
@Shola, thanks for the tip on the HttpAuthModule. I've been using a simple one and was looking something like that.
@Paul, I haven't yet set the umbracoApplicationUrl - not sure I need to? Also, I've been meaning to use Azure Logger package for that other project we are hoping to launch soon, but just haven't had time. We've borrowed ideas for the CDN toolkit for that before it as launched. @Jeavon - great stuff!
Any tips on testing? Is there a way to target different server instances with Azure websites? Fortunately this is a fairly simple site, so I don't expect any suprises... (knock on wood).
Alex
is working on a reply...