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.
Related
I have made a basic todo list React app (PERN stack), and can run it locally on my computer. I have not added any files (docker or web config) aside from a client folder and server(frontend) folder(backend) following this tutorial
Youtube: https://www.youtube.com/watch?v=ldYcgPKEZC8
Github code: https://github.com/ousecTic/pern-todo-app
I am now uploading this application onto an Azure Web app, via a GitHub repository linked onto VS code. Deployment goes fine, but the site does not run properly.
Here are the errors I am receiving from Azure's end
enter image description here
enter image description here
What node modules or other things could I be missing?
Thanks
The issue to my problem turned out to be that I was uploading my front end and back end at the same time, only uploading my front end worked. Also found in my case that deploying directly is more reliable than deploying via a connection on Github.
I have an App Engine Service, running on Google Cloud Platform.
I run an old version of my NodeJS application on it.
After having updated my code, I have run the following command: gcloud app deploy, in my GCP console, directly. It shows no error.
It says 'X files updated' and after that, I go on my application and the code is actually not updated.
I expect my code to be deployed and therefore, updated, after I run this command.
Why is this expectation not met?
Are you sure you are deploying to the same version? If you're deploying a different version, did you migrate traffic to this new version? To check this, login to console.cloud.google.com > App Engine > Versions
This will show you all the versions you currently have deployed and you can confirm which one(s) are serving traffic
You should also confirm that you actually have the 'updated' source code deployed. Following the link in bullet 1 above, you should see a column that says 'Diagnose' with 'TOOLS' under it. Click on the drop down and select 'source'. This will show you your source code. Confirm you have your updated code
If your files are static, they could be cached. You can try using cache bursting techniques (search Stackoverflow for this), or wait for some time and try again.
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.
I have created my own Docker image using following Dockerfile:-
FROM open-liberty:webProfile8
COPY mysample.war /config/dropins/
COPY server.xml /config/
Docker image got generated with some warning:-
Successfully built cc05c3d94adf Successfully tagged
sampleopenlibty:latest SECURITY WARNING: You are building a Docker
image from Windows against a non-Windows Docker host. All files and
directories added to build context will have '-rwxr-xr-x' permissions.
It is recommended to double check and reset permissions for sensitive files and directories.
I pushed this image to Azure Container Repository and created an App Service out of it but whenever I browse to the Web-App instead of showing my custom/sample web app it shows the out of the box PAGE of Open Liberty.
Can someone please help me what I would have done wrong to fix this issue?
Thank you
I just summarize your comment and post it as an answer.
It was related to the Database connectivity which is in the sample WAR file. We defined some Application settings (Env. vriables) but somehow they are not getting picked up by the app hosted in Docker image. After hard coding it in the code and deployng it everything works.
So now it boils down to fixing the Application settings (Env. varible) to get it all working.
use COPY --chown=1001:0 mysample.war /config/dropins/
to know more open-liberty-docker-docs read Updating file permissions
I am trying to deploy an application to the Azure Service Fabric using the release definition task. When it gets to the task to deploy the server is returning the following error:
The type initializer for 'Microsoft.ServiceFabric.Powershell.Constants' threw an exception
I checked the Endpoint configuration and it appears to be set up as it is supposed to be:
No Authentication (this is an internal text box)
Cluster endpoint: tcp://[service fabric server]:19000
It downloads the artifacts without a problem, but in deploy it searches for the paths for publish profile and application package and finds them. After it finds them it throws the error. I have tried replacing TCP in the endpoint with http, added and removed the :19000 as well and all I get is this error. I have been searching online with little success. Any help to this end is much appreciated.
John
After lots of researching trying every suggestion I could find, we decided try and connect to the machine via Powershell on the box and it too was returning this error. So we uninstalled the SDK and re-installed it and the connection could be made and the builds started to work. I don't know exactly why it failed, but apparently a re-install did the trick. It may have been a bad install, or it could have been a versioning problem. Either way, try a re-install first.