Open ajklotz opened 4 years ago
Just ran into this problem myself. The workaround did work when deploying from my local pc using the az cli. It did not work when I pushed the change and my ADO pipeline tried to run the deployment :( ADO complains about invalid json around the properties section on the Microsoft.Web/sites/config section e.g. the AzureWebJobsStorage value. I read somewhere that Powershell is more forgiving when it comes to json.
Will the workaround work in Bicep also?
Bicep is not required, regular ARM template deployment can do as much.
Thanks @kwill-MSFT for the ARM template workaround, I got your workaround as official answer from Microsoft support to our deployment issue with the app settings and a staging slot. I just wish Azure Product Group would be more active in listening to issues like this and implementing an official solution. Deploying to Azure Functions always ends up feeling like using a beta software, there's always a catch or something not working as per documented.
I created an ARM template to deploy and manage two Azure Functions across multiple environments (CI, DEV, QA, PROD, etc). My goal was to have a single ARM template that deploys to each using a parameters.json file. In my parameters.json file, I created a JSON structure where I could reference each environment and all of the application settings. My function app has the siteConfig.appSettings object included in properties so I could use template functions to apply dynamically generated application settings, like a appinsights instrumentation key, and other things. Within the function app resource, I defined another resource to apply static application settings from a parameters.json file.
Unfortunately, when the ARM template deployed it deleted any application settings that were not defined in the ARM template. This means that any application settings that were defined as part of the initial function app were deleted and replaced by the parameters.json. Also, all of the dynamically generated application settings generated from the template functions were removed and replaced by the application settings defined in the parameters.json. The two resources do not work together at all.
I went into great detail with my struggles on how to handle environment-specific ARM template deployment of a function app with dynamic and static application settings, on a stackoverflow post.
Describe the solution you'd like ARM template deployment of application settings should NOT delete existing application settings. The PowerShell Azure CLI cmdlet does not delete anything and merges nicely.
az functionapp config appsettings set
The ARM template should behave similarly.Describe alternatives you've considered The alternative is for me to put everything in a key vault and then download the key vault secrets to get application settings and then use the
az functionapp config appsettings set
command. But a lot of my application settings have characters that are not allowed as names for the secrets, so a bunch of annoying renaming has to occur.Another alternative is to create deployment templates for each environment (dev, qa, prod) that contain all of the application settings. This alternative goes against the idea of having deployment templates that can be reused (destructured). I feel that MSFT didn't design ARM templates to be used in this manner. ARM templates should be able to support multiple environments from a single deployment template using parameter templates.
I feel that this is more of a bug and not a feature request.