July 17, 2017 | Charlie Turano
This is the second in my series of blog posts on Sitecore deployments on Azure. The other posts in this series can be found here:-
Part 1: Setting Up the Solution and VSO Build
Installing Sitecore in an Azure environment can be complex due to the large number of options available to the user. I chose to use the XP environment (the most complex) with the lowest settings. This was done purely for research purposes, other environment configurations should work well with minor modifications to the scripts included here. This post goes over preparing a default setup for a Sitecore Azure deployment. Later (in the next post) we will be extending this to add a custom module to the install.
The first set of files to upload to blob storage are the Sitecore deployment files. These should be located in a single folder. I called my storage container sitecore82u3:
The Sitecore 8.2 rev. 170407_cd.scwdp.zip, Sitecore 8.2 rev. 170407_cm.scwdp.zip, Sitecore 8.2 rev. 170407_prc.scwdp.zip and Sitecore 8.2 rev. 170407_rep.scwdp.zip packages are the default packages from Sitecore. They can be downloaded for any particular Sitecore instance from that version's download page (i.e. you can find the packages for Sitecore 8.2 Update 4 under the 'Download options for Azure AppService' section)
These files contain the full Sitecore installations, and should be stored in a non-public blob. This means you will have to use the Azure Storage Explorer to create a shared access signature for each file. The full URL's for each file with the shared access signature should be added to the appropriate location in your azuredeploy.parameters.json file. An example file is included in our GitHub.
Note: The _nodb and _Bootload packages seen in the image will be discussed later in this blog post series. They will not yet be needed for the default setup described in this post.
As it turns out, there is an additional parameter in the deployment package, which is not referenced in the parameters. Bas Lijten pointed out to me that to fix this, you can either manually add that parameter to the ARM template, or rebuild the Web Deploy Package, removing the parameter. We opted to add it to the ARM template, passing in a hard-coded value. The following was added to the nested/application.json template file, for the CM deployment (the parameter is only required on CM for the xp setup) "Social Link Domain": "http://mywebsite.com/" The updated version of this file can be found on our Github repo. Within there we currently hard code the domain used by the Social Connect module....but you can modify it to read from parameters if you like, passing in a correct value. For now, the hard coded value gets us past the deployment issue, so grab the file and rename it to application.json, overwriting the default one that comes from Sitecore's repo. (it's a copy of the files from Sitecore's repo with the change above added, is up to date as of the 13th of July, 2017).
Our solution to this was to create a public blob storage container called sitecore and store all of the scripts in there. Since it was public, no shared access token was needed and everything worked correctly.
This was the option we went with....being the easiest to setup. You can see an alternative to this method further down the page.
The default ARM templates need to be uploaded into a storage container. Download the default ARM template scripts from the Sitecore GitHub repository. These scripts need to be uploaded into the sitecore Blob Container into a folder called xp. Everything in the /Sitecore 8.2.3/xp folder from Sitecore's default repository should be uploaded to the xp folder in the storage container.
Finally, grant public access to the container by right clicking it, and selecting 'Set Public Access Level...'. Grant Public read access for container and blobs, and click Apply.
Be sure to prepare your local PowerShell correctly. Open PowerShell using Administrator privileges, and make sure you have the appropriate prerequisites installed/prepared. Be sure to install the Azure and AzureRm modules.
Install-Module Azure -AllowClobber
Install-Module AzureRM -AllowClobber
Allow PowerShell to have the correct Execution Policy to run scripts. Set-ExecutionPolicy Unrestricted
Note that once you have the Azure and AzureRm PowerShell modules installed into your system, they are on the local machine....so future attempts won't require you to reinstall it.
Unblock, and Unzip the Azure Toolkit v1.1 to your system, noting the path, which can be pasted into the Install.ps1 script mentioned below.