Settings.txt (Settings StorageConnectionString) in Azure Website

Topics: Installing Orchard
Dec 14, 2013 at 3:31 PM
Edited Dec 14, 2013 at 3:38 PM
I would like to host my orchard deployments on Azure Websites in multiple instances with auto-scale, much like Azure Cloud Services, but websites are much more cost effective.

I have deployed to Azure cloud services using:

I have deployed to Azure Websites using:
<component instance-scope="single-instance" type="Orchard.FileSystems.Media.ConfigurationMimeTypeProvider, Orchard.Framework" service="Orchard.FileSystems.Media.IMimeTypeProvider"></component>
On Azure Websites I have tried:
<component instance-scope="single-instance" type="Orchard.Azure.Services.Environment.Configuration.AzureBlobShellSettingsManager, Orchard.Azure" service="Orchard.Environment.Configuration.IShellSettingsManager"></component>
and receive this error running locally:
The type 'Orchard.Azure.Services.Environment.Configuration.AzureBlobShellSettingsManager, Orchard.Azure' could not be found. It may require assembly qualification, e.g. "MyType, MyAssembly".
note: I am assuming Azure Websites are not using shared storage between instances. If they do any links to MS stating that would be great.

Any assistance is appreciated.
Dec 23, 2013 at 1:25 AM
I can tell you that Azure Web Sites do indeed use a shared file system between instances. My understanding is it's based on Azure Drive, i.e. under the hood it consists of a VHD somewhere in Azure Blob Storage exposed to the instances as an SMB share. Therefore you should not enable settings storage when using Azure Web Sites.

You can enable the media storage (for reasons other than the multiple instance support, e.g. for CDN support and for offloading traffic from your instances).
Dec 4, 2014 at 9:12 PM
I know this is an old issue, but Azure Websites now supports deployment slots. These slots, from what I can tell, do not use shared storage but can be swapped with production. In that scenario, using blob storage for settings.txt may be beneficial as we would want the same settings in the pre-production deployment.

Our specific issue is that our website takes about 45-60 seconds to warm up after a deployment. This means that the first user will be penalized. Same goes for sub-pages within the site or anything that doesn't get initialized (warmed up) at application start. We use deployment slots to "warm up" our deployment prior to swapping with production. Unfortunately, right now we need to use cloud services and I am testing out trying to use blob storage for azure website settings so that we can move away from cloud services (there are SEVERAL other issues with cloud services, including issues with the lombiq hosting module for shared events across instances, and auto-scaling issues).

Now that Azure websites supports VNET access and deployment slots, we would like to move back to trying to use that instead of Cloud Services. It seems like cloud services have their place, but for website hosting, it causes more problems than it solves. Especially for multiple instances (farm) scenarios.
Dec 5, 2014 at 1:34 AM
I'm not sure I fully understand your specific issue, but in general, I think it makes more sense for swappable deployment slots to each have their own shell settings. The main reason for this is that when you do a deployment that contains any kind of schema changes, you will want to do that on a separate database so as to not jeapardize your swap back in cases where the old code won't work against the new database schema.

The workflow I try to follow is:
  1. I decide to make a new deployment.
  2. I clone the existing database X into a new database Y.
    3 I deploy the new code to staging, and point it to the new database Y.
  3. The new code runs in staging, and makes schema changes to database Y.
  4. I test everythnig out and/or perform warm-up etc.
  5. Once I'm happy everything works as it should, I swap.
  6. If at any time I discover issues post swapping, I swap back.
This does require that you don't do any content changes in the mean time, which may or maiy not be feasible in your scenario. If content changes have been made while you were testing against the cloned database however, you can always start over and make a new clone.