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.
Related
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.
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
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?
I am using a nodejs based custom deployment on App Engine using google/nodejs-runtime docker image.
I built my code on the localhost via
gcloud preview app run .
and it runs fine. But when i deploy it to my App Engine using
gcloud preview app deploy .
it give this error (along with whole stacktrace):
Build Error: Get https://index.docker.io/v1/repositories/google/nodejs-runtime/images: dial tcp: lookup index.docker.io on 192.168.2.1:53: no answer from server.
This seems to be error while fetching the repository from the internal google repos. Is it?
If yes, why is this and how can i make sure that this doesn't happen
again.
If no, then what is it and how do i solve it?
So this is what happens while deploying to the app engine:
Docker check for Google's repo for the image, as the image file i am using (google/nodejs-runtime) is by google and hosted on Google as well (i guess).
Check for any updates to the docker image and update the image file, this is necessary to always push updated versions to the deployment.
Pull changes and push the image to App Engine server and check if the app is serving.
While my assumption was that the issue was in docker registry on Google's end, it was not so.
So there were actually two issues which were causing the issue:
Primary issue (as mentioned in question's comments by #John-Lowry):
It was of the error was DNS name resolution to connect to the docker servers. This was due to my ISP's DNS issue which was blocking access to the servers. Resolved when changed ISP and also resolved after some time on the ISP #1.
Secondary issue (Not sure if exactly related):
Once i switched ISP the following error occurred
google.appengine.tools.docker.containers.ImageError: Image with tag google/docker-registry was not found
This was resolved once i updated the image from the server. Similar Question And finally the updated app was pushed to the servers.
I am not sure why the error occurred, but this is what i assessed:
The docker registry image (google/docker-registry) was updated at some point before the deployment. While deployment, the checks were performed for the image in use (google/nodejs-runtime) but since nodejs-runtime is dependent on docker-registry (i am guessing for maintaining various access policies), it was necessary to update to the newer image.
Please suggest edits.
I have a Worker Role which isn´t working on Cloud environment.
When I run it locally, it runs perfectly, but, when I deploy it to Azure I´m having some troubles. The deploy, itself, occurs seamlessy, after the VM starts, my app doesn´t run. There is nothing on Event Log, and, even after I setted up the app to flush all Trace Messages to Azure Table, nothing is wrote there too.
How can I check if my app is really running on the VM? Why my app isn´t working there as it works locally?
Have tried to implement diagnostics on your webrole? This is the best way to find any errors in your code. An other solution is to install sysinternals during startup. Patriek van Dorp has made a nu get package thad adds the sysinternal suite as a plugin for your cloud project.
The best way is to enable RDP and remote into the machine. Then you can look at the processes running and ensure that things are running as you expect. It is odd that there is nothing in the event log if it is failing to run. Does the portal show the deployment as Ready?
Maybe too late, but i had similar issue.When i run it locally, it was running.After deploy did not run anything.Problem was that, i deploying into website,where worker not available.You should deploy into CloudService(there are available both roles) or make Sheduler, which will do request on your page, where process job you needed.In your custom intreval, ofcourse.
BTW sorry about my english ...
Regards