Make use of Azure App Services for C1 CMS multiple-instance support

There are a number of things you need to consider when deploying a C1 CMS solution on a App Service.

Multiple-instance support and CM/CD deployments

An out-of-the-box C1 CMS deployment does not support multiple instances for the C1 console.

The frontend, however, does support them, and for a high throughput we recommend having 2 deployments with different configurations:

• Content management (CM) deployment. A single-instance deployment that C1 CMS administrators / content editors will use to update their website's content.
• Content delivery (CD) deployment.  A multiple-instance deployment for the frontend website.

To publish changes from CM to CD instance, the Cloud Publisher package can be configured.

Cloud Publisher allows pushing file changes from a CM instance to a GIT repository, and an Azure App Service can be configured to pick up new commits from a GIT repository automatically.

 graph TD;

subgraph DNS
cm_hostname[Content management hostname]
cd_hostname[Public website hostname]
end

subgraph azure[Azure App Services]
   cm_website[Content management CM<br>Single instance and minimal caching]
   appservciebuild[App Service Build Service]
   cd_website[Content delivery website<br>Multi-instance and caching enabled]
end 


cm_hostname -- CNAME or A record ---> cm_website
cd_hostname -- A Record--> cd_website


subgraph GIT
   git[GIT repository with website]
   cm_website -- Cloud Publisher --> git
end

   appservciebuild -- Reads changes from --> git
   appservciebuild -- Pushes changes to --> cd_website
	

To host a GIT repository, you can use one of the following:

• GitHub: A personal access token (PAT) can be used for this repository host at the moment when configuring Cloud Publisher
• Azure DevOps.  A PAT and Git Credentials can be used for this repository host at the moment when configuring Cloud Publisher

Service creation

The target ASP.NET version must be 4.8.

DNS mapping and SSL certificates

The built-in Azure DNS for App Services fails under high load, therefore for the public website hostname it is recommended that an "A" record be used instead of a "CNAME" record.

Registering a custom domain on an App Service requires access to the DNS service as creating a TXT record is needed to confirm the domain ownership.

Redirecting from non-"www." to "www." hostname

Many websites should be accessible both with and without "www." hostname prefix, for example: www.contoso.net and contoso.net:

1. Make sure both hostnames are configured in the "Custom domains" section of the Azure App Service in use, and an SSL certificate is attached to each.
2. Create a redirect from the non-"www" website to the "www" website.

Continuous deployment

When connecting to a GIT repository from your App Service, specify the build provider to be an "App Service Build Service".

Default document

To make sure that requests to the root of the website are handled correctly, specify the default documents in the "Settings" -> "Configuration -> "Default documents" to be:

• Default.aspx
• hostingstart.html
• index.html

Instance count

The number of instances can be increase to reduce request queueing, even if the CPU usage is less than 50%.

Updating config, XML and ASPX files live

All the instances of the same App Service share the same network drive.

When implementing custom code, it is necessary to take this fact into account. So if one instance holds a write lock on a file, other instances will not be able to read it.

The App Service Editor allows editing the deployed files live. When editing live, please consider the following:

• Changes to the /Bin folder, /web.config or /App_Config/*.config files will trigger a website restart, which may lead to short downtime (from 30 seconds to 1 or 2 minutes)
• Changes to XML data files /App_Data/Composite/DataStores/*.xml are usually picked up automatically, without the restart. However, any custom implementation here may cache some of the data, and a restart may be needed for the change to have an effect.
• Any changes to *.aspx files may stop the affected ASPX pages from working, until the App Service is restarted.