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.
Related
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
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.
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".
I have an Azure WebApp and have activated the "Active Directory Authentication" in the Azure Preview Potal. Let's call it https://mysite.azurewebsites.net (not a real URL) Whis works as expected. However, when we add a deployment slot, we can't get authentication to work properly. When accessing the staged WebApp, e.g. https://mysite-staging.azurewebsites.net (not a real URL), we get redirected to
https://login.microsoftonline.com/<our-directory-guid>/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmysite-staging.azurewebsites.net/....
But the login portal gives us an error message:
AADSTS50011: The reply address 'https://mysite-staging.azurewebsites.net/<our-appliction-guid>/login' does not match the reply addresses configured for the application: .
The problem is, the WebApp does not show up as an application in our directory, so we can't set up alternate reploy URLs for it.
Is there any way to specify alternate addresses for WebApps, so that Azure AD login will work for deployment slots?
When you create the deployment slot, you need to re-setup the authentication for it, as if it's a new application. (From an app-service perspective, it is.)
The steps are roughly:
In the portal, go to your deployment slot under your app-service.
go to authentication/authorization
Go through all the steps to setup your authentication/authorization the same as for your production app. (Authenticate via AzureAD, Choose the provider, etc.)
Under "Manage App" in the staging environment, go to settings, and add new reply URL's for your staging environment. You should have your regular reply URL, and then the staging version:
https://myapp.azurewebsites.net/signin-oidc
https://myapp-staging.azurewebsites.net/signin-oidc
You should then be able to get in.
One weird thing that happened to me, is this didn't work, then I went into the staging authentication, and turned it off. That made everything work, and it correctly authenticated and didn't let me in if I wasn't signed in.
(I realize I'm posting this answer years after the original question, but after spending the better part of a week figuring it out, and this question repeatedly came up on searched, I wanted to document what I ended up doing in case someone else has a problem.)
I sure this will not fix the deployment slot is still pointing to live app but this fix this error as it is very silly.
AADSTS50011: The reply address 'https://mysite-staging.azurewebsites.net//login' does not match the reply addresses configured for the application: .
When you configure your URL under the application settings in Azure AD, you forgot… a trailing slash! That’s it! Can you believe that?
In other words, change this:
http://yoururlforyourapp
to this:
http://yoururlforyourapp/
Done! You’re welcome.
From http://www.matvelloso.com/2015/01/30/troubleshooting-common-azure-active-directory-errors/
Unfortunately it looks like you ran into some bugs in that version of the preview portal.
The Reply URL issue is likely because you created the staging slot after you configured auth on the production slot. In that version, we cloned the auth settings so your staging slot ended up pointing to the existing AAD application without adding the new Reply URL. This issue has been fixed by not auto-cloning auth settings when a new slot is created.
In any case, you should be able to find your application in the AAD management portal. If you're not able to see it, it could be because you need to change the "Show" dropdown filter from "Applications my company uses" to "Applications my company owns". Locating it and adding the staging Reply URL would have also worked around the issue mentioned above.
The error message you saw when trying to re-configure auth on your staging slot was likely another bug in the management portal if you were only seeing it on that staging slot.
The Authentication / Authorization blade has been radically updated since your question was asked, and all of these issues should be fixed now. Sorry for the inconvenience. I hope you were able to make progress in spite of these issues.
I knew that we can use RoleEnvironment.IsAvailable to check if code is running in Web/Worker Role. How about Azure Websites?
I tried the above RoleEnvironment code but it always returns false. I need to run some configuration code in Application_Start so I cannot depend on the request stuff.
Any help is appreciated.
This is actually very easy simply check for existence of this environment variable: WEBSITE_SITE_NAME.
!String.IsNullOrEmpty(Environment.GetEnvironmentVariable("WEBSITE_SITE_NAME"))
The content for this will be the name of your site.
To see more environment variable that you have under your site go to the following link: https://{sitename}.scm.azurewebsites.net/Env
You cannot (easily).
With azure Web Sites, your site runs in an IIS. RoleEnvironment will always be false, because it is not initialized there. Look at Azure Web Sites more like a regular hosting. Can you tell if your website is running in XYZ Hosting, or in your own IIS?
One thing that you could consider is the Application Settings in your web.config (yes, the appSettings section) and have some setting indicating whether you run on WebSites or not. Read the full article here about App Settings in Azure WebSites to understand what I mean. In short: if you set a setting value via the portal, it will take precedence over what is in web.config. You can even just set it in the Portal, not having it in your web.config.