8
votes

I am seeking a convenient method for deploying application settings for an Azure function that is deployed using Octopus deploy (or any automated deployment tool).

From Microsoft's guidance it seems that an azure function should not use a configuration file that would traditionally be transformed at deployment time to set environment-specific application configuration.. It is recommended to use a local.settings.json when using the azure tools to test the function on a local machine, but no file is used when deployed to an azure function app.

The alternative provided by Microsoft for azure functions is a set of environment variables that are configured through the portal interface. This setup works fine when you are manually setting everything up through the portal interface, but when deploying from an automated release management tool like Octopus deploy this becomes a real pain.

There are several methods that I have come across so far:

  1. Deploy the settings using an ARM template that can be transformed at deployment time.
  2. Post settings to Kudu REST API after deployment
  3. Use various powershell commands to replace app settings

Each of these methods will replace all application settings as there is no way to add/remove, without writing some custom code to get all settings, compare and update. This is very troublesome as there are some application settings that are not specific to my application and are required by the function host.

I could possibly add my own configuration file to by transformed and deployed with the function, which would certainly be easier than any other method I have come across, but feels like going against the grain of how functions were intended to be produced.

Does anyone have a clean and easy method of deploying application settings to an azure function app?

1
ARM templates don't replace the entire app settings. By default they're idempotent so they can be used to add or update existing values. They won't remove values (you can opt into that behavior though)Jesse Carter
@JesseCarter but if there are app settings in the portal (e.g. ones added by azure not relevant to my application - AzureWebJobsStorage, etc.) that is not in my ARM template then it will be removed.Glen Thomas
In my solution I deployed the entire function application and it's dependencies with ARM. So things like AzureWebJobsStorage were managed in my templates and automatically populatedJesse Carter
@JesseCarter that might be the way I end up going. Currently I am provisioning the function app and associated resources and deploying the functions (and their configuration) in separate processes. Joining the two together is a little awkward as the application settings are managed by developers and the provisioning is handled by a devops-like role.Glen Thomas
ARM Template is also my preference as I can inject connectionstring (azure storage, servicebus, app insights ...) into the app settings without having to store it in my release server.Thomas

1 Answers

2
votes

ARM templates in my opinion is one of the hardest type of code to maintain due to their sheer size, verbosity, and difficulty to parameterize values. I've had great success with Azure CLI. Its uses simple commands that both devs and devops folks can understand. Here's how to do it with Azure CLI. Note: you'll need to install Azure CLI on your build box first.

The following code can be executed under Windows Batch script, bash script, or even Powershell script.

$myAppSettings1 = "myKey=myValue"
az functionapp config appsettings set --resource-group $rgName --name $functionAppName1  --settings $myAppSettings1