Deploy a Web App infrastructure using ARM templates

In my last post I discussed the basics of ARM templates and the Azure Resource Manager. In the following article, I would like to discuss a few other ways to deploy larger infrastructures, including dependencies, via an ARM template.

The example infrastructure to be built here consists of the following components:

• Web API (App Service)
• Deployment / Staging Slot für die Web API
• SQL Datenbank
• Redis Cache
• Azure Search
• Application Insights
• Auto-Scale Settings
• Alerts

All in all, a typical landscape for the backend of a modern web / mobile application. What is not covered in this example, is the Continuous Integration / Deployment area for the API or the database. The focus is entirely on the infrastructure and the corresponding “wiring” of the components. To illustrate the dependencies, here is a quick chart:

I will not go into all the details of the template, but point out the important sections that e.g. connect the WebApp to Azure Search, create the Content Delivery Network, create the staging slot etc.

Let’s get to the individual components…

WebAPI

The creation of the WebAPI differs marginally from the standard template, which can be generated via Visual Studio. Since there is only one API running in the WebApp and .NET code will be executed, some settings are adapted to it. Among other things, PHP (line 65) and ARR (line 18) are disabled, the AlwaysOn feature enabled (line 64), the 64bit environment activated (line 63), the default page is removed (line 66). In addition, all connection strings (starting with Line 20) and properties , which are necessary for the communication with other services in the template (starting line 38), are filled out during the deployment.

Deployment Slot / Staging

A deployment slot provides an additional endpoint / additional WebApp within the app service plan, into which the actual app can be deployed. Deployment slots are a popular feature to launch a new version of an application with almost zero-downtime. You deploy the new version into a slot, test the functionality, generate load to “warm up” the app and then swap the production slot with the staging slot (“swapping” – corresponds to an IP switch on the contained loadbalancer). This can be done either via the portal, Powershell or e.g. Visual Studio Team Services.

The template for the “staging slot” to be created is as follows:

Storage Account and Content Delivery Network

Nearly every web application / API must be able to deal with files and the associated “delivery”. A storage account (Blob Storage) is created for the storage of files. A content delivery network is then created, which has the appropriate storage account as the source. The important thing is that the container, which is responsible for storing the files in the storage account, is created at least with the “Blobs (anonymous read access for blobs only)” permission. Unfortunately, you can not create containers by ARM template at the time of writing (see: Let me define preconfigured Blob Containers, Tables, Queue in ARM template).

Important in this section of the template is the “linking” of the CDN with the storage account (starting from Line 31).

Azure Redis Cache and Azure Search

In order to provide users with the best possible performance of an application, caches (for general requirements / caching) or search engines (especially for the search in the respective data) are often used. Azure has the Azure Redis Cache and Azure Search offers in the service portfolio. The creation of the services is relatively simple, as you can see in the following template section.

The interesting thing about the two created resources is the selection of the admin keys, so that the web app gets access to the respective service. Similar to the connection string of the SQL server, connections strings / properties must be created with which the connection from the Web app can be established. The access to the keys of the Redis Cache and Azure Search are located in the web app resource (lines 33 and 49), for completeness here again:

The two functions listKeys and listAdminKeys are so-called resource functions, which are made available by the underlying resource provider. Theoretically, each resource provider can provide such functions. To find out which functions a provider supports, there is the possibility to “ask” via Powershell (or CLI, REST api) at the desired provider. For Azure Storage, Redis or Azure Search, the calls would look like this:

Get-AzureRmProviderOperation -OperationSearchString "Microsoft.Storage/*" | where {$_.Operation -like "*list*"} | FT Operation

Get-AzureRmProviderOperation -OperationSearchString "Microsoft.Cache/*" | where {$_.Operation -like "*list*"} | FT Operation

Get-AzureRmProviderOperation -OperationSearchString "Microsoft.Search/*" | where {$_.Operation -like "*list*"} | FT Operation

The official documentation for the template functions, in particular resource functions, can be found here: Resource functions for Azure Resource Manager templates.

Other Resources

The template used here contains other resources, such as application insights, scale settings and alerts for the web application, SQL DB etc., which are created “straightforward” and for which no further explanations are necessary.

In the end, settings / information, such as the instrumentation key of AppInsights or the connection string of the database, are entered automatically during deployment time in the corresponding resource (mainly the WebApp).

Deployment

To deploy the template, there are several options available, which I have already briefly discussed in the previous article. Therefore, I only provide the Powershell script here:

# Login to Azure
Login-AzureRmAccount

# Resource Group
$rg = "myappinfra-rg"
New-AzureRmResourceGroup -Name $rg -Location westeurope

# Deploy via Resource Group Deployment
New-AzureRmResourceGroupDeployment -ResourceGroupName $rg -Mode Complete -TemplateFile ".\azuredeploy.json" -TemplateParameterFile ".\azuredeploy.parameters.json"

Wrap Up

The template including parameter file and deployment script are available on GitHub.

Have fun with 🙂