Following my blog post on Azure right after the Sitecore Symposium, I now finally can share the actual provisioning of a Sitecore deployment running on Azure Web Apps! Earlier this week, Sitecore released its new version 8.2 Update 1, which contains a lot of fresh Sitecore & Azure goodness (maybe even more than the Initial Release of Sitecore 8.2). In the last two weeks, I also presented about this topic at two different Sitecore User Group meetings, one in Belarus and one in the Netherlands. On the bottom of this blog post, you can find both the slides and the recordings of these talks.

So without further ado, lets skip the introduction I gave in my talks and in my previous blog post, and jump right to the fun part!

Deployment strategy

With the new Azure Web Apps hosting option, Sitecore leverages the full potential of Azure for the first time since its Cloud support. One of the largest advantages being the separation of concern when rolling out and maintaining a Sitecore environment: provisioning, deployment and hosting management are now clearly separated.

Provisioning

Initially, you will need to provision your Sitecore environment. You can do this via the Azure Marketplace or by using the ARM templates provided by Sitecore, executed via a PowerShell script. The latter one is the more advanced and versatile option, and also the option of my choice for this blog post. When provisioning your Sitecore environment, you will create all the assets or building blocks you need, leaving you with a vanilla Sitecore installation when ready. However, it is possible to extend the baseline you’re rolling out, as shown by Bas Lijten in his blog post on using the Azure Toolkit.

Deployment

After the initial provisioning, it’s time to deploy your custom Sitecore solution. You can do this using various methods, like a direct Web Deploy, by using a Web Deploy Package, or via your favorite Continuous Delivery tool such as VSTS, TeamCity or Jenkins. I will show you the easiest and most basic option in this blog post, using Web Deploy directly from Visual Studio, as the purpose of my blog post is to show you the Azure Web Apps specific tasks, and I consider the various deployment methods to be out of scope for this blog post.

Mind that you only have to deploy the delta of what changed in your solution, since the vanilla installation is already there after provisioning the environment. Secondly, mind that you only have to deploy your solution once per Sitecore server role (like Content Management or Content Delivery), as Web Apps share the file system when scaling out. Lastly, you should deploy to a staging slot and not directly to the current production slot. This also enables you to test and scale out before going live.

The provisioning is a one time action. Deployment is a repeatable step for each new release. And both the packages together (when using Web Deploy Packages for your custom deployment) make up a nice disaster recovery kit.

Hosting

After deploying your own solution to Azure, you can manage and maintain your hosting environment. Next to applying or adjusting security, configuring geo-replication (which isn’t supported yet in Update 1 by the way) and monitoring via Application Insights – scaling up, down and / or out is one of the easy tasks you can perform. The best practise as also explained in my previous blog post, is to deploy to a single instance per Sitecore server role in a staging slot and scale out afterwards to the desired number of App instances. The default provisioning provided by Sitecore puts every server role in a different App Service plan to be able to scale each role differently.

Scaling out Web Apps in Azure is as simple as selecting the number of instances, or configuring the desired lower and upper boundaries of the number of instances, combined with the desired CPU percentage per instance – 0r by simply clicking the desired plan when scaling up:

The building blocks

Web Apps

Sitecore uses separate Web Apps to host the web site roles (like Content Management, Content Delivery, Processing and Reporting). Each Web App is placed in its own App Service Plan to enable it to scale separately.

Application Insights

Application Insights is used for all Health Monitoring needs, like searching for all Sitecore logs, performance counters & custom telemetry. No local log files anymore!

Azure Search

Sitecore uses Azure Search as its default search engine. Azure Search is a fully managed search-as-a-service that offers scalable full-text search.

Azure SQL

Sitecore uses Azure SQL to store all of its content and analytics databases. Note that the default provisioning script places the Web database in a different SQL server instance.

Azure Redis Cache

Sitecore uses Azure Redis Cache as its default session state backend, used to store information from active visitors to be used by the content delivery and personalization process. This is great news, because Redis is very easy to configure and previous Sitecore versions didn’t support the use of Redis Cache combined with Sitecore xDB due to the lack of an onSessionEnd event on the side of Redis. This now has been fixed, so we can all enjoy the power of Redis :-).

mongoDB

The collection database (MongoDB) is the primary storage for all analytics information and the registry of contacts and engagement automation states. You can use a VM hosting mongoDB or you can use as SaaS service like mLab (which I have used for this demo).

How to provision your Web Apps environment

ARM templates

As explained earlier, ARM (Azure Resource Manager) templates are an Azure standard, using JSON to automate the creation of resources within Azure. Dependencies between those resources can also be configured. You can use them both for initial provisioning as for your Continuous Delivery setup, but for now we will aim at provisioning only.

To set up the site and its databases, Sitecore uses Web Deploy and DACPAC packages.

The ARM templates provided by Sitecore differ per seat in the Consumption Based license model and can be downloaded from their GitHub account. Currently only XM, XP0 and XP1 are available, but other seats will follow shortly (probably when Sitecore releases new updates of 8.2).

Pre-requisites for using ARM

The pre-requisites are quite small:

• You need PowerShell version 4.0 or greater
• You need to have the latest Azure PowerShell CmdLets installed
• You need to have the .NET Framework 4.6 running on your machine
• You need a running mongoDB instance (which I did via the free Sandbox tier of mLab)

You can use the PowerShellGet module to be able to aquire the Azure CmdLets and please make sure the execution policy of your user is set high enough to run these commands. You can set it to AllSigned if you want, to be sure you have enough privileges:

Then, simply run the following commands to install the Azure CmdLets:

For more information on this subject check https://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/.

Sitecore Web Deploy Packages (SCWDP)

You can install Sitecore using the well known installer option, but for deploying to Azure you actually need to host a different SCWDP package per server role your environment will be using. These packages can be downloaded from the Sitecore Developer Portal as well, under the section “Download options for Azure AppService”. I have used the full XP1 version for my demo.

Unpack the provided zip file and upload the files contained in the package one by one to your Azure blob storage. I have created a separte resource group for this storage account, because the resource group hosting the Sitecore resources itself will be recreated and deleted continuously while testing. You can create a storage account using Standard performance and the Cool access tier, because you will not access these blobs often and this setup will be the most cost efficient. The type has to be Blob storage. The files can be uploaded as a Block blob using the default block size of 4MB. Lastly, please don’t forget to change the Access policy to Blob instead of Private if you did not configure security (of course, you should not host Sitecore software publically and share the URL of your blob storage!).

This is what you will end up with: you need to copy the URL of all the packages, because you need them in your ARM parameter file later on.

Please note that you can alter these SCWDP packages (they contain DACPAC files for the database, which you can alter or remove, the Sitecore published webroot and configuration parameters that you can alter or extend). The prefered method to create these packages is using the Sitecore Azure Toolkit (see Bas’ blog mentioned above), but for now that’s out of the scope of this blog post.

Configuring your ARM template & PowerShell script

The ARM template provided by Sitecore is accompanied by a parameter file, with the extension “parameter.json”. Start by populating the parameter values in this file using your own custom values. The deploymentId and licenseXml parameters can be left empty, for they will be populated by the PowerShell script later on.

First, enter a password to use for the Sitecore admin account. Yes, you got it right.. no admin/b anymore! The password has to be at least 8 characters in length. Then you need to enter a random generated token as an API authentication key. No restrictions as far as I know, but I would advise a minimum length of 32 characters here. After that, you can paste in the connection strings of your mongoDB databases and come up with a username and password for your SQL server instances to be. The latter credentials are new ones and do not have to match anything yet. Last but not least, populate the package URL parameters with the URL’s of the SCWDP packages you’ve uploaded to your own blob storage, and that’s it!

Top tip: please note that the ARM template itself contains a ‘hidden parameter’ called “applicationinsights.location” which points to “East US” by default. If you want to use your own location for your AI instance, you can alter the default location within the ARM template, or populate the parameter value from within the PowerShell script. I chose the easy way out and changed the ARM template to:

PowerShell example script

Next to the ARM templates, Sitecore has also included an example PowerShell script to get you up and running with the ARM templates quickly. It’s in the README.md file of the aformentioned GitHub repository. You can also use the Sitecore PowerShell CmdLet for this, but I always like to go the custom script route first, so I exactly understand what is going on, before moving to a pre-defined CmdLet.

Within the PowerShell script, you need to change a small number of attribute values as well:

Make sure the ARM template paths point to the right files and place your own license.xml file next to the PowerShell script (which I’ve named “Run.ps1”). Then, set your resource group name, your Azure data center location (I am running in West Europe) and your Azure subscription ID.

Now, you can run the PowerShell script using an elevated PowerShell command prompt using the command: “.\Run.ps1” and the provisioning will start!

Manual login or Service Principal

By default, the PowerShell script lets you login into your Azure subscription via a popup, where you can login manually. This works for the demo and for your R&D, but doesn’t work well in an automated Continuous Delivery process or tool. In that case, you want to configure a Service Principal to do the authentication for you. I won’t go into detail on that, but you can find all the info and parameters in the example PowerShell script of Sitecore.

Deployment succesful?

If you want to know if the provisioning succeeded, don’t be distracted by the end phrase the example script from Sitecore writes to your screen. For some reason, no matter if the provisioning failed or not, the output always ends with the message “Deployment succesful!”:

So that isn’t very helpful. If you really want to know if the provisioning succeeded, you need to scroll up a bit and look for the “ProvisioningState” value. This value tells you accurately whether the provisioning succeeded or not:

Deployment

After some 25 minutes, your vanilla Sitecore enviroment will be provisioned. Actually, about 75% of that time is taken by the provisioning of Redis. All other resources are created quite fast. If you now want to deploy to your freshly created Web App, you can simply login to Azure, browse to the desired Web App instance (depending on the Sitecore server role you want to deploy to) and select the option “… More” in the upper right corner and then “Get publish profile”. This file can be imported by Visual Studio and allows you to deploy direct into the Web App service plan using VS Web Deploy. Due to the length of this blog post I won’t go into detail on this, but if you want to see the entire process, please watch the screencast video below!

Screencast

I’ve also made a screencast of the whole process (a bit slow but thorough I guess) so you can follow all the steps on video. This is also the part that I demo in the following SUG presentations, but being a screencast it may be easier to follow all the little details. Please note that this particular demo is based on the early access preview, which is slightly different than the actual release! In my SUGNL presentation you can see the released version of Sitecore 8.2 Update 1.

User Group presentations

SUG Belarus recording

My Azure Web Apps presentation just prior to the release of 8.2 Update 1 at the Sitecore User Group in Belarus:

SUGNL recording

My Azure Web Apps presentation a day after the (full) release of 8.2 Update 1 at the Sitecore User Group in the Netherlands:

And the slides of my Azure Web Apps presentation:

or download the slides as a PDF document from the SUGNL website!