I will be placing an Azure website, in several regions. Then configuring the Azure Traffic Manager to distribute requests to each region.
The website needs to know which region it is running in. Is there an API available to determine this? Or, is my only choice, to define a REGION app setting, that is set appropriately for each Azure website?
I had the same question today, and found this thread. It seems that Web Apps now do include the promised environment variable showing the region in which they are deployed.
I simply used:
string region = Environment.GetEnvironmentVariable("REGION_NAME");
and it worked fine (note that it returns null when run outside Azure e.g. in Visual Studio).
I got a response, to my question, on the Microsoft Azure DNS and Traffic Manager forum.
The answer was:
There's no handy way currently. In the Azure Powershell, you could use Get-AzureWebsite to read the WebSpace value, which is structured as Region+"webspace".
For now it's easier to just add it to the app setting, like you suggested. We'll have the region value as an environment variable in a later release.
So, as suggested, we will just use an app setting to tell the website what region it is running in. We will switch over, to the environment variable, when it becomes available.
Related
Currently we have a Function App in Azure which is hosted in Windows. Initially once you create, you need to choose the hosting environment as below:
Question:
Is there any chance to change the underlying hosting environment for already created Azure Functions? I did not find anything related to that even in the official documentation.
Appreciate the clarification.
Change existing Azure Function's hosting OS from Windows to Linux
In short, it's impossible.
Because of the potential of breaking changes, you can only set the Operating System when you create function.
I'm searching for ways to modify and edit app settings for Azure function during runtime.
from the links below, I was able to find how to add bindings locally and add connection settings through azure portal or Azure Cli
https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local#local-settings-file
https://learn.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library#environment-variables
However, I'm searching for ways to generate new connection setting variables as well as new bindings at runtime.
The use case would be, where we need to onboard users without manually interacting with the Azure function app configuration.
I also tried modifying it thorough an example given in below link:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp#environment-variables
I was able to modify the variable temporarily, but it appears that it loses the changes as soon as the run gets terminated (also, it didn't work when I published the app on Azure).
Is there way to accomplish this during runtime?
My set up is to have two azure functions:
1. dedicated to modifying app settings if change is detected in CosmosDB where new user information is added.
2. dedicated sending messages, but generating bindings based on app configurations added by azure function 1.
My initial thoughts were to store the whole app settings in cosmosDB and generate appsettings based on that document at every onetime, but I'm pretty sure there is better ways to do this.
also, it looks like my connection strings in local.settings.json don't get reflected when I actually publish them. what am I missing?
Thanks, in advance :)
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.
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.
How do I configure Azure Web Role to have United Kingdom (as opposed to US) as it's language/regional settings etc for all accounts? I believe I can RDP in and change it. However I want to set it to default on creation of the web role. It is making a difference to some classic ASP pages we have in a legacy app.
Interesting problem. Can't say I've attempted this before. What you want is to set a different locale at startup so that it is always enforced as VMs making up your Web Role may be rebooted from time to time.
Unless someone comes up with a better idea you could try to modify the registry from a Windows Azure Startup Task. You would need to know which user locale to modify and you would need a registry changing CmdLet like this one (though I haven't tried it): Set-RegistryKey.
Given you can figure out what registry value to modify and what user is running your IIS this could be done.
Use a Startup Task. Call a Cmd script and envoke a PowerShell script. Call the CmdLet and set the locale you want.
I realize this is not a complete solution, just a suggestion. Hopefully it is worth while.