Change an Azure App Setting using the portal without a restart

Question

I sometimes to this:

In the Azure portal, I go to "App Services", then I click on my web app, and then I go to "Application Settings".

Here I change one value from the "App Settings" list:

Eg. I change "128" to "129"

Finally I click on "Save".

This causes my web app to restart. I don't want that.

Question: Is there a way to manually change this value without a restart? If not, should I store this value in another way then? maybe using a new section in web.config which I can upload each time?

If I use a new section, eg:

<moreAppSettings configSource="moreSettings.config">
</moreAppSettings>

And this moreSettings.config is like this:

<?xml version="1.0" encoding="utf-8"?>
<moreSettings>
   <add key="ClientAppBuild" value="129" />
</moreSettings>

Can I upload and override that single .config file without a restart?

Answer 1

Editing App Settings through the Azure Portal works the same as editing the web.config file. Consequently this will cause the IIS App Pool that is hosting your Web App to be restarted. This works exactly the same way in Azure App Service as it does with IIS on any Windows Server.

If you don't want to restart the App Pool when updating a particular setting, then you'll need to store them elsewhere. If you are storing a simple Key/Value pair, then you could store it in a JSON or XML file deploy out with the app, or you could use a Key/Value storage service like Azure Storage Tables or Redis Cache. You could also store the Key/Value pair within your applications database as well. No matter where you store it, you'll likely want to implement some kind of caching so you don't have to read the value from storage everytime it's accessed.

Answer 2

If all you're after is a key-value store that you can modify during runtime, why not use something designed specifically to do that, like Table Storage or Redis Cache?

If you're simply trying to store your build number, just deploy a static VERSION file with your project (untracked by source control) and increment the build number inside, at build time. You'll want to keep this file outside of wwwroot (and under d:\home\site\somethingElse) so the next deployment won't clean it up.

If you hook up source control to Kudu for continuous integration, you can get the current/active commit id (which also represents your latest built commit if you don't roll back) and a few other interesting things by calling Kudu's /api/deployments:

http is like curl but different

$ http https://SiteUsername:SitePassword@sitename.scm.azurewebsites.net/api/deployments

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...

{
    "active": true,
    "author": "snobu",
    "deployer": "GitHub",
    "end_time": "2017-03-29T08:47:08.954981Z",
    "id": "5ada48724129c78b8a993b4a25f2144aec03cbd2",
    "message": "Changed bootstrap theme to Flatly",
    ...

More on that API here - https://github.com/projectkudu/kudu/wiki/REST-API#deployment

That's way more meaningful than an artificial build number. You can safely store the site-level credentials as Application Settings and construct the /api/deployments URL without hard coding secrets in.

Answer 3

Another solution that I can think of is to have 2 deployment slots, says:

• production
• pre-production

pre-production is the slot with similar configurations as production, to achieve zero downtime.

So step by step is:

1. Add new config to pre-production
2. Wait for pre-production to come back up
3. Route 100% traffic from production to pre-production

Repeat steps 1 and 2 for production, then reverse traffic back to production.