Deploy to Azure Web Apps

17 min

The example creates an Alloy sample site using Visual Studio, but you can apply most steps to sites created in other ways.

Note See also the Installing the Optimizely Alloy sample site video for information about cloud installation.

Cloud requirements

You need a cloud-enabled license from the Optimizely License Center.

Microsoft Azure Portal requires an account with login details.

When you install a database using Microsoft Azure SQL Database, ensure that SQL Database supports each product and add-on that you want to use on the site for the site to work properly.

Ensure that each deployed application and module is designed for the cloud.

Set up a cloud website

The following image illustrates an Optimizely Content Management System (CMS) website running in an Azure Web Apps environment with multiple instances. The website instances share the same SQL database and BLOB storage that stores binary file data in the cloud environment. The sites are load-balanced, and a Service Bus manages events between the CMS websites.

Optimizely Content Management System (CMS) website running in an Azure Web Apps environment with multiple instances

deploying_to_azure.png

Using App Service plans, you can increase or reduce the number of CMS sites from the Azure portal. See Scale up an app in Azure App Service.

The following steps create a CMS website running in an Azure website environment.

Create a site

Creating a CMS site is based on the new .NET Core template, see Install Optimizely (ASP.NET Core).

Install the NuGet package EPiServer.Azure to the project.

Save your license file under the site root, on the same level in the folder structure as the /bin folder. The license is used and activated later when you deploy the website to Azure.

Create Azure resources

Create an Azure web app. a. In the Azure portal, click Create a resource in the top left corner, and select Web App.

b. Choose whether to create a resource group or use an existing group. (A resource group is a logical container into which web apps, databases, and so on are deployed.)

c. Enter a name for your web app. The name must be unique for web apps in Azure. d. Select Publish: Code, your Operating System, and Region. e. Select or create an App Service plan. f. The performance monitoring service Application Insights is enabled by default. If you want to turn it off, go to Monitoring and select No under Enable Application Insights. g. Click Review + create at the bottom of the panel and then Create again after you have reviewed your settings.

Tip Select Pin to dashboard to make it easier to find your web app later.

Create a SQL database. a. Select Create a resource in the top left corner, and select SQL Database. b. Select an existing server or create one, and provide a login user and password.

c. Click Review + create and then Create again after you have reviewed your settings. d. After the database is created, go to the database and select Security > Networking. e. Open the Public access tab and enable Selected networks.

f. Scroll down on the Public access tab and add your client and enable Allow Azure services and resources to access this server.

Create Azure BLOB storage. When you run on Azure, you should store media (such as images) in Azure BLOB storage to enable scaling. See Create a storage account for detailed steps. The storage container name must be in lowercase (such as mysitemedia) for DNS compatibility.

Tip Create two BLOB storage accounts: one for development and one for production, and switch between them using just the connection string.

Create a service bus. To scale the site to run on several instances, set up a Service Bus in Azure to handle messages among the site instances. See Create a Service Bus namespace for detailed steps.

Update the configuration

Change some configurations for the website to work with Azure.

Warning Do not skip this step! If you do, assets are stored locally, and will not deploy properly to the Azure BLOB storage.

There are two ways of configuring Azure resources; one way is by using the EPiServer.Azure package directly, and the other is by using the EPiServer.CloudPlatform.Cms NuGet package. The CloudPlatform configuration applies to DXP deployments using the deployment API.

Install the EPiServer.Azure NuGet package and register the Azure BLOB and event providers in your Startup.cs or Program.cs:

services.AddAzureBlobProvider(options =>
{
    options.ConnectionString = "<your-azure-storage-connection-string>";
    // Or 
    options.ServiceUri = "[http|https]://[storage name].blob.core.windows.net" ;
    options.ContainerName = "<your-azure-blob-storage-name>";
});

services.AddAzureEventProvider(options =>
{
    options.ConnectionString = "<your-service-bus-connection-string>";
    // Or
    options.Endpoint = "<your-service-bus-endpoint>";
});

Add the connection strings to appsettings.json:

    connectionString="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>"

c. Add a connection string named EPiServerAzureEvents (it should match the event provider name in episerver.framework). You can find the connection string to the event provider in the Azure portal under your service bus account > Settings > Shared access policies. Select the policy RootManagedSharedAccessKey. In a new panel you see the connection strings and access keys. The following example shows the three database connection strings in web.config, defined for Azure:

{
  "ConnectionStrings": {
    "EPiServerDB": "Server=tcp:abcdefgh.database.windows.net,1433;Database=mySiteDB;User ID=dbadmin@abcdefgh;Password={password};Trusted_Connection=False;Encrypt=True;Connection Timeout=30;",
    "EPiServerAzureBlobs": "DefaultEndpointsProtocol=https;AccountName=mystorageaccount;AccountKey=<key>",
    "EPiServerAzureEvents": "<your-service-bus-connection-string>"
  }
}

Using managed identity:

{
  "ConnectionStrings": {
    "EPiServerDB": "Server=tcp:abcdefgh.database.windows.net,1433;Database=mySiteDB;User ID=dbadmin@abcdefgh;Password={password};Trusted_Connection=False;Encrypt=True;Connection Timeout=30;",
    "EPiServerAzureEvents": "[service bus endpoint].servicebus.windows.net",
    "EPiServerAzureBlobs": "[http|https]://[storage name].blob.core.windows.net"
  }
}

EPiServerDB: Found in the Azure portal under your SQL database > Overview > Show database connection strings. Ensure MultipleActiveResultSets=True is included.

EPiServerAzureBlobs: Connection string found under your storage account > Settings > Access keys. For managed identity, use the blob service URI found under your storage account > Settings > Endpoints.

EPiServerAzureEvents: Connection string found under your service bus > Settings > Shared access policies. For managed identity, use the service bus endpoint found under your service bus > Overview.

Note The EPiServerAzureBlobs and EPiServerAzureEvents connection strings are optional if you already configured the connection strings directly in the service registration in step 1. Only EPiServerDB is always required. If set, these connection strings override the values configured in the service registration methods.

Deploy to Azure

The application or site must be pushed to a container registry, Azure provider, or such resource. There are many ways to push applications to the container registry in Azure; one way is by using Visual Studio, see Microsoft: Container Tools in Visual Studio.

From version 7.7 of CMS, there is a Bootstrap feature for content. It works so that if there is an export package located at [SolutionDir]\App\_Data\DefaultSiteContent.episerverdata that package is imported during initialization, and a site is created. The Bootstrap happens only if the site does not have any previous content. For cloud deployment, you may want to publish the project to the cloud environment before starting a local site configured against the cloud database. In that case, the Bootstrap happens in the cloud environment, which is much faster (because the site and database are likely in the same data center) and also sets the SiteUrl to the cloud URL for the created site.

You can also transfer data to an Optimizely site running on Azure Web Apps using the Optimizely CMS export/import functionality. Export the start page from your local site and database and import on the site running in Azure before continuing to the next step.

Create an admin or edit user

To log in to the site on Azure, create a user with access to the edit or admin view, start the local site while connected to the SQL Database, and perform the following steps. You must let the source IP address access the Azure database server. You can enable this in the Azure Portal on the specific SQL Database server (select the SQL server > Firewall/Virtual Networks > Add client IP).

Start the site (Debug/F5).

You are redirected to a register page to register the first user in the WebAdmins group.

Go to the CMS admin view > Administer Groups.

Create another group WebEditors. The WebAdmins and WebEditorsare default Optimizely groups providing access to the edit or admin user interface.

Go to Create User and create a user that is a member of WebAdmins and WebEditors. After deployment, you will need this user later when logging in to the Azure website.

Activate the license

Go to the CMS admin view and activate your cloud license on test and production environments. The running instances will count towards the total number of instances the license allows. See also Manage cloud licenses.

Change the site URL

Depending on how the site was created (see Deploying content), you might need to update the site definition for the CMS website created in the first steps after deployment. If so, log in to the website and go to the CMS admin view > Settings > Manage Websites, and change the Site URL to the URL in Azure. This will also map a hostname to the correct site in CMS. The URL can be found in the Azure portal. Select your web app > Overview, the site URL is given in the right column.

Activate logging

You can configure diagnostic logging for your App Service to send application logs to Azure Monitor, Log Analytics, or a storage account.

Open your App Service in the Azure portal and go to Diagnostic settings.

Click Add diagnostic setting.

Select the desired log categories and destination, then click Save.

See Enable diagnostics logging for apps in Azure App Service for detailed steps.

SQL database automatic tuning

The Azure SQL Database Automatic tuning is a feature that provides improved performance and automatic tuning of the database, based on AI and machine learning. You should leave the settings as default, and in particular, leave CREATE INDEX as Off, as turning it on might cause problems with the Optimizely Dynamic Data Store (DDS) and sub-optimal indexes.

See Automatic tuning in Azure SQL Database for more information.

Staged deployment

Azure Web Apps supports deployment slots, so you can deploy new code into a staging environment before moving it to production. To make sure deployment slots do not interfere with the production environment, make sure you define the EPiServerDB, EPiServerAzureEvents, and EPiServerAzureBlobs connection strings in the Azure portal as "sticky" (session affinity) to each slot. If a deployment slot re-uses the production connection strings, it is treated as a load-balanced server, part of the production environment, including licensing restrictions. See Set up staging environments in Azure App Service for details about using deployment slots.

Note Defining the EPiServerDB, EPiServerAzureEvents, and EPiServerAzureBlobs as connection strings in the Azure Portal requires at least EPiServer.CMS.Core 8.3.0.

The core parts of CMS do not use Session State, but some functionality does, such as some audience criteria. There are two approaches to enabling session state, depending on the sticky session feature (also known as session affinity) provided by Azure App Service, which ensures a user is reaching the same server combined with the default in-memory session state provider.

Another approach to enable better scaling is using an optimized provider for Azure, such as the session provider for Azure Web Apps.