We're using Umbraco 8.12.1 in a master/replica setup, with a single Backoffice (master) instance and a scalable frontend (replica) instance. The replica is configured to return a 404 if the /umbraco folder is requested.
Can I double-check how "umbracoApplicationUrl" in umbracosettings.config should be configured for the master and the replica.
Currently we have both the master and the replicas umbracoApplicationUrl set to the URL of the Backoffice address.
That post is older (Oct 2019) and is tagged as Umbraco 7, so perhaps this is something that has changed between v7 and v8? The reference to 'itself' could just be a red herring, written without any context of master/replica in mind?
The documentation on this is so ambiguous, even having checked the Umbraco 9 Docs, which in one place states it should include /umbraco and in another says it shouldn't (or at very least, makes zero mention of it and doesn't include it in the example provided).
In both cases, just as it does in the v8 docs, it continues to state:
"how the server should reach itself"
Itself....not the master server. So I am inclined to agree with Jeffries answer on the v7 post I link to above.
The docs really need to clarify this, probably in the 'Load Balancing > Scheduling and Master Election' page, which is the one place it does seem to suggest that the URL should be that of the master server and that the use of 'itself' elsewhere are misleading....
So double checking, in those docs the line the elected "Scheduling server" must be able to resolve this address.
Now if you have explicitly set one server as master and others as replica. Only the scheduling server needs to resolve that URL and it should be pointing at itself. In that instance the master server will be the scheduling server and so will need to know how to access itself.
So it's correct that the server should be able to access itself. But in an environment where you've fixed the master server to one server, only that server needs to be able to access itself, and only that server will care about that setting.
Back-office install explicitly configured to have ServerRole.Master
(and therefore, as I understand it, also explicity set to be the scheduling server)
Front-end install(s) explicitly configured to have ServerRole.Replica
I would agree entirely that the back-office install should have it's umbracoApplicationUrl set to https://admin.mysite.com/umbraco, I don't think there is any ambiguity there.
However, from what I can see in the Umbraco codebase setting my front-end install(s) umbracoApplicationUrl to either:
Leaving it unset entirely/null (i.e. letting it be inferred/updated with each request in to a frontend node)
both look to me like they'd cause unwanted and unexpected results? (at least in some scenarios)
I say that because this URL (whether explicitly set in umbracoSettings.config, IServerRegistrar.GetCurrentServerUmbracoApplicationUrl() or by being infered from the 1st and/or subsequent HTTP requests) ends up being stored in IRuntimeState.ApplicationUrl which is then used for things such as:
Various HealthCheckStatus like the HTTP headers checks and HTTPS checks under Settings > Security in the back-office
UmbracoApiControllerBase.ApplicationUrl
Back-office authentication call backs and links in User invitation emails
Now admittedly, I don't know what all of these do and maybe some of them will be irrelevant in the context of my frontend nodes (expected to be) unused /umbraco back-office interface, but some, like the ones in bold and probably the health checks, I would be pretty apprehensive about using anything but my frontend node(s) vanity URL of https://www.mysite.com/umbraco
If there is any doubt as to whether that's necessary/made use of by my frontend/replica install(s) or not, I'd certainly be more at ease using https://www.mysite.com/umbraco than allowing it to be any of:
http://localhost/umbraco (which I read can occur when Azure uses localhost to 'warm up' a new node when auto-scaling
That is, unless I am missing some good reason why explicitly setting umbracoApplicationUrl to https://www.mysite.com/umbraco on my frontend/replica servers would be a bad idea?
I always configure my front end nodes so /umbraco/* is 404'd
Things like health checks don't really work in a load balanced environment because they're just testing the local machine, not the front end servers.
For the Application URL I guess it would depend on whether your site is using the Umbraco API. If you are then you can't block /umbraco/* and it may be that your front end sites need to know where to look. I would set that to http://www.mysite.com/umbraco
For the ServerRegistrar stuff, in my playing a lot of that gets bypassed when you've explicitly set it. The background tasks should be run on the CMS box, not the front end servers.
Checking what we do with my setups the front end servers don't have the application url setting set at all, but if I was to set it I would set it to www. rather than admin. because they wouldn't be able to access admin. anyway in many cases. But I don't think they should really be pinging anything.
Would be nice to get this completely clarified in the documentation.
Makes sense. My frontend installs have /umbraco/* enabled still although I have instructed my client/users not to access it and to use the master server back-office UI instead.
This is because:
1) As you suggested, I have frontend nodes calling /Umbraco/Api/* (only for read-only based requests, anything which manipulates Umbraco data/DB is explicitly set to hit https://admin.mysite.com/Umbraco/Api/*)
2) I find it very useful to still have access to the back-office of frontend nodes as a developer, as it helps me debug issues (like Examine indexes differing between the master and replica nodes, another ongoing issue I have)
I am happy that I have done the right thing in my context, setting the umbracoApplicationUrl on my frontend installs to https://www.mysite.com/umbraco as you have suggested you would if you needed to manually set them to anything at all in your context.
umbracoApplicationUrl in master/replica solution
Hi,
We're using Umbraco 8.12.1 in a master/replica setup, with a single Backoffice (master) instance and a scalable frontend (replica) instance. The replica is configured to return a 404 if the /umbraco folder is requested.
Can I double-check how "umbracoApplicationUrl" in umbracosettings.config should be configured for the master and the replica.
Currently we have both the master and the replicas umbracoApplicationUrl set to the URL of the Backoffice address.
As an example:
Is this correct? I'm not entirely clear how it should be configured from the description at: https://our.umbraco.com/documentation/reference/config/umbracosettings/#umbracoapplicationurl
Many thanks!
Yes, It should be pointing at the master URL
I had this exact question as well as the docs are quite ambiguous on this, at least in the context of a master/replica set up.
Steve - How certain are you of this? I ask because this forum thread states the opposite: https://our.umbraco.com/forum/using-umbraco-and-getting-started/99761-load-balancing-and-umbracoapplicationurl
That post is older (Oct 2019) and is tagged as Umbraco 7, so perhaps this is something that has changed between v7 and v8? The reference to 'itself' could just be a red herring, written without any context of master/replica in mind?
Can anyone corroborate this claim?
The documentation on this is so ambiguous, even having checked the Umbraco 9 Docs, which in one place states it should include /umbraco and in another says it shouldn't (or at very least, makes zero mention of it and doesn't include it in the example provided).
In both cases, just as it does in the v8 docs, it continues to state:
"how the server should reach itself"
Itself....not the master server. So I am inclined to agree with Jeffries answer on the v7 post I link to above.
The docs really need to clarify this, probably in the 'Load Balancing > Scheduling and Master Election' page, which is the one place it does seem to suggest that the URL should be that of the master server and that the use of 'itself' elsewhere are misleading....
A lot of the docs are aimed at non-load balancing environments, or are misleading.
I don't have the front end servers with /umbraco URL available or even that folder installed.
I'm fairly certain it just needs to access a /umbraco URL
So double checking, in those docs the line
the elected "Scheduling server" must be able to resolve this address.Now if you have explicitly set one server as master and others as replica. Only the scheduling server needs to resolve that URL and it should be pointing at itself. In that instance the master server will be the scheduling server and so will need to know how to access itself.
So it's correct that the server should be able to access itself. But in an environment where you've fixed the master server to one server, only that server needs to be able to access itself, and only that server will care about that setting.
Thanks for taking the time to review and dig into it some more Steve.
Firstly, to confirm my set up/context:
I would agree entirely that the back-office install should have it's umbracoApplicationUrl set to https://admin.mysite.com/umbraco, I don't think there is any ambiguity there.
However, from what I can see in the Umbraco codebase setting my front-end install(s) umbracoApplicationUrl to either:
both look to me like they'd cause unwanted and unexpected results? (at least in some scenarios)
I say that because this URL (whether explicitly set in umbracoSettings.config, IServerRegistrar.GetCurrentServerUmbracoApplicationUrl() or by being infered from the 1st and/or subsequent HTTP requests) ends up being stored in IRuntimeState.ApplicationUrl which is then used for things such as:
NotificationsComponent.SendNotification
Now admittedly, I don't know what all of these do and maybe some of them will be irrelevant in the context of my frontend nodes (expected to be) unused /umbraco back-office interface, but some, like the ones in bold and probably the health checks, I would be pretty apprehensive about using anything but my frontend node(s) vanity URL of https://www.mysite.com/umbraco
If there is any doubt as to whether that's necessary/made use of by my frontend/replica install(s) or not, I'd certainly be more at ease using https://www.mysite.com/umbraco than allowing it to be any of:
That is, unless I am missing some good reason why explicitly setting umbracoApplicationUrl to https://www.mysite.com/umbraco on my frontend/replica servers would be a bad idea?
I always configure my front end nodes so /umbraco/* is 404'd
Things like health checks don't really work in a load balanced environment because they're just testing the local machine, not the front end servers.
For the Application URL I guess it would depend on whether your site is using the Umbraco API. If you are then you can't block /umbraco/* and it may be that your front end sites need to know where to look. I would set that to http://www.mysite.com/umbraco
For the ServerRegistrar stuff, in my playing a lot of that gets bypassed when you've explicitly set it. The background tasks should be run on the CMS box, not the front end servers.
Checking what we do with my setups the front end servers don't have the application url setting set at all, but if I was to set it I would set it to www. rather than admin. because they wouldn't be able to access admin. anyway in many cases. But I don't think they should really be pinging anything.
Would be nice to get this completely clarified in the documentation.
Morning Steve,
Makes sense. My frontend installs have /umbraco/* enabled still although I have instructed my client/users not to access it and to use the master server back-office UI instead.
This is because:
1) As you suggested, I have frontend nodes calling /Umbraco/Api/* (only for read-only based requests, anything which manipulates Umbraco data/DB is explicitly set to hit https://admin.mysite.com/Umbraco/Api/*)
2) I find it very useful to still have access to the back-office of frontend nodes as a developer, as it helps me debug issues (like Examine indexes differing between the master and replica nodes, another ongoing issue I have)
I am happy that I have done the right thing in my context, setting the umbracoApplicationUrl on my frontend installs to https://www.mysite.com/umbraco as you have suggested you would if you needed to manually set them to anything at all in your context.
Thanks for all the assistance and investigation.
HARVS17890UK
is working on a reply...