Press enter to see results or esc to cancel.

Sitecore 8.2-1 on Azure Web Apps

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.

deployment-strategy

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:

scaling-web-apps

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.

blob-storage

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!”:

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:

provisioning-state

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!

 

Comments

16 Comments

mahesh kava

very helpful. much appreciated

Martin English

Wonderful Post Rob! I am about to stand up a new 8.2 Azure environment for one of our clients and your detailed post had all the information that I was looking for.

Cheers!

Rob Habraken

Thanks Martin!

Vidhi Sharma

Well Structured content with complete context from Provisioning to Deployment to Hosting Details.

Thanks !

Vikas

Hi Rob,

Nice article and very useful.

Can you please let us know how we will migrate existing production running xdb Application to Azure.

Which we will select PAAS/SAAS.

What would be the best approach.

Rob Habraken

Thanks Vikas! I would advise you to first setup a vanilla Sitecore environment in Azure (which is PaaS by the way). If that runs fine and you have finished the scripts and acquired the knowledge, it’s a matter of deploying your custom implementation to that environment. You don’t want to copy anything over from the current environment. Regarding the already running production databases for xDB, it really depends on what solution you have there. If you currently run an Azure VM (IaaS) or a SaaS service like mLab, you can just copy paste the connection strings into your new setup (into the ARM template parameter file). If it runs on prem, you might want to consider migrating your MongoDB databases to an Azure VM first.

Make sure to also check out my other blog posts about this topic: Blue Green Sitecore Deployments on Azure and Azure templates update.

Vikas

Thanks Rob quick reply..

Its running in on premise data centre and now I am thinking to move all xdb (Sitecore 8.1) applications to Cloud.

Vikas

Hi Rob,

Correct me If I am wrong:

If we go with New Sitecore Azure Paas model than we have to make below change as well as.

We have to upgrade Sitecore 8.0/8.1 to 8.2 version first
Instead of Lucens search we have to use Azure search.
Custom databases also move to Azure SQl.
Mongo db would be installed on Azure VM or will be Mslab

Should this new model will fully support all the SItecore module like WFFM EXM or etc..

Please let me know if there are any other changes or challenges.

Thanks

Rob Habraken

Hi Vikas, that is true. You have to upgrade to at least 8.2 Update 1, but I would recommend going straight to Update 4. Lucene can be used on your dev box, but in the Cloud you should use Azure Search indeed. If you use these scripts it’ll come provisioned and ready to use, but to be honest, the most issues we saw to date were Azure Search related. If you like, a VM with Solr could also work, just so you know that there’s a valid alternative ;-). Rest of your suggestions are correct. And regarding all the modules: you need Update 3 for that, but it should work. Didn’t test WFFM on Azure Web Apps myself though. Regards, Rob

Vikas

Thanks Rob…

Vikas

Hi Rob,

I have watched your Blue Green Sitecore Deployment on Azure video and it is very informative.

Is it possible to you share the PPT or doc with us. My email id is chauhan.vikas@rediffmail.com.

Thanks,
Vikas

Rob Habraken

Hi Vikas, they are on the bottom of the post, via a link to SlideShare :-). Please check Blue Green Sitecore Deployments on Azure. You can download them too over there.

Abhishek

That’s an excellent blog Rob. I am trying to replicate whatever you have done and reached till where we deployed the vanilla 8.2.1 instance to Azure Web App. Quick question, on my locally deployed vanilla Sitecore instance I see my data folder outside of the application root. I just used the exec from the Sitecore downloads. Even the available zipped root folder from the Sitecore downloads has data folder outside of the root. Since I am at a point to deploy my local customizations to azure web app not sure how this data folder discrepancy will impact.

Will appreciate your suggestions.

Rob Habraken

Hi Abhishek,

the Sitecore Web Deploy packages (SCWDP files) are set up with the data folder placed inside the App_Data folder within the web root. If you only deploy your changes (delta), known as ‘working outside the webroot’, this will automatically be configured correctly. So you can use a local exec install locally, deploy the project from Visual Studio to this local installation, while deploying the same solution to the Cloud based on SCWDP files.

Good luck with your Sitecore implementation!
regards, Rob

Abhishek

Hey Rob,

Thanks for the suggestions. I literally tried to follow the steps you mentioned and tried deploying to the local installation (web root from WDP packages). However unfortunately I got stuck with data folder thing again :(.

When I browse this local installation get the below error –
https://www.screencast.com/t/sklpG0fJ1

I really do know from where the path ” D:\home\site\wwwroot\App_Data” is coming from. Its not hard coded anywhere in my config files and all data folder path references are relative. Usually all my IIS sites resides in default C:\inetpub\wwwroot folder.

I understand that for Azure app services, the path “D:\home\site\wwwroot” acts as default but not really sure if it has anything to do with the local environment.
Is it a mandate for WDP package installation to go in D:?

Appreciate the inputs.

Thanks

Rob Habraken

Hello Abhishek,

The root path seems to be correct, but shouldn’t be configured hard coded indeed. The issue doesn’t seem familiar to me, as we did not have a problem with this, although we do publish a different config set to Azure than locally. I have sent you an email, let’s try to find out what goes wrong. Easier than debugging via blog post comments :-).

regards, Rob


Leave a Comment

Rob Habraken

Software Engineer, Technical Manager, Consultant, Sitecore MVP and overall technology addict. Specialist in web development, Microsoft technology and, of course, Sitecore.

https://www.robhabraken.nl