Is it possible to lookup the application name for an Azure app as it runs, i.e., get the information about that is displayed in the Azure portal? In the example below, I'd want something to tell me from within the application that I am running sitemap-prod-eastus.
I've been looking at the Azure Context object but not seeing what I need. There is an invocation ID, a name for the function, a directory - not the info in this window.
Maybe this can be done through Azure Application Insights?
I am working in Node JS.
I've not seen anything that would expose this to a function app. That said, there is one sort of workaround that you could do which would work - go to the Configuration blade for the function app, Application settings tab, and add a configuration key like function_name and set its value to the name of your app. Your app could then just read it out of configuration.
It's an extra step, but if you're doing it with something like ARM or Terraform, it's just another configuration entry with a variable you already declared to set up the app in the first place.
Answering my own question: Azure provides WEBSITE_SITE_NAME in the runtime environment that matches the name of the function app.
Related
I am trying to use a template to deploy a managed Kubernetes cluster (AKS). My problem is that the template has a parameter aadSessionKey that I seem to be unable to locate.
I assume the expanded name of the parameter is Azure AD SessionKey. When I look in the portal, I can see that my Azure AD has a Name, Application ID and Object ID, but nothing that looks like a session key, nor a way to generate such a thing.
I am using a free trial account if that matters.
Can you try entering any random value and try deploying it. It seems like this is system generated value which is not to be filled by clients. This has been present in template for some other reason.
Ref - https://twitter.com/ashtonkj/status/1196384865672925184
I created an environment variable in Azure App Service. However, I'm not able to pick the value from Azure while it is published.
So I added it to the appsettings.json, and it works.
My question would be, if I add an environment variable in Azure configuration settings, shall I add it in the appsettings.json as well, or is having it in the Azure environment settings enough?
When I navigate to
https://your-web-name.scm.azurewebsites.net/Env.cshtml
I can clearly see the variable is present there. Why is this not being picked up in the code? Am I doing something wrong?
appSettings["MailKitPassword"] <-- This is not being picked up, so I have to hard-code it.
In order to retrieve it you should use Environment.GetEnvironmentVariable("APPSETTING_MailKitPassword")
As Thiago Mentioned, you need to use GetEnvironmentVariable method to retrieve the AppSettings values,
so your code should be
Environment.GetEnvironmentVariable("APPSETTING_MailKitPassword")
However i would recommend you to store the passwords in Azure KeyVault.
I have looked at the Azure functions documentation but couldn't quit find answer to my question and hence I thought I asked the wider user community.
We have a single Azure subscription with multiple resource groups for our different environments, so one group for dev, one for test and one for prod.
We have developed multiple Azure functions in dev and would like to use CI/CD to deploy to test and prod.
However, doing this manually Azure complains that the name of the function app already exists which is weird because that would imply that the function app name must be unique to the subscription or globally across Azure? Does that mean you need to name your function apps func-dev, func-test etc? That seems very ugly.
How have you managed to solve this?
azure function name has to be globally unique (not just in your subscription), because the name would be like:
functionName.azurewebsites.net
so you cannot have a function with name functionName if you already created one, because the dns name for that is occupied.
you can use subfunctions to work around that, so create a subfunction called dev, test, and prod inside the function and call those
Function App, as any App Service application, has to have globally unique name:
Naming Conventions -> Compute.
Indeed, it's typical to include your environment into the App name.
Function names have to be unique within a single Function App, but may repeat in different apps.
I have published an API app from Visual Studio to a new resource group, also created an App Service Plan, so after the deployment the resource group contains 2 items:
AppServicePlan1
AppService1
Now I am trying to deploy these items to another resource group as follows:
Select 'Automation script' in the resource group settings
Click 'Deploy'
Select 'Create new' resource group, enter its name
Enter 'Serverfarms_AppServicePlan1_name' parameter value (new app service plan name, e.g. AppServicePlan2)
Enter 'Sites_AppService1_name' parameter value (new app service name, e.g. AppService2)
Tick 'Agree to terms and conditions'
Click 'Puchase'
The process fails with the following error message:
"The host name AppService1.azurewebsites.net is already assigned to another Azure website: AppService1."
I have tried different things - deploying app service plan, logic apps, etc. from one resource group to another works fine, but deploying an app service fails as described above.
I have tried changing the hostNames property in the template file to ["AppService2.azurewebsites.net"] manually - I'm not getting the error then (although I'm not sure, maybe something else also needs to be changed, e.g. properties enabledHostNames, hostNameSslStates?) and the deployment seems to work, however the 'deployed' app service can't be used as it contains only 1 file - hostingstart.html.
What am I missing?
I think you have everything correct - as you noticed when you use the generated automation script it will create everything with the same properties that currently exist. We try to parameterize the correct value (like the web app name) but there are some details that can be overlooked (like host names). After changing all that it sounds like you got it to deploy.
The "code" however is not part of the automation script - only the infrastructure and configuration. So you still need to deploy your app to have it be identical. You can folder app deployment into the JSON template (using webdeploy or github) but since that requires access to external artifacts, that's not done automatically.
That help?
I'm trying to build a small program to change the autoscale settings for our Azure WebApps, using the Microsoft.WindowsAzure.Management.Monitoring and Microsoft.WindowsAzure.Management.WebSites NuGet packages.
I have been roughly following the guide here.
However, we are interested in scaling WebApps / App Services rather than Cloud Services, so I am trying to use the same code to read the autoscale settings but providing a resource ID for our WebApp. I have already got the credentials required for making a connection (using a browser window popup for Active Directory authentication, but I understand we can use X.509 management certificates for non-interactive programs).
This is the request I'm trying to make. Credentials already established, and an exception is thrown earlier if they're not valid.
AutoscaleClient autoscaleClient = new AutoscaleClient(credentials);
var resourceId = AutoscaleResourceIdBuilder.BuildWebSiteResourceId(webspaceName: WebSpaceNames.NorthEuropeWebSpace, serverFarmName: "Default2");
AutoscaleSettingGetResponse get = autoscaleClient.Settings.Get(resourceId); // exception here
The WebApp (let's call it "MyWebApp") is part of an App Service Plan called "Default2" (Standard: 1 small), in a Resource Group called "WebDevResources", in the North Europe region. I expect that my problem is that I am using the wrong names to build the resourceId in the code - the naming conventions in the library don't map well onto what I can see in the Azure Portal.
I'm assuming that BuildWebSiteResourceId is the correct method to call, see MSDN documentation here.
However the two parameters it takes are webspaceName and serverFarmName, neither of which match anything in the Azure portal (or Google). I found another example which seemed to be using the WebApp's geo region for webSpaceName, so I've used the predefined value for North Europe where our app is hosted.
While trying to find the correct value for serverFarmName in the Azure Portal, I found the Resource ID for the App Service Plan, which looks like this:
/subscriptions/{subscription-guid}/resourceGroups/WebDevResources/providers/Microsoft.Web/serverfarms/Default2
That resource ID isn't valid for the call I'm trying to make, but it does support the idea that a 'serverfarm' is the same as an App Service Plan.
When I run the code, regardless of whether the resourceId parameters seem to be correct or garbage, I get this error response:
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
{"Code":"SettingNotFound","Message":"Could not find the autoscale settings."}
</string>
So, how can I construct the correct resource ID for my WebApp or App Service Plan? Or alternatively, is there a different tree I should be barking up to programatially manage WebApp scaling?
Update:
The solution below got the info I wanted. I also found the Azure resource explorer at resources.azure.com extremely useful to browse existing resources and find the correct names. For example, the name for my autoscale settings is actually "Default2-WebDevResources", i.e. "{AppServicePlan}-{ResourceGroup}" which I wouldn't have expected.
There is a preview service https://resources.azure.com/ where you can inspect all your resources easily. If you search for autoscale in the UI you will easily find the settings for your resource. It will also show you how to call the relevant REST Api endpoint to read or update that resorce.
It's a great tool for revealing a lot of details for your deployed resources and it will actually give you an ARM template stub for the resource you are looking at.
And to answer your question, you could programmatically call the REST API from a client with updated settings for autoscale. The REST API is one way of doing this, the SDK another and PowerShell a third.
The guide which you're following is based on the Azure Service Management model, aka Classic mode, which is deprecated and only exists mainly for backward compatibility support.
You should use the latest
Microsoft.Azure.Insights nuget package for getting the autoscale settings.
Sample code using the nuget above is as below:
using Microsoft.Azure.Management.Insights;
using Microsoft.Rest;
//... Get necessary values for the required parameters
var client = new InsightsManagementClient(new TokenCredentials(token));
client.AutoscaleSettings.Get(resourceGroupName, autoScaleSettingName);
Besides, the autoscalesettings is a resource under the "Microsoft.Insights" provider and not under the "Microsoft.Web" provider, which explains why you are not able to find it with your serverfarm resourceId.
See the REST API Reference below for getting the autoscale settings.
GET
https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/microsoft.insights/autoscaleSettings/{autoscale-setting-name}?api-version={api-version}