This section describes best practices with running Umbraco on Azure Web Apps

What are Azure Web Apps

They have been called a few names in the past, many people still know Azure Web Apps as Azure Web Sites.

App Service is a fully Managed Platform for professional developers that brings a rich set of capabilities to web, mobile and integration scenarios. Quickly create and deploy mission critical web Apps that scale with your business by using Azure App Service.

You can read more about them here

Umbraco will run on Azure Web Apps but there are some configuration options and specific Azure Web Apps environment limitations to be aware of.

Recommended configuration

You need to add these configuration values. E.g in a json configuration source like appSettings.json:

{
    "Umbraco": {
        "CMS": {
            "Global": {
                "MainDomLock" : "FileSystemMainDomLock"
            },
            "Hosting": {
                "LocalTempStorageLocation": "EnvironmentTemp"
            },
            "Examine": {
                "LuceneDirectoryFactory": "SyncedTempFileSystemDirectoryFactory"
            }
        }
    }
}

You can also copy the following JSON directly into your Azure Web App configuration via the Advanced Edit feature.

{
  "name": "UMBRACO__CMS__Global__MainDomLock",
  "value": "FileSystemMainDomLock",
  "slotSetting": false
},
{
  "name": "UMBRACO__CMS__Hosting__LocalTempStorageLocation",
  "value": "EnvironmentTemp",
  "slotSetting": false
},
{
  "name": "UMBRACO__CMS__Examine__LuceneDirectoryFactory",
  "value": "SyncedTempFileSystemDirectoryFactory",
  "slotSetting": false
}

Remember to add an ASPNETCORE_ENVIRONMENT variable with values Development, Staging, or Production.

The minimum recommended Azure SQL Tier is "S2", however noticeable performance improvements are seen in higher Tiers

If you are load balancing or require the scaling ("scale out") ability of Azure Web Apps then you need to consult the Load Balancing documentation. This is due to the fact that a lot more needs to be configured to support scaling/auto-scaling.

Storage

It is important to know that Azure Web Apps uses a remote file share to host the files to run your website. This is due to the files running your website do not exist on the machine running your website. In many cases this isn't an issue. It can become one if you have a large amount of IO operations running over remote file-share.

Issues with read-only filesystems

Although Umbraco can be configured to use environmental storage it still requires its working-directory to be writable. If Umbraco is deployed to a read-only file system it will fail to boot.

For example, Azure's Run from Package feature is not supported by Umbraco. To check if your web app is using this feature you can check the WEBSITE_RUN_FROM_PACKAGE environment variable.

Scaling

If you require the scaling ("scale out") ability of Azure Web Apps you need to consult the Load Balancing documentation. This is due to the fact that a lot more needs to be configured to support scaling/auto-scaling.

Web worker migrations

It's important to know that Azure Web Apps may move your website between their 'workers' at any given time. This is normally a transparent operation. In some cases you may be affected by it if any of your code or libraries use the following variables:

• Environment.MachineName (or equivalent)

When your site is migrated to another worker, these variables will change. You cannot rely on these variables remaining static for the lifetime of your website.

How to find the Linux App Service Logs

The quickest way to get to your logs is using the following URL template and replacing {app} with your Web App name:

https://{app}.scm.azurewebsites.net/api/logstream

You can also find this in the KUDU console by clicking Advanced Tools > Log Stream on the Web App in the Azure Portal.

Web App secret management

Consult the Azure Key Vault documentation if you would like to directly reference Azure Key Vault Secrets to your Azure Web App.

Secure Sockets Layer (SSL) and HTTPS

We strongly encourage the use of HTTPS with Umbraco installations especially in production environments. Using HTTPS will greatly enhance the security of your website, see the Security reference for more information.

File & folder permissions

To ensure a stable and smoothly running Umbraco installation, these permissions need to be set correctly.

Hosting v9+ in IIS

Information about hosting a v9 application using IIS.

Load Balanced setup

Information on how to deploy Umbraco in a Load Balanced scenario and other details to consider when setting up Umbraco for load balancing.

Running Umbraco on Azure Web Apps

Best practices for running Umbraco on Azure Web Apps.

Runtime modes

The runtime mode setting optimizes Umbraco for the best development experience or optimal production environment.

Umbraco v8+ uses Serilog for logging. When load balancing Umbraco consideration should be given as to how the log files from each server will be accessed.

There are many Serilog Sinks available and one of these may be appropriate to store logs for all servers in a central repository such as Azure Application Insights or Elmah.io.

For more information, see SeriLog Provided Sinks.

This describes some more advanced techniques that you could achieve with flexible load balancing

The election process that runs during the startup of an Umbraco instance determines the server role that instance will undertake.

There are two server roles to be aware of for flexible load balancing:

• SchedulingPublisher - The Umbraco instance usually used for backoffice access, responsible for running scheduled tasks.

• Subscriber - A scalable instance that subscribes to content updates from the SchedulingPublisher server, not recommended to be used for backoffice access.

Explicit SchedulingPublisher server

It is recommended to configure an explicit SchedulingPublisher server since this reduces the amount of complexity that the election process performs.

The first thing to do is create a couple of small classes that implement IServerRoleAccessor one for each of the different server roles:

public class SchedulingPublisherServerRoleAccessor : IServerRoleAccessor
{
    public ServerRole CurrentServerRole => ServerRole.SchedulingPublisher;
}

public class SubscriberServerRoleAccessor : IServerRoleAccessor
{
    public ServerRole CurrentServerRole => ServerRole.Subscriber;
}

then you'll need to replace the default IServerRoleAccessor for the your custom registrars. You'll can do this by using the SetServerRegistrar() extension method on IUmbracoBuilder from a Composer.

// This should be executed on your single `SchedulingPublisher` server
builder.SetServerRegistrar<SchedulingPublisherServerRoleAccessor>();

// This should be executed on your `Subscriber` servers
builder.SetServerRegistrar<SubscriberServerRoleAccessor>();

Now that your subscriber servers are using your custom SubscriberServerRoleAccessor class, they will always be deemed 'Subscriber' servers and will not attempt to run the automatic server role election process or task scheduling.

By setting your SchedulingPublisher server to use your custom SchedulingPublisherServerRoleAccessor class, it will always be deemed the 'SchedulingPublisher' and will always be the one that executes all task scheduling.

Subscriber servers - Read-only database access

In some cases infrastructure admins will not want their front-end servers to have write access to the database. By default front-end servers will require write full access to the following tables:

• umbracoServer

• umbracoNode

This is because by default each server will inform the database that they are active and more importantly it is used for task scheduling. Only a single server can execute task scheduling and these tables are used for servers to use a server role election process without the need for any configuration. So in the case that a subscriber server becomes the SchedulingPublisher task scheduler, it will require write access to all of the Umbraco tables.

In order to have read-only database access configured for your front-end servers, you need to implement the Explicit SchedulingPublisher server configuration mentioned above.

Now that your subscriber servers are using your custom SubscriberServerRoleAccessor class, they will always be deemed 'Subscriber' servers and will not attempt to run the automatic server role election process or task scheduling. Because you are no longer using the default ElectedServerRoleAccessor they will not try to ping the umbracoServer table.

Controlling how often the load balancing instructions from the database are processed and pruned

The configurations can be adjusted to control how often the load balancing instructions from the database are processed and pruned.

Below is shown how to do this from a JSON configuration source.

{
    "Umbraco": {
        "CMS": {
            "Global": {
                "DatabaseServerMessenger": {
                    "MaxProcessingInstructionCount": 1000,
                    "TimeBetweenPruneOperations": "00:01:00",
                    "TimeBetweenSyncOperations": "00:00:05",
                    "TimeToRetainInstructions": "2.00:00:00"
                }
            }
        }
    }
}

Options:

• TimeToRetainInstructions - The timespan to keep instructions in the database; records older than this number will be pruned.