-
Notifications
You must be signed in to change notification settings - Fork 59
Frequently Asked Questions (FAQs)
- Missing dependsOn
Please make sure you declare that the ZipDeploy resource depends on the site. Dependencies are required for resources that are deployed within the same template, especially when the order of creation matters. For Example: If function app site and ZipDeploy extension are being deployed in the same template, then it is important to declare that the ZipDeploy resource depends on the site. Because only after the creation of the site, we want to create ZipDeploy extension for deployment.
Solution: The following example shows declartion of dependsOn element, and for the full deployment template, see Function App with Basic Resources template:
"dependsOn": [
"[concat('Microsoft.Web/sites/', parameters('siteName'))]"
],
- Updating AppSettings in the same Template
Please make sure that the app settings are NOT being independently updated in the same ARM template as the deployment. For Example: The following template can fail the deployment, because on updating the app settings in the ARM template, the existing app settings will be deleted, and then new app settings will be created using the ARM template. During this process, the new app settings are not yet available. If the ZipDeploy starts in parallel being in the same template, then the app setting might not be available this time and the deployment can fail.
"resources": [
{
"apiVersion": "2018-11-01",
"name": "[concat(parameters('functionAppName'), '/appsettings')]",
"type": "Microsoft.Web/sites/config",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('functionAppName'))]",
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
],
"properties": {
"AzureWebJobsStorage": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';EndpointSuffix=', environment().suffixes.storage, ';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]",
"APPINSIGHTS_INSTRUMENTATIONKEY": "[reference(resourceId('microsoft.insights/components', variables('applicationInsightsName')), '2020-02-02-preview').InstrumentationKey]",
"FUNCTIONS_EXTENSION_VERSION": "~3",
"WEBSITE_RUN_FROM_PACKAGE": "1"
}
},
{
"name": "[concat(parameters('functionAppName'), '/ZipDeploy')]",
"type": "Microsoft.Web/sites/extensions",
"apiVersion": "2021-02-01",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('functionAppName'))]"
],
"properties": {
"packageUri": "[parameters('packageUri')]"
}
}
]
Solution: Try to deploy with one of the two ways mentioned below.
i) It is strictly recommended to include AppSettings as part of Site resource, instead of providing it separately in resources like SiteConfig resource, Sites/Config and Sites/AppSettings resources. When creating the site, add app settings to site config under properties like this "properties": { "siteConfig": { "appSettings": [ ] } } }
and make the ZipDeploy resource depend on the site. Here is the sample template.
ii) You can split it into two separate ARM templates. First, run the template to update the app settings, and then second template for deployment.
- Invalid or Expired SAS URL
One of the common reasons for the following error is that the specified SAS URL was invalid or has expired. So, failed to download zip from URL.
Error Detail: The resource operation completed with terminal provisioning state 'Failed'. (Code: ResourceDeploymentFailure) Raw Error:
{
"code": "DeploymentFailed",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",
"details": [
{
"code": "Conflict",
"message": "{\r\n \"status\": \"Failed\",\r\n \"error\": {\r\n \"code\": \"ResourceDeploymentFailure\",\r\n \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\"\r\n }\r\n}"
}
]
}
Solution: Please check the specified SAS URL is valid. You can navigate to Kudu debug console and curl on the URL to verify if Zip download works. If the URL is invalid or has expired, then regenerate the URL.
- Linux Consumption plan
ZipDeploy extension and the appSetting WEBSITE_RUN_FROM_PACKAGE=1
are not supported for Linux Consumption plan.
Solution: If you are using Linux Consumption plan, then:
- Do not use ZipDeploy extension.
- Set appSetting
WEBSITE_RUN_FROM_PACKAGE=URL
for deployment using the .zip package url. For example:
NOTE: Please include rest of the existing app settings in the template to preserve them.
{
"name": "[parameters('siteName')]",
"type": "Microsoft.Web/sites",
"apiVersion": "2021-02-01",
"location": "[parameters('location')]",
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "WEBSITE_RUN_FROM_PACKAGE",
"value": "[parameters('packageUri')]"
}
]
}
}
}
Dependencies are required for resources that are deployed within the same template, especially when the order of creation matters. For Example: If function app site and ZipDeploy extension are being deployed in the same template, then it is important to declare that the ZipDeploy resource depends on the site. Because only after the creation of the site, we want to create ZipDeploy extension for deployment. Here is more information on dependsOn.
- No. The appSetting
WEBSITE_RUN_FROM_PACKAGE=1
is only available with ZipDeploy, not MSDeploy. - The ZipDeploy extension with the appSetting
WEBSITE_RUN_FROM_PACKAGE=1
is the recommended path of deployment, except for Linux Consumption plan. - For Linux Comsumption plan, please remove MSDeploy extension and remove ZipDeploy extension. Then add the app setting
WEBSITE_RUN_FROM_PACKAGE = packageURL
for deployment in ARM Template.
- MSDeploy is not supported with Linux, it is Windows only. MSDeploy is not a recommended deployment mechanism for Azure Functions.
- For Premium and Dedicated plan on Linux, use ZipDeploy extension and set the appSetting
WEBSITE_RUN_FROM_PACKAGE=1
. - For Linux Comsumption plan, please remove MSDeploy extension and remove ZipDeploy extension. Then add the app setting
WEBSITE_RUN_FROM_PACKAGE = packageURL
for deployment in ARM Template.
OR Why WEBSITE_RUN_FROM_PACKAGE=1
is not working for function app with Consumption plan on Linux?
- ZipDeploy extension and the appSetting
WEBSITE_RUN_FROM_PACKAGE=1
is not supported with Linux Consumption plan. It is the recommended deployment path for all other OS and SKU. - For Linux Comsumption plan, please add the app setting
WEBSITE_RUN_FROM_PACKAGE = packageURL
for deployment in ARM Template.
To enable the remote build processes on Linux, please verify the following app settings (you can simply verify configurations on the Azure portal):
-
WEBSITE_RUN_FROM_PACKAGE=0
or WEBSITE_RUN_FROM_PACKAGE app setting removed SCM_DO_BUILD_DURING_DEPLOYMENT=true
For Functions app on Linux, ENABLE_ORYX_BUILD=true
is set by default. If this build does not work for you e.g. for dotnet or java app, then set ENABLE_ORYX_BUILD=false
.
WEBSITE_RUN_FROM_PACKAGE setting should be made consistent between ARM template and Deployment task to avoid unexpected issues around file updates when deploying. For example, if using "Run From Package" in the DevOps deployment task, make sure the ARM template also uses WEBSITE_RUN_FROM_PACKAGE = 1, and if not using "Run From Package" in the DevOps deployment task, make sure the ARM template uses WEBSITE_RUN_FROM_PACKAGE = 0.
When setup DevOps pipeline with RunFromPackage option, for every run, DevOps will automatically add WEBSITE_RUN_FROM_PACKAGE=1 to the current AppSettings collection. As part of the pipeline, user often provides script/template to create/update the site and its AppSettings. If user misses to include this as well, it creates a situation as if the setting is removed and re-added back for every run. This leads to file system being changed during deployment and a common source of transient issue if not missing deployed content altogether. Therefore, make sure the template or script include WEBSITE_RUN_FROM_PACKAGE=1 if DevOps's RunFromPackage is selected and vice versa.
Changing or removing these settings may cause your function app to not start. Please make sure you have these required settings.
App setting required for all OS and SKU:
- AzureWebJobsStorage
App setting required for Premium plan or Consumption plan on Windows and Premium plan on Linux:
- WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
- WEBSITE_CONTENTSHARE
NOTE: In ARM template, for Windows, do not need to set the WEBSITE_CONTENTSHARE setting in a deployment slot, because it is generated for you when the app is created in the deployment slot.
NOTE: In ARM template, for Windows, do not need to set the WEBSITE_CONTENTSHARE setting for Elastic Premium plan, because it is generated for you when the site is first created.
OR Why the Function app is unavailable (throwing 500 error) during slot swap for a few seconds?
- Set WEBSITE_SKIP_ALL_BINDINGS_IN_APPHOST_CONFIG to 1 to skip all bindings in applicationHost.config. If your app triggers a restart because applicationHost.config is updated with the swapped hostnames of the slots, set this variable to true to avoid a restart of this kind. It is set to avoid restart during deployment slot swap if there was a restart due to the addition of the bindings.
- If you are running a Windows Communication Foundation (WCF) app, do not set this variable.
For swapping the 2 slots, it is recommended to have 2 separate templates:
- First run this template successfully for deploying to slot using ZipDeploy. Test deployment slot thoroughly if any testing steps involved.
- Then run this template for swapping slots.
- If you are restricting access to the storage account through the private endpoints, you will not be able to access the data storage in the storage account through the portal or otherwise.
- You can give access to your secured IP address or virtual network for the data storage in the storage account, by Managing the default network access rule
After restricting storage account to a virtual network, why do I get 503 error when trying to reach the function app?
Verify and update the Application Settings under Configuration for the function app to the following:
Setting name | Value | Comment |
---|---|---|
AzureWebJobsStorage | Storage connection string | This is the connection string for a secured storage account. |
Verify and update these App setting for Premium plan or Consumption plan on Windows and Premium plan on Linux:
Setting name | Value | Comment |
---|---|---|
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING | Storage connection string | This is the connection string for a secured storage account. |
WEBSITE_CONTENTSHARE | File share | The name of the file share created in the secured storage account where the project deployment files reside. |
Consider the following settings when using Virtual Network:
WEBSITE_CONTENTOVERVNET = 1
- A value of 1 enables your function app to scale when you have your storage account restricted to a virtual network. You should enable this setting when restricting your storage account to a virtual network. To learn more, see Restrict your storage account to a virtual network.
- Supported on Premium and Dedicated (App Service) plans (Standard and higher). Not supported when running on a Consumption plan.
WEBSITE_VNET_ROUTE_ALL = 1
- A setting value of 1 indicates that all traffic is routed through the virtual network. Indicates whether all outbound traffic from the app is routed through the virtual network.
- You need this setting when using features of Regional virtual network integration.
- It's also used when a virtual network NAT gateway is used to define a static outbound IP address.
This is an expected behavior that the ARM template will delete the existing app settings and replace the app settings for a function app based on the app settings present in the ARM template. The API requires the payload to contains all necessary settings which will replace the existing one entirely. There is no partial remove or patch support with existing AppSettings. For instance, if one you want to add a new setting, one needs to get existing set, add to that collection and update as a whole.
Therefore, please include all of the existing app settings in the template to preserve them. This does not apply only if the app settings block is not defined in the current template.
- This setting is for Windows only. This setting is only needed when using the node language stack to specify which node.js version to use. For Example:
NOTE: Please include rest of the existing app settings in the template to preserve them.
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "WEBSITE_NODE_DEFAULT_VERSION",
"value": "~14"
}
]
}
}
-
WEBSITE_NODE_DEFAULT_VERSION
is Windows only property. Click here for more information. - Linux apps should use
LinuxFxVersion
setting.
- Linux apps should include a
linuxFxVersion
property undersiteConfig
. If you are just deploying code, the value for this is determined by your desired runtime stack in the format ofruntime|runtimeVersion
. - If you are deploying a custom container image, you must specify it with
linuxFxVersion
and include configuration that allows your image to be pulled, as in Web App for Containers. Also, setWEBSITES_ENABLE_APP_SERVICE_STORAGE
tofalse
, since your app content is provided in the container itself: - More information about setting
linuxFxVersion
using ARM template and using Azure CLI is available in the documentation.
OR Why we need to enable Always On when running on dedicated App Service Plan?
-
If you run on an App Service plan, you should enable the
"alwaysOn": true
setting under site config so that your function app runs correctly. On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. The Always on setting is available only on an App Service plan. -
When running in a Consumption Plan or Premium Plan you should NOT enable Always On. On a Consumption plan the platform activates function apps automatically and on a Premium plan the platform keeps your desired number of pre-warmed instances always on automatically.
All client tools are syntactically validating the ARM Template. If the validation fails, then a similar error message will be displayed in json format. For example:
{"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Web/sites/func-xyz' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'.","additionalInfo":[{"type":"TemplateViolation","info":{"lineNumber":0,"linePosition":0,"path":""}}]}}
Azure Resource Group Deployment task can be used for deployment as well as validation. You can add the task with deploymentMode: 'Validation'
using the following json format to run the same validation independently before deployment and get more information from the error message. For example:
- task: AzureResourceManagerTemplateDeployment@3
inputs:
deploymentScope: 'Resource Group'
subscriptionId: # Required subscription ID
action: 'Create Or Update Resource Group'
resourceGroupName: # Required resource group name
location: # Required when action == Create Or Update Resource Group
templateLocation: 'Linked artifact'
csmFile: # Required when TemplateLocation == Linked Artifact
csmParametersFile: # Optional
deploymentMode: 'Validation'
Install the latest version of Azure CLI.
You can use the az deployment group validate command to validate your ARM Template pre-deployment. For example:
az deployment group validate --resource-group <resource-group-name> --template-file <template-file-location> --parameters functionAppName='<function-app-name>' packageUri='<zip-package-location>'
For further troubleshooting, you can setup a test resource group to look out for preflight error and deployment error
On Visual Studio Code, install the latest Azure Resource Manager Tools extension.
This extension catches syntactically errors in your ARM Template pre-deployment. Here are couple of visual examples of errors.
You can add wait time or delay between resources using deployment deploymentScripts
in your ARM template like below. Here the dependsOn
should include the resource after which you want to add a wait time.
{
"type": "Microsoft.Resources/deploymentScripts",
"apiVersion": "2020-10-01",
"kind": "AzurePowerShell",
"name": "WaitSection",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('functionAppName'))]"
],
"properties": {
"azPowerShellVersion": "7.0",
"scriptContent": "start-sleep -Seconds 60",
"cleanupPreference": "Always",
"retentionInterval": "PT1H"
}
}
Whichever resource we want to create after wait time should have a dependsOn
block like below.
"dependsOn": [
"WaitSection"
]