I have Azure functions with configs (database connection strings, active directory, etc) set up for dev and live environments, right now I have everything in a class and I comment in/out the bits I'm using or not using.
Is there a way to upload a json file with the azure functions that will guide its config?
You mention "upload a json file" so I'm assuming that you're referring to some sort of release management activity. My suggestion is to simply use the built in AppSettings. Your use case is essentially what they are built for. Generally speaking if you store your settings within the appsettings of a function app and you have separate environments for your functions (dev & live) then you don't need to manage a separate json configuration file. The environment owns the configuration and your code will get the settings from the current environment.
If you have a more complex deployment and configuration management scenario I would consider using a release management tool such as VSTS to manage those configuration settings as part of the release pipeline so each environment has the correct settings at deployment time. Most CI\CD tools have functionality to update json configuration and\or update Azure App configuration directly.
Yes. You need to add connection strings as Application Settings. Azure Functions Core Tools uses local.settings.json file to read your connection strings when running locally and these settings are not pushed to Azure when published.
Related
We have 4 Azure environments for the stages of our development process; Dev, QA, UAT, Production. As you would expect, settings and options need to differ between environments, e.g., "apiurl": "http://dev-api.ourdomain.com" in dev needs to become "apiurl": "https://uat-api.ourdomain.com" for UAT.
At the moment we manually set these in the App Service Configuration page in the Azure Portal. There are problems with this method we are trying to overcome:
It cannot be timed to happen with releases, it has to be manually done
It's prone to human error
Previous values are lost
We cannot easily compare values between environments
We cannot easily see which settings are no longer used
We would like to setup an appsettings.json with environment transforms for the differences. This addresses the last 3 issues as it will be stored in our code source control (if not secret), but this is useless if we cannot deploy that same file to set the Azure configuration. Pipeline steps might solve issues 1 and 2, but reintroduces issues 3 and 5.
Surely there is a simple way to do this that I am missing?
I'd recommend creating the appsettings.json file in your source code, and use a pipeline to deploy the app service with it included; those settings will take effect. The pipeline can either adjust the file contents immediately before deployment, or upload the file as-is but also deploy app settings to override the file's contents.
This fits your requirements because:
using a pipeline for automation gives you timing control (req 1) and reduces the risk of human error (req 2)
keeping some of the settings in source control gives you a (partial) history of previous values (req 3)
some of the settings may be the same across all environments; those can be left untouched in the appsettings.json, but those which differ can be overridden by the pipeline and adjusted correctly
you could override settings by using a script task such as Powershell or a FileTransform task to actually change the appsettings.json
or, you could override settings by automated configuration of the azure app service configuration, using the Azure CLI or an ARM Template for example.
For comparison of settings across the different environments (req 5), I'd recommend:
organising your pipeline variables into different groups by environment, so the pipeline code makes it clear what the differences will be when deployed
using azure cli or powershell commands to interrogate the actual deployed app services.
I can't seem to find any documentation on how to handle Azure Release Pipeline Variables locally. I have the placeholder names in my web config but I'm not sure how to inject them when debugging in Visual Studio.
First off, don't use a release pipeline for configuration management. Configuration should be driven from source control, so there is one single source of truth about the state of your software and its configuration. For secrets, they should be retrieved and managed in an external secret store (such as an Azure key vault).
Use deployment-time configuration transforms. Your standard, day-to-day web.config should contain whatever values you need to debug. Then, at deployment time, use web deploy transforms to turn the configuration file into one suitable for running your application in the environment you're targeting.
I have used this documentation to setup continuous deployment on Azure functions with git-hub. Now I have successfully setup git-hub repository in Azure function for continuous deployment.
I am able to see APP settings in local.settings.json file. But I want to know how to configure Connection strings (SQL Connection strings) in continuous deployment.
You want to keep your sensitive data out of your source code repository. That being said, app.settings.json of any kind is not an option.
You have several options there. Two mostly used are either Azure Vault or Azure AppSettings where you can set key/value pairs which are then available to your app either through settings (merged with other settings) or through environment variables.
I use second approach with env variables access to AppSettings.
This link might help:
https://www.hanselman.com/blog/BestPracticesForPrivateConfigDataAndConnectionStringsInConfigurationInASPNETAndAzure.aspx
The documentation that you've referred to is sort of a "quick and easy" continuous deployment option for Functions that gets you up and running quickly. It's not ideal for a production environment though, as you've discovered there is no way to parameterize your app settings. In order to build a proper build/release pipeline you'll need to move away from the direct Git integration and use something like VSTS which you can configure properly against multiple environments including the ability to set AppSettings and ConnectionStrings properly. Based on the approach you've taken currently, your only option is to go into the Azure Portal and manually configure AppSetting and ConnectionStrings in your function app directly.
This blog post covers a lot on the topic and shows one approach for accomplishing what you're after:
https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/10/04/azure-function-ci-cd-devops-pipeline/?utm_source=vs_developer_news&utm_medium=referral
Configuring a complete CI/CD pipeline is a bit involved (as you'll be able to see from the link) so there's no easy answer that can fit right into a StackOverflow post. I highly recommend that you read through that and do some more research on Google around the VSTS and Functions integrations.
I'm quite used to publishing websites to IIS and Azure using the publish profiles feature of Visual Studio 2012. A big feature for me is the ability to specify a configuration transform file per environment, such that I can apply both the "Release" config transform and the "Production" config transform to produce a single result which is a release build tailored for he the production environment.
Now I'm trying to build an Azure worker role, which supports the idea of multiple discrete configurations for the role and will apply the "Release" or "Debug" build configuration transforms depending on the packaging settings.
Is it possible to also apply a target environment config transform to the web.config in a similar fashion to how publishing works?
To clarify, I want to apply multiple config transforms to the web.config of the web application hosted in the Web Role based on the build configuration and target environment.
Have a look at my answer here: Azure Web Role configuration settings across environments
The best solution I've found is to keep your web.config transforms for (Debug/Release).
Then separately, to keep individual Cloud Deployment Projects for each target environment you are going to deploy to (e.g. LocalEmulator, QA, Production).
It is possible to have CloudDeployment level config transforms, (i.e. on the ServiceConfiguration.cscfg) but you can only have a single Service Definition per Cloud Deployment. (see note below). So if you end up in a situation where you need different scaling, instance or endpoint options for different environments, this option falls down. The best solution I've found is one cloud deployment project per environment.
note It might/would be possible to build a config transform system for the csdef file as well using something CTT.exe or SlowCheetah but honestly this was more work than was required for my needs.
I am trying to setup essentially a Development, Staging and Production cloud service. So far I have setup 2 cloud services:
MyApp - which is what I am hoping to have be the staging and production since they have the same connection string and should be identical and the ability to quickly swap VIP is a nice feature.
MyAppDev - I want this to point to our development database.
I also want to do the continuous build integration from tfspreview to azure. This is working great except for making the connection string unique.
So far I have setup the cloud services and have it doing continuous builds. I have also set my connection string in web.config and web.production.config. In addition I have setup publishing profiles (.azurePubxml) files and set them to be the Alternative Publish Profile in the build definition process section. These publish profiles specify which config to use (or at least that is what I thought). It seems to pick up the settings for the publish profile because I have RDP enabled and such with different passwords.
So how can I make the build controller use the "Production" & "Debug" build configurations to pickup the web.config transformations?
Hope that makes sense.
EDIT:
I only have Solution to build as seen below:
When defining your build definition, in the "Process" section under item 1. "Items to Build" you are given the opportunity of defining which configuration to Build. In here, type the name of the configuration that matches your .config definition to build that version.
EDIT: This is a little late, but this is how I got the alternate configuration to build along with the correct connection strings. I set the MSBuild Argument for configuration manually and my build correctly changed the connection strings on deployment to Azure.
Just set your downloaded Azure publishing profile in section 6. "Web Deploy Publishing Profile". It's not necessary to use different web.config files Connection String will be rewritten on publish build runtime.