I need to understand Slot Application Settings better for Azure App Services. When they apply and how to use them correctly.
I have 2 App Services set up each running 2 slots as below.
Site 1 with slot - building-staging
Site 1 with slot - staging
Site 2 with slot - building-production
Site 2 with slot - production
So for each site, I'd like to be able to put an invalid connectionstring for the build slot in the Application Settings blade so that the site can't be accessed and will just give you basically an error page on the azuerwebsites.net url for that slot.
In my production slot of each I then want to put the correct connectionstring so that once swapped they will work.
I can not get this to work reliably, the settings don't apply when I swap. Should I be marking the connection strings on the production slot as slot settings? Should the original one on the build slot be a slot settings? Do I need some kind of nuget package installed I'm not aware of.
Please help
If I understood your question correctly, you need to mark them all as slot settings.
App settings and connection strings marked as slot settings will stay on the slot when a swap is done. Any settings/connection strings not marked as slot settings will be swapped with the app.
The answer to my question was found in this document. (Which if anybody from the Azure team comes accross, should really be linked to from the Configuration for deployment slots section here )
Windows Azure Web Sites: How Application Strings and Connection Strings Work
In a nutshell, you shouldn't use ConfigurationManager to get settings from the Application Settings blade UNLESS you are using .NET 4.5 framework.
If you don't use .NET 4.5 framework you should be using Environment.GetEnvironmentVariable instead.
This tripped me up as I was converting an existing environment of mine over to App Services. I would have loved a big warning somewhere to tell me to make sure of this.
EDIT: So this was not the whole story;
The other part is what is meant by "sticky" and "not sticky" settings in the documentation. I kept finding references to the fact that the settings aren't actually put into your web.config file but rather lives in an in memory property bag accessible to your app. I couldn't find any reference of how I could see what was in this mysterious bag, but the answer it obvious once you know it.
During a swap, any settings on your staging slot is actually copied over to the settings of your production slot, i.e. it actually changes it in the production slots "Application Settings" blade. And whatever is in your slot's Application Settings blade is what is in the in memory property bag.
Related
When I read the doc for both slot and site,
Website: https://learn.microsoft.com/en-us/azure/templates/microsoft.web/2018-02-01/sites
Deployment slot: https://learn.microsoft.com/en-us/azure/templates/microsoft.web/2018-11-01/sites/slots
I can see that I can apply application settings by adding to properties.siteconfig.appsettings to either the website or a slot. This I how I do it today for the website, but I am wondering if, even though the deployment slot has the same structure, if I can add settings to my slot by doing the same? I don't care about sticky settings. The reason why I am asking is that when I export from the portal I can't see how they do it and everywhere I look on the Internet people is using the Microsoft.Web/sites/config type or Microsoft.Web/sites/slots/config type. Can't i just use properties.siteconfig.appsettings as in the doc for the deploy slot, or am I missing something fundamental?
I am not in a position where I can go to a computer and test it, but my mind is going nuts to find out.
You could indeed configure the appsettings through the siteconfig tag. As for your puzzle, it's because you don't understand why there are two ways to set the appsettings.
Actually the siteconfig is used to Prevent copying settings from the Prod site, you could check the github pull.
Hope this could help you.
I can note that some of the deployment slots settings of Azure app services can be swapped, but others cannot be swapped.
Do you know why?
First we should understand that slots are primarily meant to be used to deploy new versions of a website real quick. Running (for instance) a staging environment on a slot is not recommended.
These are the settings that, according to the documentation, don't get swapped:
Publishing endpoints
Custom Domain Names
SSL certificates and bindings
Scale settings
WebJobs schedulers
If any of these would be swapped, that would mean that your application would break. In more ways than one.
For instance, you would have to change the publishing endpoints for your deployments, since they would have swapped with the slots. This means updating your CI/CD environment every time you swap slots.
The custom domain name that is connected to your production slot would now point to the secondary slot, rendering the swap useless. Because your domain still points to the old version!
If someone managed to reach the new version (which would be hard because the custom domain name still points to the other slot), the SSL certificate (and binding) wouldn't be there. Image that happening to a website that provides a HSTS header.
You can name at least one good reason for each of these settings to not be swapped when swapping slots.
We have a number of feature requests in UserVoice for settings to remain sticky to slots and have plans to work on a few of them. Feel free to add your support to the one you're interested in:
https://feedback.azure.com/forums/169385-web-apps
My web.config contains multiple entries in "appSettings" (e.g.: twilio account key). One of these is for the asp.net chart control. It's the configuration part that states where the images the control generates are to be stored.
All of these settings work on my development machine. That is, i can connect to twilio and the chart control stores image in memory (as it should, according to the settings).
When i publish the site to my azure website (using vs), all of the settings work, apart from the chart control one. The chart control behaves as if the setting isn't even there. (it defaults to c:\TempImageFiles for storage).
I looked into the published version of the web.config and the setting is there. Only, it's beeing ignored.
My next attempt was to add that setting using the portal. (It's possible to add appSettings for a web app using the portal). I copied the exact same setting from web.config into the portal settings. This worked, so there is nothing wrong with what's in the settings.
So my question is: Why are some (at least this one) settings from web.config ignored when the app runs inside an azure web app?
You might have an app setting defined in the Web App's configuration with an identical name that overrides the web.config setting. This is typically done to have production settings stored in Azure instead of Web.config.
You can confirm if this is the case by opening your Web App's blade in the new portal, and checking the Application Settings tab there.
azure websites / azure web app service are typical web applications running on top of azure PaaS infrastructure. So whatever storage allocated to the service is accessible from the app. But it cannot be the typical C: or D: where in a regular server the app may have complete access. Mostly the C: space is allocated for IIS hosting. D:\local is something you can utilize as the app will have complete read and write access.
Please refer azure web app service sandbox details here.
If you are accessing the path via code try using Server.MapPath property to get access to the path. options like Path.GetTempPath() will not work.
One point to note is, any local storage in azure PaaS services is to be treated like a temporary storage. Whenever the site, service or role recycles the storage will be gone a fresh storage will be assigned.
Hello,
I noticed that when i want to swap slots on Azure the whole configuration will also be copied. I have a lot of environment-specific settings that i wanted to have configured automatically on a swap. So for example, i want that the ENVIRONMENT_TYPE of the test slot stays on TEST and doesn't change to DEV. Like you can see in the Screenshot, these preview messages don't really make sense.
Can anybody help me changing this option? How do you handle this?
Thanks a lot, have a nice day!
In the Azure Preview Portal, you can mark individual AppSettings as "Slot Setting" which means that they won't get swapped. This is described at https://azure.microsoft.com/en-gb/documentation/articles/web-sites-staged-publishing/.
You can access the Preview Portal at https://ms.portal.azure.com/. Choose Browse everything and select your Web-App. On the blade for your web-app, there is a box called Deployment Slots. If you select this, it will list the available Deployment slots - choose the one that you wish to modify, and you can then mark the individual App Settings as "Slot Setting".
(1) we have a web application running on Azure Web Site using Sql Server (Web Edition). The application includes two connection strings:
DefaultConnection - normal connection string, in the form of
Server=tcp:{my-sql-server}.database.windows.net,1433;Database=...).
EFConnection - Entity framework connection string. Since im using the
EF designer (and loving it) i need to use a connection string in the
form of metadata=res://*/Models.EDM...
(2) I've placed the connection strings in the web.config; this is the only way the "metadata..." (EF) connection string was accepted (when tried to enter these connection strings in the Azure web site's control panel, i got all kind of strange errors).
Everything works great.
(3) Next, I have added a staging slot to our web site to perform staged development, as described in Staged Deployment on Microsoft Azure Web Sites
The staged site works fine. I've created for it a different Sql Server, and set its connection string in the same manner as in the production site (ie. in the web.config). I handle the different web.config using web.config Transformations. (i have another 2 transformations - for development/debug and for local deployments/release)
The problem: now that i have a production + staging site, i try to do swap. The swap works great, and any changes introduced to the staging site are swapped to the production.
However, the swap also takes the connection strings from the staging site, connecting the production to the staging database.
*Is this a known bug? is there a work-around? (for now i am required to do direct deployment to the production site once QA tested the staged site - this means downtime for our site, and quiet defeats the purpose of this whole exercise)
App settings and connection strings are not sticky to the slot and will remain with the website when swapped but we can configure selected app settings and connection strings to become sticky to the slot using a PowerShell command (not yet supported by the Azure portal).
Use this command in Azure PowerShell to set 2 app settings as sticky to the slot:
/* If you have one config */
Set-AzureWebsite -Name mysite -SlotStickyAppSettingNames #("myslot")
/* If you have more than one */
Set-AzureWebsite -Name mysite -SlotStickyAppSettingNames #("myslot", "myslot2")
And this command to set 2 connection strings as sticky to the slot (follows the same described principles above):
Set-AzureWebsite -Name mysite -SlotStickyConnectionStringNames #("myconn", "myconn2")
Sticky to the slot configuration is website-wide configuration and affects all slots in that website.
EDIT:
As noted by Jeff Treuting in one the comments below, now the new portal has a "Slot setting" checkbox that you can select going to:
"Web Apps" -> choose your web app -> "Settings" -> "Application Settings".
The Staging environment is a production swapping mode that allows you to perform an upgrade of your website compeltely before you swap it with the current production system. It also provides a rollback mechanism in case there is an issue with your upgrade.
Perhaps the word Staging is a little misleading for companies that use this term to represent a QA environment as close to production as possible. In Microsoft Azure, the Staging environment is a pre-production concept that allows you to pre-configure and test an upgrade of your website.
QA environments should have their own environments.
The deployment slots feature for Azure Websites allows validating a version of your site with full content and configuration updates on the target platform before directing customer traffic to this version. The expectation is that a deployment slot would be fully configured in the desired target format before performing a swap. The swap operation does not apply transformations to the source deployment slot, it seamlessly redirects web traffic.
One idea to simplify the workflow in terms of validation and pre-swap updates would be using app settings for EF connection strings.
so we should use azure "staging" as another step in the deployment - a method used for assuring immediate deployment, without site downtime?
in that case i can still use it as a qa environment, and reconfigure before swapping with prodcution.
FWIW, you can save the EF connection string in the Azure portal by (a) copying and pasting the entire string BETWEEN the quotation marks, (b) replacing the HTML entity-modified quote mark around the inner connection string with actual double quotes, and (c) selecting "Custom" for DB type in the Azure console.