Application Initialization for an App Service in Azure not working - azure

We have an appservice in Azure configured to have max 8 instances and everytime we deploy, we see restart activity under Availability and Performance (Diagnostics).
We have also observed loads of 5xx errors this is happening. Our analysis so far is that requests are getting routed to cold instances which have just been spun up and these are reasons for getting failures.
I have found this guide -> https://azure.github.io/AppService/2020/05/15/Robust-Apps-for-the-cloud.html and following the Application Initialization advice.
As a result, I have added
<applicationInitialization >
<add initializationPage="/healthcheck"/>
</applicationInitialization>
to web.config
I restarted the app service and sent few test requests to the app. In the Application Insights I can see the health endpoint being called - so application initialization logic is kicking in. However, it is calling http://localhost/healthcheck and 307 being returned.
I looked into 307 and the reason, it is returning 307 as app service is configured to only run using https protocol but http://localhost is non-https and hence service is redirecting.
What do i do need to so it calls the app service with https protocol.
I tried adding the full app url in the application initialization block but then I can see
http://localhost/https://app-service-name.azurewebsites.net/healthcheck being called - which is even worse.
What am I doing wrong?

I assume your application runs ASP.NET Core. As mentioned in the other answer, application initialization only supports HTTP, so you need to make that work. What we did is this:
/// </summary>
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
// ...
// IIS App initialization requires HTTP
app.UseWhen(
context => !WarmupController.IsWarmupRoute(context.Request.Path),
mainApp => mainApp.UseHttpsRedirection()
);
WarmupController.IsWarmupRoute basically only contains a StartsWith check.
This way you allow HTTP requests only for your warmup/healthcheck route. There is no need to adapt web.config or AppService settings.

Related

Blazor websocket disconnects when using Application Gateway

I have two blazor server (.NET 6) apps running as app services in Azure. The apps are to be "hidden" behind an application gateway to give users the impression that they are visiting the same site. Traffic is to be directed using parts of the url i.e {{domain}}/* go to app 1, {{domain}}/{{keyword}} go to app 2.
This has been set up, using routing rules on the gateway and the routing works as expected, with requests reaching the correct apps. However, when reaching app 2, the websocket immediately disconnects, killing blazor in the process. Error message displayed in the console of app 2. The apps are very barebones, containing very little code as this is a POC.
Things I have tried:
Use Azure SignalR and not using it.
Configured both apps to use websocket
Use different routing rules for the two apps and use the same routing rule with two backend pools.
Use Azure Front Door, but the same issue persists.
Randomly toggle settings
Added options.ServerStickyMode = ServerStickyMode.Required; to the signalR config in program.cs
Added `#inject Microsoft.AspNetCore.Http.IHttpContextAccessor _HttpContext
#{
_HttpContext.HttpContext.Response.Headers["Cache-Control"] = "no-store";
}` to _Layout.cshtml with the _HttpContext. yadayada both inside the body and outside.
Maybe the most frustrating thing is that it works just fine when reaching the first app. I have tried switching the deploys, i.e. deploy app 1 code to app 2 service and vice versa, to no avail.
Have anyone else experience a similar thing? Any config or code changes I have missed?

Azure Application Gateway: Why when i hit its Public IP, i redirect to "<app_service_url>:80"?

I have an app service which runs web app.
I created application gateway on the front of wab app.
But when i hit Application Gatway's Public IP, i get redirected to https://somename.azurewebsites.net:80/
My Questions
Why it does not goes to go <ApplicationGatwayPublicIP> directly instead of https://somename.azurewebsites.net:80/
Let's assume that i accepte to https://somename.azurewebsites.net:80/. Why it adds 80 at the end (which i have to delete manually in oreder to work)?
Thank you in advance for your help!
PS: I will make some screenshot which can be helpul:
Backend Pool (app service):
Backend Settings (for app service):
If you need more informations, please make me a comment
Thank you again
To resolve this issue, you need configure your backend pool with use of custom domain as below:
Make sure to add authentication/trusted root certificates of back-end servers and upload a certificate as below:
And configure a request to routing rule in setting under rules in backend targets try to add the Backend Pool which App Service has been configured and HTTP setting add which app gateway to connect app service and save
Once a backend pool is healthy stage now you can able to use public IP addresses that can be accessed directly. Now you can try to restrict access. check this similar issue answer by jeremy
The main cause of issue you need to add custom domain Configure App Service with Application Gateway along with certificate.
Reference:
Manage traffic to App Service - Azure Application Gateway | Microsoft Learn

Azure App Service Deployment Slot - Application Gateway

Working on a project where we are starting to use Deployment Slots in our App Services.
All our Prod apps are located behind Application Gateway, and we would like to also have our Slots located behind Application Gateway.
I understand we can not do this using "App Services" as target type in the Backend Pools as of now, but wondered if it is doable using "IP Address or FQDN" as target type.
I have tried to set it up, with various changes in the "HTTP Settings", Probe and so, but haven´t gotten it up spinning.
Can anyone confirm if this is possible, and have any tips on how this should be configured?
Thanks!
I was able to get this working on one of my slots.
Basically setup the listener with your necessary protocol, port cert, hostname, etc... I'm using multi-site listeners so I can have multiple URLs for the one AppGW/Public IP.
The rule points to the listenter, backend pool and appropriate http setting.
The HTTP setting should be configured to connect to your app service URL accordingly. I'm using the azurewebsite.net URL, so I use well known CA cert & override hostname from backend target:
The backend pool then points to the azurewebsites.net URL:
Make sure that GET / works on your app service and returns 200-399 HTTP status codes. Anything outside that range is a failure and the backend pool will be removed. If you need to create a custom health probe to a URL that will respond properly, or adjust the acceptable HTTP status code (if 401 or 403 due to required auth, then just override it with that for testing purposes for now).
I'm trying to do it again with a second slot and running into 502 errors from the App Gateway... However, I'm also waiting on DNS changes from my network team. My first one with my company domain works via hosts file edit, but the 2nd slot (which has 2 different URLs/listeners configured in the AppGW) doesn't want to work the same way for some reason.

How do you add a web app to the backend pool of Azure Application Gateway?

I have created a Webapp and have added an IP restriction so that it can only be accessed via the Azure Application Gateway Public IP.
In the Application Gateway, I navigated to the BackEnd Pools, clicked to ADD backend pool and copied the web app URL e.g. https://mywebapp.azurewebsites.net, it complained it only wanted FQDN so I removed the https:// and entered in mywebapp.azurewebsites.net
I then navigated to my Application Gateway and copied the public IP address of the gateway and entered it in my browser to test the app but it won't see the web app, I get the error "This site can’t be reached."
Have I missed a step, is the FQDN incorrect? Do I need to use a custom Domain?
One of the things I would look for is if a listener and a rule has been created. This is required to enable the application gateway to route traffic appropriately to the backend pool.
More info here -
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-web-app-powershell
I tried adding an existing app service web app to the backend pool like you mentioned and realized that it was not adding the listener/rule for it. When i used the powershell script as mentioned in the link above which creates a listener and a rule , i was able to successfully hit backend pool website when i browsed using the Application Gateway public ip/dns.
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-create-gateway-arm

Validating the endpoint for Azure hosted service

I have deployed one azure WCF hosted service. I created one service and one service contract. Everything works fine if I call it as below:
http://myexampleservice.cloudapp.net/TestSertvice.svc/Test1
Now, we want to catch all invalid request, which either do not have the correct service name or correct operation name. For example all requests of the form below:
http://myexampleservice.cloudapp.net/TestSertvice12.svc/Test1
Is there any way to do this?
If I call above invalid requests then service returns response status as 404. Is there any possibility that azure traffic manager will degrade the service if it gets too many such requests?
-Manish
This is actually pretty easy to do. So first you will need to catch 404 requests occurring on your instance(s):
<customErrors mode="On" >
<error statusCode="404" redirect="~/Errors/Error404.aspx" />
</customErrors>
Each time a 404 error occurs the user/consumer will be redirected to Error404.aspx where you can add this event to a local counter (a file or a static variable) or shared counter if you have multiple instances (SQL Azure, Table Storage, ...).
Take a look at the options you have when configuring the traffic manager:
You can setup a monitoring endpoint. This would point to a different page (like /Status/CanBeUsed.aspx). This page should return an HTTP status code different from 200 if it decides that the deployment should not be used (ie: if your local/shared counter contains too many 404 errors). The Traffic Manager will monitor this page and after 3 failed requests it will fail over to a different deployment.

Resources