Azure functions: who's doing it wrong?
-
So I'm trying to automate some Azure Functionapp deployments here. The deploy command itself was fairly simple, but I also want to automate things like setting the parameters (environment variables) to the appropriate connection strings—to the database, event hub and such.
A recommended way to deploy a function is using a deployment slot. That page is even titled “Set up staging environments”, so I assume (but this is the point where either me or them is an ass) that the intent is to deploy the function to the slot, verify it works there, and then swap it to the production, the support for swapping being the main difference between a slot and just another functionapp.
So to do that I would think that I configure the staging slot with connections to the test/staging database, eventhub, keyvault etc., test the code there and then swap it to production where it will use the production settings.
Except further down the page it says:
Settings that are swapped:
- General settings, such as framework version, 32/64-bit, web sockets
- App settings (can be configured to stick to a slot)
- Connection strings (can be configured to stick to a slot)
- Handler mappings
- Public certificates
- WebJobs content
- Hybrid connections *
- Service endpoints *
- Azure Content Delivery Network *
- Path mappings
Features marked with an asterisk (*) are planned to be unswapped.
Settings that aren't swapped:
- Publishing endpoints
- Custom domain names
- Non-public certificates and TLS/SSL settings
- Scale settings
- WebJobs schedulers
- IP restrictions
- Always On
- Diagnostic settings
- Cross-origin resource sharing (CORS)
- Virtual network integration
- Managed identities
- Settings that end with the suffix _EXTENSION_VERSION
That looks a bit mixed up for that use-case. Well,
- The application settings and connections strings (with caveat that I didn't see a separate connection strings setting in the portal) will usually be a mix, so the user has to configure which ones are to be swapped anyway.
- The three entries with asterisk and note they are planned to be unswapped, yeah, they almost certainly shouldn't be swapped. But I don't think they are used in any of the services I am going to touch, so I don't need to care.
- The _EXTENSION_VERSION is the strangest. The FUNCTION_EXTENSION_VERSION has to match the version of the support library (Microsoft.NET.Sdk.Functions in case of .нет) the code is linked with, otherwise it won't even start, so that really sounds like it should be the other way around, those should be swapped just like the runtime version, which the first point says is swapped.
So am I ass-u-me-ing wrong how it should be used, or are some of the defaults bogus?
-
@Bulb A contrafactual analysis assuming MS to be acting in good faith and not being gratuitously stupid seems to indicate:
- the swapped settings are at your environment/fleet scope
- the non-swapped settings are at your function/service scope
-
@Gribnit Yeah, except most of the settings are simply environment variables, just some have special meanings to the servers, so they are clearly all at the same scope.
-
@Bulb both control planes are projected onto a common control plane, sure.
