Azure app services have a testing in production setting, that allows you to route traffic to different slots, Scott Hanselman talks about it here
But - when I'm done, and I want to stop traffic from routing between different slots, how can I turn it off and disable it entirely, so that ALL traffic goes back to my production slot? Using the azure portal, I can route all 100% of traffic back to my "production" slot, but because it's cookie based (there is a cookie called x-ms-routing-name that sets the current slot that users are stuck to), it only works for new traffic - users that are already routed to another slot stay routed to it.
Is it possible to "turn off" this feature entirely and get all traffic back to my main production slot?
there is a cookie called x-ms-routing-name that sets the current slot that users are stuck to
The x-ms-routing-name could let you to route requests to a specific slot.
To reroute users to a specific slot using it, you must make sure that the slot is already added to a Traffic Routing list.
You could use the following link in your web page to let uses opt out of your beta app:
Go back to production app
The string x-ms-routing-name=self specifies the production slot.
Once the client browser access the link, not only is it redirected to the production slot, but every subsequent request will contain the x-ms-routing-name=self cookie that pins the session to the production slot.
For more details, you could refer to this article.
If you have the "routing rules" parameter of an AppService configured, you will get the x-ms-routing-name header.
As a shortcut, you can remove the number 0 in the Azure Portal.
<-- This will remove the header completely
<-- This will enable the header, but never route to the other slot.
You can also null the whole section routingRules, e.g. via https://resources.azure.com.
"type": "Microsoft.Web/sites/config",
"location": "West Europe",
"properties": {
"routingRules": [
{
"actionHostName": "mysite-myslot.azurewebsites.net",
"reroutePercentage": 4,
"changeStep": null,
"changeIntervalInMinutes": null,
"minReroutePercentage": null,
"maxReroutePercentage": null,
"changeDecisionCallbackUrl": null,
"name": "myslot"
}
],
If you disable the setting completely, you have to wait about a minute. Then the AppService will start ignoring the x-ms-routing-name header, even if clients still have it pointing to your staging slot.
Related
In order to make my application specific tasks avoid timeout errors, inside AKS cluster, I have changed the backend settings of my azure application gateway "Request time-out (seconds)" from 30 to 900. However, it reverts back to be 30 when I check it next time. What can we do to make this timeout setting a permanent change.
If you are using AGIC, you should control these settings from ingress annotations and not directly change it on application gateway.
You can use:
appgw.ingress.kubernetes.io/request-timeout: "900"
Reference: https://azure.github.io/application-gateway-kubernetes-ingress/annotations/#request-timeout
I have so far used the appsettings.{environment}.json files to keep application level configuration settings. Now I encounter this tab in Azure Portal for an App Service.
What is the difference between using the appsettings.json files and "Application Settings" Tab in the Azure Portal? And which one to use When?
difference between using the appsettings.json files and "Application Settings" Tab in the Azure Portal? And which one to use When?
If you are using more than one environment like Production, Staging and Development for your application. You need specific Environment appsettings i.e., appsettings.{environment}.json.
Or if you don't want to use any specific environment. In this case you are using only production (Default) Environment you can use appsettings.json file.
Few reasons to use Azure Application Settings -
1st - Let's assume that in order to avoid leaking configurations in appsettings.json, you aren't committing it to your repo. But you also deploy your web app on Azure AppServices. In this situation Application Settings tab can help you to configure your configurations directly and then Azure will auto create appsettings.json by reading those values.
2nd - This time we are committing appsettings.json and deployed web app on Azure. We also have a property as
{
"Users": {
"CanAccessApp": [ "abc#gmail.com", "test#gmail.com" ],
"CanAccessHangfire": [ "abc#gmail.com", "test#gmail.com" ],
"CanAccessLog": [ "abc#gmail.com", "test#gmail.com" ]
}
}
Now, I also want one more user to be able to access logs. How you will do it? Generally, update in your appsettings.json and redeploy.
Or you can create similar property in Application Settings by
Users:CanAccessLog:0 -> vic#gmail.com
Users:CanAccessLog:1 -> abc#gmail.com
Users:CanAccessLog:2 -> test#gmail.com
and so on where 0,1,2 are indexes of the array (Azure style). This one will help us to test quickly without redeploying or modifying appsettings.json.
I'm trying to track when my bot stops responding. I think it stops responding when it doesn't get any usage for a while. I'll send it a few requests sometimes and then I won't get any responses back. I can fix this by stopping and restarting the App Service within the Azure Portal.
I was considering creating a cronjob that sends a POST request to the somebotname.azurewebsites.net/api/messages endpoint and e-mailing me if there's no response, but I'm not sure how to get a token so that this will pass. I was also considering doing a daily publish via azure devops but I'm not sure if this is even possible.
Is there a best practice for testing if a bot is still running?
The best way to do it is with Application Insights which you can find here
https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
It's not hard to add to a project. Simply add NuGet package and initialize with the key (InstrumentationKey).
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.7.0" />
</ItemGroup>
And init like so
public void ConfigureServices(IServiceCollection services)
{
// The following line enables Application Insights telemetry collection.
services.AddApplicationInsightsTelemetry();
// This code adds other services for your application.
services.AddMvc();
}
With appsettings.json
{
"ApplicationInsights": {
"InstrumentationKey": "putinstrumentationkeyhere"
},
"Logging": {
"LogLevel": {
"Default": "Warning"
}
}
}
For instance here is full example for .NET core
https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core
In the app insights you will see all errors in real time and you can set up alerts to notify you of downtime.
If you will have production issues there is also cool feature of snapshot debugging to test what happened.
Check your "Always On" setting and make sure it's set to "On".
Azure WebSites Always On
Configuration->General Settings->Always On
Of course, you'll need to pay more in this case.
We have a load balanced set in Azure for our web application, which load balances port 80 and 443 between two VMs. We have used the default tcp probe. Is there a way to get the current status of the probe for the load balancer from Azure?
I know I could just check each individual machines and do a probe myself, but I want to know if we could see what Azure sees for each machine.
Well as of 2018-06-05 this feature is not available in the Azure Portal. Today you have to configure "Diagnostic Logs" for the Load Balancer. If you choose the "Storage Account" option a JSON file is created with records like below
{
"time": "2018-06-05T08:50:04.2266987Z",
"systemId": "XXXXXXXX-XXXX-XXXX-XXXX-d81b04ac33df",
"category": "LoadBalancerProbeHealthStatus",
"resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX/RESOURCEGROUPS/TEST-INT/PROVIDERS/MICROSOFT.NETWORK/LOADBALANCERS/TEST-LB",
"operationName": "LoadBalancerProbeHealthStatus",
"properties": {"publicIpAddress":"XXX.XXX.XXX.XXX","port":8080,"totalDipCount":2,"dipDownCount":0,"healthPercentage":100.000000}
}
,
{
"time": "2018-06-05T08:50:09.2415410Z",
"systemId": "XXXXXXXX-XXXX-XXXX-XXXX-d81b04ac33df",
"category": "LoadBalancerProbeHealthStatus",
"resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX/RESOURCEGROUPS/TEST-INT/PROVIDERS/MICROSOFT.NETWORK/LOADBALANCERS/TEST-LB",
"operationName": "LoadBalancerProbeHealthStatus",
"properties": {"publicIpAddress":"XXX.XXX.XXX.XXX","port":8080,"totalDipCount":2,"dipDownCount":1,"healthPercentage":50.000000}
}
"Log Analytics" suggested by Eric is not mandatory but can be used to analyze these LB logs.
There's an easy solution for this now; not sure when it was added to Azure, but here you go:
Click on the Load Balancer from within the Azure portal
Under Monitoring, click on Insights.
You should see something like this:
Hopefully your health checks will look healthier than the ones in this image!
you could use 'Log Analytics' to see current status for health probe. Below has more details and step-by-step.
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-monitor-log
you can check https://learn.microsoft.com/en-us/rest/api/load-balancer/loadbalancerprobes, click on GET and then Try it.
It will need you to login with your Azure credentials and put the LB name, RG and Probe on LB which you want to check.
fill the details and it will give you the response code if the probes are healthy or not.
Similarly you can use https://learn.microsoft.com/en-us/rest/api/load-balancer/loadbalancers/get to get all the details of a particular LB.
I want to specify a custom machine key for my websites running on Azure, so I can swap between staging and production and keep the environment consistent between the two without users being "logged out" whenever I do a swap (because otherwise the machine key changes and the user's cookies can't be decrypted anymore). I've previously been setting this in the web.config file, but I don't really like having this value stored in source control (I'm continuously deploying changes to the server). Connection strings can be specified in the Azure portal to avoid this problem. Is there a solution for machine keys?
In your web.config reference an external config file for the machinekey section:
<system.web >
<machineKey configSource="mkey.config"/>
</system.web>
Create a file mkey.config like this:
<machineKey
validationKey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"
decryptionKey="B179091DBB2389B996A526DE8BCD7ACFDBCAB04EF1D085481C61496F693DF5F4" />
Upload the mkey.config file to Azure web site using ftp instead of web deploy.
I'm not 100% sure I understand you question correctly, so I'll answer both possible interpretations.
Interpretation #1: Before you swap prod and stage your users got key A when they were accessing the (old) prod. When you do the swap you want users to keep getting key A when they hit the new prod.
Use App Settings. You can set them using the Portal or Powershell. Those are key value strings that you can set and they are accessible as environment variables from your site. When you swap you prod and stage slots the app settings that were on the old prod all move to the new prod, so your customers will see the same values for them.
Interpretation #2: Before you swap prod and stage your users got key A when they were accessing the (old) prod, and key B when the accessed the old staging slot. When you do the swap you want users to getting key B when they hit the new prod and key A when the access the new staging slot
Using sticky settings. Those are app settings that you set for the site but you configure them to stay with the site that they were on, meaning that when you swap sites you swap the settings as well. You can make app settings sticky by using the following powershell command.
Set-AzureWebsite -Name mysite -SlotStickyAppSettingNames #("myslot", "myslot2")
Full details in this link: http://blog.amitapple.com/post/2014/11/azure-websites-slots/#.VMftXHl0waU