How to stick app config settings to a slot via bicep?
Here is my bicep file:
var stagingSettings = [
{
name: 'AzureFunctionsJobHost__extensions__durableTask__hubName'
value: 'staging'
slotSetting: true
}
]
resource functionApp 'Microsoft.Web/sites/slots#2018-11-01' = {
name: name
kind: kind
location: location
properties: {
clientAffinityEnabled: true
enabled: true
httpsOnly: true
serverFarmId: resourceId('Microsoft.Web/serverfarms', servicePlanName)
siteConfig: {
use32BitWorkerProcess : false
appSettings: stagingSettings
}
}
identity: {
type: 'SystemAssigned'
}
}
On deploying this code, I don't see app config settings stick to a slot:
checkbox is not checked. What am I missing?
You need to create a slotConfigNames resource:
Names for connection strings, application settings, and external Azure storage account configuration
identifiers to be marked as sticky to the deployment slot and not moved during a swap operation.
This is valid for all deployment slots in an app.
Something like that should work:
param functionAppName string
resource functionApp 'Microsoft.Web/sites#2018-11-01' existing = {
name: functionAppName
}
resource functionApps 'Microsoft.Web/sites/config#2021-03-01' = {
name: 'slotConfigNames'
parent: functionApp
properties: {
// Sticky app settings
appSettingNames: [
'AzureFunctionsJobHost__extensions__durableTask__hubName'
]
}
}
Related
I have tried numerous methods and the workflow is still deployed enabled.
My latest attempt was to use the resource in my bicep:
resource workflow 'Microsoft.Web/sites/workflows#2015-08-01' = {
name: workflowName
dependsOn: [ logicContainer ]
location: location
kind: 'Stateful'
properties: {
flowstate: 2
}
}
However, the workflow never appears in the Logic App function.
I cannot even deploy the container in the 'Stopped' state, since for Microsoft.Web/sites#2022-03-01, state is readonly.
In my yaml I send a the workflows in a pipe separated string e.g. "wf-one|wf-two|wf-three|wf-four"
Then, in my bicep I populate an array of Workflow states app settings:
var wfAppSettingStatuses = [ for wf in split(workflows,'|'): {
name: 'Workflows.${wf}.FlowState'
value: 'Disabled'
}]
To add to the Logic App container configuration settings use the union function:
resource logicContainer 'Microsoft.Web/sites#2022-03-01' = {
name: appName
location: location
kind: 'functionapp,workflowapp'
identity: {
type: 'SystemAssigned'
}
properties: {
httpsOnly: true
siteConfig: {
appSettings: union(wfAppSettingStatuses, [
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: applicationInsights.properties.InstrumentationKey
}
...
])
use32BitWorkerProcess: true
}
serverFarmId: planId
clientAffinityEnabled: false
vnetRouteAllEnabled: true
storageAccountRequired: false
keyVaultReferenceIdentity: 'SystemAssigned'
}
}
Each workflow in the list is now disabled, therefore if you require one to be enabled on deployment, remove it from the pipe delimited string.
main.bicep
resource appService 'Microsoft.Web/sites#2020-06-01' = {
name: webSiteName
location: location
properties: {
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: linuxFxVersion
appSettings: [
{
name: 'ContainerName'
value: 'FancyContainer'
}
{
name: 'FancyUrl'
value: 'fancy.api.com'
}
]
}
}
}
The infrastructure release process is run successfully, and the app settings are set correctly, after that I run the node application build and release where the Azure DevOps release pipeline adds some application-related config to app settings. (API keys, API URLs, for example) and everything works great.
But if I have to rerelease infrastructure, for example, I expand my environment with a storage account, the app settings which the application release set are lost.
Is there a workaround to keep app settings which not defined in Bicep template?
From this article: Merge App Settings With Bicep.
Don't include appSettings inside the siteConfig while deploying.
Create a module to create/update appsettings that will merge the existing settings with new settings.
appsettings.bicep file:
param webAppName string
param appSettings object
param currentAppSettings object
resource siteconfig 'Microsoft.Web/sites/config#2022-03-01' = {
name: '${webAppName}/appsettings'
properties: union(currentAppSettings, appSettings)
}
main.bicep:
param webAppName string
...
// Create the webapp without appsettings
resource webApp 'Microsoft.Web/sites#2022-03-01' = {
name: webAppName
...
properties:{
...
siteConfig: {
// Dont include the appSettings
}
}
}
// Create-Update the webapp app settings.
module appSettings 'appsettings.bicep' = {
name: '${webAppName}-appsettings'
params: {
webAppName: webApp.name
// Get the current appsettings
currentAppSettings: list(resourceId('Microsoft.Web/sites/config', webApp.name, 'appsettings'), '2022-03-01').properties
appSettings: {
Foo: 'Bar'
}
}
}
I'm trying to deploy a .NET Core 3.1 Azure App Service on Linux using a Bicep template from Azure CLI. The app service and corresponding app service plan are deployed correctly but the app service stack settings are empty on the Azure portal and I have to set these manually. I tried setting the metadata property on the 'Microsoft.Web/sites' resource and also on the 'Microsoft.Web/sites/config' resource, but the result was the same.
This is my app service plan:
resource appServicePlan 'Microsoft.Web/serverfarms#2021-02-01' = {
name: 'MyAppService'
location: resourceGroup().location
properties: {
reserved: true
}
sku: {
name: 'P1v2'
}
kind: 'linux'
}
Here is my first attempt to set the stack using 'Microsoft.Web/sites' as suggested here:
https://github.com/Azure/bicep/issues/3314
resource appService 'Microsoft.Web/sites#2021-02-01' = {
name: 'MyApp'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
kind: 'app'
properties: {
enabled: true
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: 'dotnet|3.1'
appCommandLine: 'dotnet MyApp.dll'
metadata: [
{
name: 'CURRENT_STACK'
value: 'dotnetcore'
}
]
}
}
}
Here is my second attempt to set the stack using 'Microsoft.Web/sites/config' as suggested here:
Bicep - How to config Runtime Stack to Azure App Service (Bicep version 0.4)
resource appService 'Microsoft.Web/sites#2021-02-01' = {
name: 'MyApp'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
kind: 'app'
properties: {
enabled: true
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: 'dotnet|3.1'
appCommandLine: 'dotnet MyApp.dll'
}
}
resource webConfig 'config' = {
name: 'web'
properties: {
metadata: [
{
name: 'CURRENT_STACK'
value: 'dotnetcore'
}
]
}
}
}
The result is the same. The deployment is completed with the following warning:
Warning BCP037: The property "metadata" is not allowed on objects of
type "SiteConfig". Permissible properties include
"acrUseManagedIdentityCreds", "acrUserManagedIdentityID", "alwaysOn",
"apiDefinition", "apiManagementConfig", "autoHealEnabled",
"autoHealRules", "autoSwapSlotName", "azureStorageAccounts",
"connectionStrings", "cors", "defaultDocuments",
"detailedErrorLoggingEnabled", "documentRoot", "experiments",
"ftpsState", "functionAppScaleLimit",
"functionsRuntimeScaleMonitoringEnabled", "handlerMappings",
"healthCheckPath", "http20Enabled", "httpLoggingEnabled",
"ipSecurityRestrictions", "javaContainer", "javaContainerVersion",
"javaVersion", "keyVaultReferenceIdentity", "limits", "loadBalancing",
"localMySqlEnabled", "logsDirectorySizeLimit", "managedPipelineMode",
"managedServiceIdentityId", "minimumElasticInstanceCount",
"minTlsVersion", "netFrameworkVersion", "nodeVersion",
"numberOfWorkers", "phpVersion", "powerShellVersion",
"preWarmedInstanceCount", "publicNetworkAccess", "publishingUsername",
"push", "pythonVersion", "remoteDebuggingEnabled",
"remoteDebuggingVersion", "requestTracingEnabled",
"requestTracingExpirationTime", "scmIpSecurityRestrictions",
"scmIpSecurityRestrictionsUseMain", "scmMinTlsVersion", "scmType",
"tracingOptions", "use32BitWorkerProcess", "virtualApplications",
"vnetName", "vnetPrivatePortsCount", "vnetRouteAllEnabled",
"websiteTimeZone", "webSocketsEnabled", "windowsFxVersion",
"xManagedServiceIdentityId". If this is an inaccuracy in the
documentation, please report it to the Bicep Team.
[https://aka.ms/bicep-type-issues]
The resources are deployed, but the app service stack setting is blank and I have to set it manually to make it work.
I know that in the ARM template this is set on the CURRENT_STACK property of the Microsoft.Web/sites/config metadata (as suggested here https://cloudstep.io/2020/11/18/undocumented-arm-oddities-net-core-app-services/). However, this doesn't seem to be supported (yet) in Bicep. If anyone has found a working solution, please post it here.
Thanks.
The Metadata parameter is not available anymore in the SiteConfig. The stack setting can be mentioned LinuxFxVersion.
So, solution will be Instead of using dotnet|3.1 , You should use DOTNETCORE|3.1.The over all code will be as below:
resource appServicePlan 'Microsoft.Web/serverfarms#2021-02-01' = {
name: 'MyAppService'
location: resourceGroup().location
properties: {
reserved: true
}
sku: {
name: 'P1v2'
}
kind: 'linux'
}
resource appService 'Microsoft.Web/sites#2021-02-01' = {
name: 'anumantestapp'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
kind: 'app'
properties: {
enabled: true
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: 'DOTNETCORE|3.1'
appCommandLine: 'dotnet MyApp.dll'
}
}
}
Ouptut:
I have a bicep template that creates 2 webApps and a KeyVault. Each WebApp is created with a managedID which I need to add to Keyvault so the webapp can pull in the secrets.
But when creating 2 webapps, I can't work out how to assign both ManagedIDs to KeyVault.
The bicep template is using modules
name: 'ciKeyVault'
params: {
keyVaultName: keyVaultName
aclBypass: keyVaultSettings.aclBypass
aclDefaultAction: keyVaultSettings.aclDefaultAction
enabledForDeployment: keyVaultSettings.enabledForDeployment
enabledForDiskEncryption: keyVaultSettings.enabledForDiskEncryption
enabledForTemplateDeployment: keyVaultSettings.enabledForTemplateDeployment
keyPermissions: keyVaultSettings.keyPermissions
keyVaultSettings: keyVaultSettings
secretsPermissions: keyVaultSettings.secretsPermissions
skuFamily: keyVaultSettings.skuFamily
skuName: keyVaultSettings.skuName
tenantId: subscription().tenantId
objectId: 'b71e61c4-7cff-41d0-8370-a7d9c01dde84'
}
}
and the objectId needs to be retrieved from the AppService Deployment. using this module:
module AppService '../../../Modules/Azure.App.Service.template.bicep' = [for i in range(0, length(webAppSettings.webApps)): {
name: webAppSettings.webApps[i].Name
dependsOn: [
frontEndAppServicePlan
]
params: {
webAppName: webAppSettings.webApps[i].appServiceType == 'functionApp' ? toLower('fnc-${webAppSettings.webApps[i].name}-${resourceGroupNameSuffix}') : toLower('web-${webAppSettings.webApps[i].name}-${resourceGroupNameSuffix}')
hostingPlan: frontEndAppServicePlan.outputs.hostingPlanId
virtualNetworkResourceGroup: virtualNetworkResourceGroup
environmentName:environmentName
webAppSettings:webAppSettings
appServiceType: webAppSettings.webApps[i].appServiceType
LinuxFX:webAppSettings.webApps[i].LinuxFX
appSettings:webAppSettings.webapps[i].appSettings
}
}]
Its fine when its a single appService cause I can reference the ID using output usid string = AppServices.identity.principalId
but when I have 2 appServices I can't work out how to pass in both IDs
Any ideas?
Cheers
Let's say you have a module Azure.App.Service.template.bicep that looks like that:
param webAppName string
...
// Create the web app
resource webApp 'Microsoft.Web/sites#2020-09-01' = {
name: webAppName
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
...
}
output usid string = webApp.identity.principalId
In the parent template you can create an array of module to create your webapps (the same way you are doing it) and then create an access policies resource to grant access to key vault to all the web apps.
...
// Create the app services
module AppServices '../../../Modules/Azure.App.Service.template.bicep' = [for webApp in webAppSettings.webApps: {
name: webApp.Name
params: {
webAppName: webApp.Name
...
}
}]
// Granting the app services access ot key vault
resource appServicesKeyVaultAccessPolicies 'Microsoft.KeyVault/vaults/accessPolicies#2019-09-01' = {
name: '${keyVaultName}/add'
properties: {
accessPolicies: [for i in range(0, length(webAppSettings.webApps)): {
tenantId: subscription().tenantId
objectId: AppServices[i].outputs.usid
permissions: {
secrets: keyVaultSettings.secretsPermissions
keys: keyVaultSettings.keyPermissions
}
}]
}
}
I am currently trying to deploy out a resource group using azure bicep, however, I am running into an issue using key vault for my azure app service. I would like to know if I am actually doing this the correct way. I have a main bicep file that is along the lines of:
// params removed for brevity...
targetScope = 'subscription'
resource rg 'Microsoft.Resources/resourceGroups#2021-04-01' = {
name: 'rg-${appName}-${region}'
location: 'centralus'
}
module appServicePlan 'appplan.bicep' = {
params: {
sku: appServicePlanSku
appName: appName
region: region
}
scope: rg
name: 'AppServicePlanDeploy'
}
module keyVault 'keyvault.bicep' = {
params: {
keyVaultName: keyVaultName
sqlPassword: sqlServerPassword
webSiteManagedId: webSite.outputs.webAppPrincipal
}
scope: rg
name: 'KeyVaultDeploy'
dependsOn: [
webSite
]
}
module ai 'ai.bicep' = {
scope: rg
name: 'ApplicationInsightsDeploy'
params: {
name: appName
region: region
keyVaultName: keyVault.outputs.keyVaultName
}
dependsOn: [
keyVault
]
}
resource kv 'Microsoft.KeyVault/vaults#2019-09-01' existing = {
name: keyVaultName
scope: rg
}
module sql 'sqlserver.bicep' = {
scope: rg
name: 'SQLServerDeploy'
params: {
appName: appName
region: region
sqlPassword: kv.getSecret('sqlPassword')
sqlCapacitity: sqlCapacitity
sqlSku: sqlSku
sqlTier: sqlTier
}
dependsOn: [
keyVault
]
}
module webSite 'site.bicep' = {
params: {
appName: appName
region: region
keyVaultName: keyVaultName
serverFarmId: appServicePlan.outputs.appServicePlanId
}
scope: rg
name: 'AppServiceDeploy'
dependsOn: [
appServicePlan
]
}
My question comes with the implementation of the site.bicep, I started off by passing the secret uri from exported variables and creating the web app last as app insights, sql, etc... all need to be setup and in keyvault before we use their exported secret uri to construct a config. I had something along the lines of:
site.bicep (before):
properties: {
serverFarmId: serverFarmId
keyVaultReferenceIdentity: userAssignedId
siteConfig: {
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: '#Microsoft.KeyVault(SecretUri=${appInsightsConnectionString})'
}
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: '#Microsoft.KeyVault(SecretUri=${appInsightsKey})'
}
]
netFrameworkVersion: 'v5.0'
}
}
The only problem with this implementation is that the key vault MUST be constructed before the website because sql, ai, and the other services will store their values inside of the key vault for the web app to consume by their respective uris. The issue with this is that the KeyVault rightfully so has no idea which azure service to let access it's keys.
My question is the solution of constructing the web app before the key vault the only way to beat this problem? I am using managed identities on the web app and would like to continue doing so if possible. My final solution ended up somewhat like this:
site.bicep (final)
// params removed for brevity...
resource webApplication 'Microsoft.Web/sites#2020-12-01' = {
name: 'app-${appName}-${region}'
location: resourceGroup().location
tags: {
'hidden-related:${resourceGroup().id}/providers/Microsoft.Web/serverfarms/appServicePlan': 'Resource'
}
identity: {
type: 'SystemAssigned'
}
properties: {
serverFarmId: serverFarmId
siteConfig: {
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiConnectionString)'
}
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiInstrumentationKey)'
}
{
name: 'AngularConfig:ApplicationInsightsKey'
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiInstrumentationKey)'
}
]
netFrameworkVersion: 'v5.0'
}
}
}
output webAppPrincipal string = webApplication.identity.principalId
And the KeyVault which will take a dependsOn webSite
keyVault.bicep(final):
resource keyVault 'Microsoft.KeyVault/vaults#2019-09-01' = {
name: keyVaultName
location: resourceGroup().location
properties: {
enabledForDeployment: true
enabledForTemplateDeployment: true
enabledForDiskEncryption: true
enableRbacAuthorization: true
tenantId: subscription().tenantId
sku: {
name: 'standard'
family: 'A'
}
accessPolicies: [
{
tenantId: subscription().tenantId
objectId: webSiteManagedId
permissions: {
keys: [
'get'
]
secrets: [
'list'
'get'
]
}
}
]
}
}
Just treat your accessPolicies as separate resource and add them when both Key Vault and App Service are created. Same applies for Config section and Connection Strings. Check documentation here.
In ARM templates you can achieve same effect using nested templates. In Bicep it is kind the same, but you declare them as separate resource that usually contains parent name (e.g. name: '${kv.name}/add', name: '${webSite.name}/connectionstrings')
Sample
Step 1: Create an App Service without config section
resource webSite 'Microsoft.Web/sites#2020-12-01' = {
name: webSiteName
location: location
properties: {
serverFarmId: hostingPlan.id
siteConfig:{
netFrameworkVersion: 'v5.0'
}
}
identity: {
type:'SystemAssigned'
}
}
Step 2: Create Key Vault without access policies
resource kv 'Microsoft.KeyVault/vaults#2019-09-01' = {
name: keyVaultName
location: location
properties:{
sku:{
family: 'A'
name: 'standard'
}
tenantId: tenantId
enabledForTemplateDeployment: true
accessPolicies:[
]
}
}
Step 3: Create new access policy and reference Web Apps Managed Identity
resource keyVaultAccessPolicy 'Microsoft.KeyVault/vaults/accessPolicies#2021-06-01-preview' = {
name: '${kv.name}/add'
properties: {
accessPolicies: [
{
tenantId: tenantId
objectId: webSite.identity.principalId
permissions: {
keys: [
'get'
]
secrets: [
'list'
'get'
]
}
}
]
}
}
Step 4: Update Webb app config section
resource webSiteConnectionStrings 'Microsoft.Web/sites/config#2020-06-01' = {
name: '${webSite.name}/connectionstrings'
properties: {
DefaultConnection: {
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiConnectionString)'
type: 'SQLAzure'
}
}
}
One solution could be to use User Assigend Identity instead of System Assigned. Then you would deploy the following:
Deploy a user assigend identity
Key Vault and assign permissions for user assigned identity
Deploy web app with user assigned identity and read / write secrets
User assigned is independent of the resources and so you avoid your chicken and egg problem.
More:
https://learn.microsoft.com/en-us/azure/templates/microsoft.managedidentity/userassignedidentities?tabs=bicep
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
You should split up three parts of your deployment into separate resources:
Deploy the Key Vault - without any access policies!
Deploy the App Service - with the SystemAssigned Identity, but without the app settings
Deploy the Key Vault Access Policy for the MSI
Deploy the App Settings