Azure Flask web app + Azure SQL + Github | 500 server error every day - azure

I've created Flask web app which is connected to an Azure SQL db. The app works just fine locally and I've pushed it successfully using two methods (i) Github and (ii) External Repository. When it is just pushed, everything works just fine, but for some reason, it will later on within the day (or the next day) crash and provide an 500 internal server error. When I push it again, it works just fine... and so on and so forth.
I've looked at a majority of post related to this issue but I could not find a solution so far. The thing is I don't really know where to look to find a solution. The Azure diagnosies isn't helpful in this case and just tells me :
I thought it might be the connections string with the db, but it works just fine for a day before the app crashed.
Then I though it might be the service plan, but I tried several (test & prod) and the problem remains.
I suspect it might be the app server itself, but I don't know where to look to confirm.
Any ideas on how to resolve such an issue ?
Flask app = Python 3.8

I found a solution that seems to work. I hope it will last and that it'll help someone in the same situation.
I. Kudu :
Go to the Kudo console : myAppName.scm.azurewebsites.net/,
Go to Bash menu (I'm Linux based),
cd LogFiles,
cat 2021_10_08_xxx_docker.log,
I found this :
II. Azure CLI :
After a bit of research, I found this command to modify the WEBSITES_PORT :
az webapp config appsettings set --resource-group <ressource-group> --name <appname> --settings WEBSITES_PORT=8000.

Related

nestjs deployment using vscode to azure app service

This is my first nestjs application (or any nodejs application for that matter) and I'm having trouble deploying it to a "production" environment. Steps I've followed:
1) I installed the Azure extension for VS Code
2) I click the blue up arrow icon in VS Code to initiate the deployment
3) The first time I tried, I had manually created my node JS application from portal.azure.com and chose that app service from the list, it didn't work
4) the second time I tried it, I created a new app service from the deployment process in VS Code
5) The application deploys and I get a deployment successful message. If I expand deployments under my new app service in the azure extension in VS Code, I see the deployment and when I select that, I get a log that finishes with this screenshot:
6) I try hitting an endpoint on my nestJS api from postman and I get an application error message that has a link to https://mywebsite.azurewebsites.net/detectors to troubleshoot. When I click that link, it fails to load in the azure portal
7) I read somewhere that I need to include my nodeJS version on the app service so I tried adding that - see screenshot below:
8) I can see the files if I use the SSH tool from the azure portal
a couple things to mention, I've read a few things that suggest I need to do something with "tsc"? in my package.json file. Since this is my first time doing anything with nestjs/nodejs, I have no clue what that means. I have not modified my package.json file (at least the scripts section) at all from how it comes out the box. Is there something I need to adjust there? Is there something I need to change on azure? I'm really liking nestjs a whole lot, but getting it to work in on my "real" server is proving to be a challenge...
any help is greatly appreciated.
TIA

Azure WebApp for Container WebSocket Not Working - SAFE / ElmishBridge

I have been working on a project built from the SAFE stack template and everything runs successfully when I build it to a docker container and run this locally.
Using Azure WebApp for Container, the container successfully attaches and deploys, and I am able to load the app from the URL as expected. [The Server is responding with the Client App]
The issue is that the WebSockets are not working once deployed, but they work properly from when I run the container locally.
I've looked through a lot in regards to all of this and tried a lot of different things, but am having no success. I could share more, but I was primarily seeing if anyone has encountered this.
I did run this:
az webapp config set --web-sockets-enabled true --name MyAppName --resource-group MyResourceGroup
as per something suggested from here: https://social.msdn.microsoft.com/Forums/azure/en-US/036f9c3d-16dc-4e52-b943-5eb1afed824f/enabling-websockets-on-a-web-app-for-containers-service
I can confirm that the WebSockets being enabled was set to false, by default, and that it required using the CloudShell to set it to true.
It is frustrating, because I am unable to get any information beyon the following:
WebSocket connection to 'wss://xxx.azurewebsites.net/socket/init' failed: Error during WebSocket handshake: Unexpected response code: 503
I don't want to initially overshare detail about code, unless requested as something helpful, because everything works when run in a container locally. It does feel oddly like something related to that Azure setting or perhaps some kind of Port-related Application Setting or the such.
Further, this does feel like it is not an aspect of SAFE-template or Elmish-Bridge, but anyone who has successfully deployed this combo on Azure using a Docker Container may have direct insight on this problem. It seems like something wider than this particular usage, but related to Container/Websocket usage on Azure.
Any help is appreciated. Thanks.
It seems that WebSockets are not fully supported in Azure WebApp for Containers that are running Linux Containers:
https://github.com/aspnet/AspNetCore/issues/10370
Can you check what appservice plan you have?
TLDR: you need to get at least a B1 appservice plan. The FREE one will not work with Streamlit (and apps using WebSockets).
After a couple of hours trying to find the answer to the same answer, I found out what it was. I wanted to deploy a streamlit app, but was stuck at the same place after following the guidance. A Ctrl+Maj+J showed in the "Please wait" page that WebSockets were an issue. It appears WebSockets will not work for FREE Linux appservice plans, and after recreating a B1 appservice plan (as in the guidance), it worked.
Might be a duplicate of this issue.

Azure Web App Profile UNKNOWN_ASYNC - What is it?

My web app has quite a bit of a userload, but still - running on 10 azure instances it should run good.
Now and then some instances just seem to die, while others are still working perfectly. I tried to profile it through the Azure portal, but by far the biggest issue is something called UNKNOWN_ASYNC.
Locally I can't reproduce this problem.
What could the reason be for UNKNOWN_ASYNC?
How can I figure out what is going on?

Cannot see Deployment Source options in Azure Portal

I'm writing this simple answer to help others that would otherwise have had to spend hours getting confused by every tutorial out there.
My issue:
Newbie to Azure web apps and have been trying to learn how to deploy via GitHub. Every tutorial and video I checked out showed that as soon as you create a Web App then go to the Deployment options screen it lets you choose how you want to deploy it.
However I was not seeing this in mine - it was as if it was pre-configured for me but there was no ftp or GitHub option showing.
Solution:
The problem may be because I had used the node.js empty template to create my web app and it preconfigured something for me (though I don't see why this should be the case); but in any case I went to the Deployment options screen, pressed the Disconnect button. Waited then hit settings, and hey presto I finally got to where all the tutorials were talking about.

How to further debug a 500 Internal Server Error after upgrade to ASP.NET 5 beta5

I had a site running asp.net 5 beta4, and decided to upgrade to beta5. The site runs locally fine. I pushed the changes to master and it was picked up from bitbucket and deployed successfully.
When I try to hit the site in azure, I get a 500 Internal Server Error. I've tried a number of things, but can't seem to track down the root cause of the failure. I'm looking for suggestions as I'm hitting a wall. From what I've tried below it seems like some fundamental initialization is failing.
Here's what I've tried:
Enabling customerrors="off". I added a web.config to the wwwroot folder with system.web/customErrors mode="Off". I've verified that the web.config is populated correctly in the deployed wwwroot and had the appsettings containing the dnxversion etc merged correctly.
Customizing the custom error page, adding runtimeinfo. I have the following set in my Startup.cs:
app.UseErrorHandler("/Home/Error");. I also have set the error page to display the exception. This doesn't seem to be hit.
Attached to the remote process to debug. Visual studio eventually freezes, so haven't gotten anywhere with this.
Enabled application insights. This registers events when I debug locally, but doesn't capture anything from the azure instance.
Enabled application logs and request failure tracing. The detailed errors show a 500.0, without much detailed information.
Imgur
Imgur
I've also verified through the console that the runtime is set correctly to beta5.
Update:
I set the ASPNET_ENV to Development and it loaded with appsettings loaded via the azure portal. Setting ASPNET_ENV to something else isn't working. I also removed any custom code from startup.cs pertaining to the non-development environments, with no help. I'm still looking for a means of capturing the original error.
Assuming you are targeting DNX451 and not dnxcore50, there is a good chance Azure it still trying to run it against the beta4 runtime instead of beta5. If that's the case, you won't get a decent error message.
Try adding an environment variable in Azure "SCM_DNX_VERSION" and set it to 1.0.0-beta5. It looks like kudu was recently upgraded to support beta5 https://github.com/projectkudu/kudu/commit/55175a017779bf493ff8e6ce87b96dd1451f7d7b, so you might want to try to redeploy from bitbucket in the case that the Kudu team has already deployed this change.
For a little more detail, you can check out my previous answer (although it is very dated and references the old "K" names) here:
Deploying ASP.NET vNext beta 2 on Azure with Kudu
Every time you update to a new beta, you will have to update your SCM_DNX_VERSION environment variable.

Resources