App Service (Web App): How to manage Slots App Settings using ARM templates and Azure Pipelines?

Question

Dear all,

We are currently working on automating deployment of an App Service (Web App) in Azure.

Our goals are:

• To use slots to do hot deployment
• To use an Azure DevOps Release pipeline and ARM templates for deploying the App Service resource, including the Staging slot
• To have another Azure Release pipeline to deploy the binaries of the application to the Staging slot, including App Settings values

Some settings are "deployment slot settings" and some aren't - see https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots for explanations.

The problem is, we can't find a way to differentiate the deployment slot settings from those who swap with the slot in ARM template. In ARM template, an App Setting is just a name - value pair, and all App Settings belong to the same App Settings resource type (see https://learn.microsoft.com/en-us/azuretemplates/microsoft.web/2018-02-01/sites).

To the best of my understanding this doesn't allow us to specify slot settings - so what is the solution to do that?

Thanks in advance for your answer.

Answer 1

https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/list-slot-configuration-names#slotconfignamesresource

@Nouvel R ,
Please see the link above.
<rant>It is sometimes too hard to get your question through</rant> :)

You can use this in your ARM Template or Bicep to manage Slot App Settings.
The names you specify in the corresponding string arrays becomes "Slot" settings - the little tiny mini checkbox that says "slot setting" gets checked.
IMHO, Microsoft should have made this a property of the appSetting, storageSetting and connectionStrings.
This is so error-prone. What if the name you give in this string array does not exist as a setting? LOL.

Here is a Bicep blurb - please note the name of the slotConfig_resource, it has to be "slotConfigNames".

param appService_SlotAppSettings array = [  
  'setting1'  
  'setting2'  
  'setting3'  
  'setting4'  
]  
resource appService_resource 'Microsoft.Web/sites@2021-01-01' = {  
  name: 'yourAppServiceName'  
  location: resourceGroup().location    
}  
  
resource slotConfig_resource 'Microsoft.Web/sites/config@2021-01-01' = {  
  name: 'slotConfigNames'  
  parent: appService_resource  
  properties:{  
    'appSettingNames': appService_SlotAppSettings  
  }  
}  



 

  

Answer 2

Thank you @Dabhan-MSFT ,

So to clarify - my question is very specific to App settings and to how to manage them when creating the Web App and the Slots programatically by the mean of ARM templates.

In the link that we share, section "Which settings are swapped?", the list "Settings that are swapped:" says "App settings (can be configured to stick to a slot)". Fine. So I have the option to choose which ones are swapped and which ones aren't.

Now when I look at the description of the ARM template to create the Web app (see https://learn.microsoft.com/en-us/azure/templates/microsoft.web/2019-08-01/sites ), I can't find a way to specify which App settings I want to swap and which ones I want to stick to a Slot, because there is only one appSettings section which only contains name / value pairs of App settings. And the slots (https://learn.microsoft.com/en-us/azure/templates/microsoft.web/2019-08-01/sites/slots/config ) use the same section.

Thus the question: how can I declare programatically an App setting is swappable and another one isn't?

Answer 3

Hi

Deploying your application to a non-production slot has the following benefits:

You can validate app changes in a staging deployment slot before swapping it with the production slot.
Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap when pre-swap validation isn't needed.
After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back.

Which settings are swapped?
When you clone configuration from another deployment slot, the cloned configuration is editable. Some configuration elements follow the content across a swap (not slot specific), whereas other configuration elements stay in the same slot after a swap (slot specific). The following lists show the settings that change when you swap slots.

Settings that are swapped:

General settings, such as framework version, 32/64-bit, web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Public certificates
WebJobs content
Hybrid connections *
Virtual network integration *
Service endpoints *
Azure Content Delivery Network *

Features marked with an asterisk (*) are planned to be unswapped.

Refer - https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#which-settings-are-swapped

Answer 4

You can add the following PS task. Hope this will help.

Get Azure Functions App Settings

Write-Host "Getting Azure Web App Settings..."
$azureWebNames = Get-AzureRmResource -ResourceGroupName "ResoruceGroupName" -ResourceType "Microsoft.Web/sites"

$azureWebNames | ForEach-Object -Process{
$webAppNames = $_.Name

$webAppSettings= Get-AzureRmWebAppslot -ResourceGroupName "ResoruceGroupName" -Name $webAppNames -slot "slotname"

$webAppSettings|  ForEach-Object -Process{
    $currentAppSettings = $functionAppSettings.SiteConfig.AppSettings
    $newAppSettings = @{}
        ForEach ($item in $currentAppSettings){
            $newAppSettings[$item.Name] = $item.Value
            $newAppSettings["CosmosDb_ConnectionString"] = $conn
            $newAppSettings["DatabaseName"] = $databaseName         
        }
    Set-AzureRmWebAppSot -AppSettings $newAppSettings -Name $webAppNames  -ResourceGroupName "ResoruceGroupName" -slot "slotname"
 }

}

Answer 5

An example to make slot sticky:

$connectionString = @{}
$webAppName = "Web AppName"
$resourceGroup ="Resource Group Name"
$slotName ="slot Name"
$connectionString.Add("AzureWebJobsStorage", @{ value = "The Actual connecting string here" ; Type = 3 }) #Custom
$connectionString.Add("Common", @{ value = "The Actual connecting string here" ; Type = 2 }) #Azure SQL

Login-AzureRmAccount

creat slot connection string

New-AzureRmResource -PropertyObject $connectionString -ResourceGroupName $resourceGroup
-ResourceType "Microsoft.Web/sites/slots/config" -ResourceName "$webAppName/$slotName/connectionstrings"
-ApiVersion 2015-08-01 -Force

set connection string as sticky setting

$stickSlotConfigObject = @{"connectionStringNames" = @("AzureWebJobsStorage","Common")} #connection string Name
Set-AzureRmResource -PropertyObject $stickSlotConfigObject -ResourceGroupName $resourceGroup
-ResourceType Microsoft.Web/sites/config -ResourceName $webAppName/slotConfigNames
-ApiVersion 2015-08-01 -Force

Refer: https://blogs.msdn.microsoft.com/benjaminperkins/2017/09/04/how-to-make-an-app-setting-or-connection-string-sticky/