Recommended way to manage separate host configs

[APIWT]

What is the recommended way to have a separate host.json file per CI environment/deployment?

[mhoeger]

@APIWT - can I ask about your scenario? We have separate App Settings (through the portal or through local.settings.json), but I'm wondering what differences you have in host.json. Thanks!

[APIWT]

@mhoeger sure! One good example is that we have a different log level in our environments. So on dev we log everything in app insights but in QA and production we only log errors.

My opinion is that every configuration option in host.json could be set differently in different environments.

[fabiocav]

Assuming this is in Functions 2.0, every host.json setting can also be defined as an environment variable/app setting. In order to do that, you need to define the variable in the right scope, under the AzureFunctionsJobHost section.

For example, if you're changing a configuration named foo in host.json, you can define an app setting named AzureFunctionsJobHost__foo instead, and that will be applied.

[APIWT]

@fabiocav

How do you represent arrays? For example: https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json#functions

And how about bools? For example isEnabled for https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json#applicationinsights

Last but not least, are there any unsupported host.json options as environment variables?

[APIWT]

@fabiocav

Also, how do we handle when we need dots in a key? For example here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json#logging

The key Function.Something

[fabiocav]

This is all based on the ASP.NET Core environment variable provider. Arrays are expressed as a 0 based configuration set of elements:

For example:

List:0 = "foo"
List:1= "bar"

You should be able to express booleans as simple "true"/"false"

There are no options we block using environment variables.

For periods, you can just set the variables with them.

[APIWT]

@fabiocav
That makes sense. Do those colons become double underscores or just literal colons in the environment variable names?

[fabiocav]

They can be either. Both are supported, but on Linux/Mac OS, colons are not supported in the environment variable name