Should Umbraco be able to work out that it's running on Azure and apply sensible defaults?
I often deploy Umbraco to Azure Web Apps, sometimes standalone, sometimes load-balanced.
Incorrect configuration for Azure (if I'm honest, usually a missed setting in an XML file), is by far the most common problem I encounter. And when I come to (issues|our).umbraco.org I see lots of other people having similar Azure specific problems.
More often than not the solution is found after a pouring through various forum posts, links to documentation, overlapping blog posts from other devs etc. but it always feels like a bit of a mission - especially when Azure Web Apps are essentially all the same.
Would it make sense to change the default value for things like umbracoContentXMLUseLocalTemp if Umbraco detects that it is running in an Azure Web App ?
This new setting umbracoLocalTempStorage (which still needs to be documented) supersedes, the umbracoContentXMLStorage which supersedes the umbracoContentXMLUseLocalTemp setting. Basically the Umbraco files that need to be stored in local temp (fast) storage will use this single new setting so that would be: The xml cache file, the distributed cache file marker, and the plugins cache file. Examine indexes cannot uses this setting because Examine doesn't know what Umbraco is.
So although we could detect things like Environment Variables to determine the site is running on Azure, it would still require some additional config for things like Examine. For the most part, if it's a single server instance you are setting up, it's just the 2 configuration parts: umbracoLocalTempStorage and configuring Examine.
Could we not use the azure portal application settings on azure webapps in some way?
Don't all freshly deployed webapps get an app setting of
WEBSITE_NODE_DEFAULT_VERSION = 6.9.1
which if an asp.net appsetting key is set with the same name will seamlessly inherit that as a this is azure?
I've only recently discovered that if I set a connection string in the application settings of the webapp of umbracoDbDSN, that I don't have to do any changes to the web.config on deployment as this also seamlessly overwrites the web.config connectionstring of the same name.... so a trustedconnection string for local dev that exposes no pwds/usernames simpy uploads and works for the live db with connection details hidden away in the portal settings. (original post below from 2013 doh.. how come I didn't know this)
So rather than have a separate code base with settings in place from the azure gallery, could we not have the same code base with simply add these to the portal web app - application settings.. (with the proviso that these same keys need to exist in a default non azure state in the core) and maybe even some clever powershell script to run against azure on first deploy to work out the umbraco version and apply other settings like the examine ones?
Just thought does this not smack of a Health Check for Azure?
There is no separate codebase. The marketplace is the same codebase, i was saying that this marketplace instance should already have the pre-configured configuration.
Yes, there are environment variables you can use WEBSITE_SITE_NAME is the main one to check but as i mentioned previously this will not work for all required settings like Examine so you will still need to do some config updates regardless
Thanks Shannon, I hadn't seen the documentation change as of 7.6/Examine v0.1.80+
And yes, given the amount of other tweaks we make in config files to get Umbraco configured the way we need it, making the change is not as big a deal as remembering to make the change in the first place.
Perhaps then it's just a case of adding it to the Health Check section to point out that the site is running in Azure and extra configuration may apply (with a link to the docs?).
Shanon thanks, maybe codebase was the wrong word..
What I was meaning was that if I deploy from azure gallery, then fetch local I now have different settings in web.config and examine.config... than if I had deployed locally from the latest release on our and then wanted to deploy to azure later.
Ideally I don't want to have to make any changes to the files (when deploying local to azure or cloning azure to local) and it would seem that setting azure portal settings to override default settings in the web.config was the simplest of solutions. (no external config settings files or build scripts required) At that point umbraco never needs to know it's on azure as it's azure sorting the settings.
I understand your point about the examine.index settings, could that not still be a manual intervention though via a health check, the health check doesn't need to know it's azure but the user clicking the add azure examine settings would?
and as I think you alluded to doesn't have the settings you've mentioned.
In all this I don't really understand if running a local dev site would have any problems with the same azure specific settings applied, so all this could be moot??
Just musing as this is a very specific deployment, and umb obv needs to maintain a generic approach for any platform.
Should Umbraco be able to work out that it's running on Azure and apply sensible defaults?
I often deploy Umbraco to Azure Web Apps, sometimes standalone, sometimes load-balanced.
Incorrect configuration for Azure (if I'm honest, usually a missed setting in an XML file), is by far the most common problem I encounter. And when I come to (issues|our).umbraco.org I see lots of other people having similar Azure specific problems.
More often than not the solution is found after a pouring through various forum posts, links to documentation, overlapping blog posts from other devs etc. but it always feels like a bit of a mission - especially when Azure Web Apps are essentially all the same.
Would it make sense to change the default value for things like
umbracoContentXMLUseLocalTempif Umbraco detects that it is running in an Azure Web App ?HI,
Been a while since I've deployed to Azure but wouldn't this be better in the Health Check section... in fact, is it not already?
Steve
We do have one set of instructions for configuration on Azure websites https://our.umbraco.org/Documentation/Getting-Started/Setup/Server-Setup/azure-web-apps so you shouldn't need to jump through hoops to get the info you need.
I've been thinking about this recently too but when we implemented a new setting recently - http://issues.umbraco.org/issue/U4-10503
This new setting
umbracoLocalTempStorage(which still needs to be documented) supersedes, theumbracoContentXMLStoragewhich supersedes theumbracoContentXMLUseLocalTempsetting. Basically the Umbraco files that need to be stored in local temp (fast) storage will use this single new setting so that would be: The xml cache file, the distributed cache file marker, and the plugins cache file. Examine indexes cannot uses this setting because Examine doesn't know what Umbraco is.So although we could detect things like Environment Variables to determine the site is running on Azure, it would still require some additional config for things like Examine. For the most part, if it's a single server instance you are setting up, it's just the 2 configuration parts:
umbracoLocalTempStorageand configuring Examine.We should make sure the template that exists here in the Azure Marketplace https://azuremarketplace.microsoft.com/en-us/marketplace/apps/umbracoorg.UmbracoCMS has the correct config settings in place.
Could we not use the azure portal application settings on azure webapps in some way?
Don't all freshly deployed webapps get an app setting of
which if an asp.net appsetting key is set with the same name will seamlessly inherit that as a this is azure?
I've only recently discovered that if I set a connection string in the application settings of the webapp of umbracoDbDSN, that I don't have to do any changes to the web.config on deployment as this also seamlessly overwrites the web.config connectionstring of the same name.... so a trustedconnection string for local dev that exposes no pwds/usernames simpy uploads and works for the live db with connection details hidden away in the portal settings. (original post below from 2013 doh.. how come I didn't know this)
So rather than have a separate code base with settings in place from the azure gallery, could we not have the same code base with simply add these to the portal web app - application settings.. (with the proviso that these same keys need to exist in a default non azure state in the core) and maybe even some clever powershell script to run against azure on first deploy to work out the umbraco version and apply other settings like the examine ones?
Just thought does this not smack of a Health Check for Azure?
There is no separate codebase. The marketplace is the same codebase, i was saying that this marketplace instance should already have the pre-configured configuration.
Yes, there are environment variables you can use
WEBSITE_SITE_NAMEis the main one to check but as i mentioned previously this will not work for all required settings like Examine so you will still need to do some config updates regardlessThanks Shannon, I hadn't seen the documentation change as of 7.6/Examine v0.1.80+
And yes, given the amount of other tweaks we make in config files to get Umbraco configured the way we need it, making the change is not as big a deal as remembering to make the change in the first place.
Perhaps then it's just a case of adding it to the Health Check section to point out that the site is running in Azure and extra configuration may apply (with a link to the docs?).
Shanon thanks, maybe codebase was the wrong word..
What I was meaning was that if I deploy from azure gallery, then fetch local I now have different settings in web.config and examine.config... than if I had deployed locally from the latest release on our and then wanted to deploy to azure later.
Ideally I don't want to have to make any changes to the files (when deploying local to azure or cloning azure to local) and it would seem that setting azure portal settings to override default settings in the web.config was the simplest of solutions. (no external config settings files or build scripts required) At that point umbraco never needs to know it's on azure as it's azure sorting the settings.
I understand your point about the examine.index settings, could that not still be a manual intervention though via a health check, the health check doesn't need to know it's azure but the user clicking the add azure examine settings would?
Also having had a client provide an azure gallery deployment ready to go... it was only 7.7.1? https://github.com/umbraco/Umbraco-Azure-Gallery
and as I think you alluded to doesn't have the settings you've mentioned.
In all this I don't really understand if running a local dev site would have any problems with the same azure specific settings applied, so all this could be moot??
Just musing as this is a very specific deployment, and umb obv needs to maintain a generic approach for any platform.
is working on a reply...