While trying to get Logux running in Cloud Run, I get this error:
Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.
Even though the server is running an the Dockerfile is exposing the correct port (which is mapped in Cloud run as well).
The Dockerfile is located here: https://github.com/knownasilya/battle-chess/blob/main/Dockerfile
Note that the server runs https and ws on port 31337.
As mentioned by the Cloud Run Troubleshooting docs, if we get the message:
Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.
And we know our code/container is working as expected, we should check that the port that that Cloud Run will be checking correlates with the one used in our app and like in this case, that the container listens on 0.0.0.0 (all the net interfaces)
As well this is mentioned in the Cloud Run Requirements doc:
The container must listen for requests on 0.0.0.0 on the port to which requests are sent. By default, requests are sent to 8080, but you can configure Cloud Run to send requests to the port of your choice. Cloud Run injects the PORT environment variable into the container. Inside Cloud Run container instances, the value of the PORT environment variable always reflects the port to which requests are sent. It defaults to 8080.
Related
I am trying to run Julia code in azure container app, but it fails for some reason.
docker file is pretty simple:
FROM julia:1.7-bullseye
COPY . /
EXPOSE 8080
RUN julia --project='/' -e 'using Pkg; Pkg.build()'
ENTRYPOINT julia --project='/' main.jl "0.0.0.0" "8080"
"0.0.0.0" and "8080" there is the host and port on which HTTP is served:
HTTP.serve(GENERAL_ROUTER, host, port_restful_api)
The app supposed to run a simple HTTP server that is served over port 8080, GET to / is the health check that returns simple "Up"
When I run that same image locally with docker run -p 8080:8080 my-test:latest it works fine and hitting localhost:8080 gives me my expected response
But when I have it in container app - revision fails to be provisioned (and no extra errors provided). In the ingress I added availability to accept traffic from anywhere and target port is 8080...
What I am missing?
UPDATE
At the same time in log analytics I can see my output to console that should indicate that the app is supposedly running fine, e.g.
[ Info: API handler service: Running on thread 1
In Julia those are done with
#info "API Server: Running on thread $(Threads.threadid())"
But in logs those are in stderr stream. Could it be that the ACA treats any output to stderr as startup error?
UPDATE 2:
The very same code works without any issues or changes on Azure Container Instance and in Azure Kubernetes Service...
So for now I stopped investigating and decided to use ACI.
You should verify if any process inside the julia image needs root privileges as ACA do not support running privileged containers based on the docs:
Azure Container Apps can't run privileged containers. If your program
attempts to run a process that requires root access, the application
inside the container experiences a runtime error.
Did you specify 8080 as your target port when configuring the HTTP ingress of your Container App? https://learn.microsoft.com/en-us/azure/container-apps/ingress?tabs=bash
The platform will try to ping your app at the specified port due to the default health probes. If it receives no response, it will restart your app: https://learn.microsoft.com/en-us/azure/container-apps/health-probes?tabs=arm-template
I'm trying a simple NextJS server in an Azure AppService, and the container fails to start, even though the logs indicate that NextJS is up and ready to server files. The code works fine locally.
My code is here: https://github.com/CutieDarkFae/Catz
The container log finishes with:
***2020-06-11T08:43:19.032969810Z Extracting modules...
2020-06-11T08:43:44.262867136Z Done.
2020-06-11T08:43:45.328947365Z
2020-06-11T08:43:45.328985465Z > cats#0.1.0 start /home/site/wwwroot
2020-06-11T08:43:45.328992064Z > next start
2020-06-11T08:43:45.328996364Z
2020-06-11T08:43:47.016355156Z ready - started server on http://localhost:3000***
But the AppService logs end with:
2020-06-11T08:46:44.113Z INFO - Waiting for response to warmup request for container catz_0_39a9d511. Elapsed time = 210.9209243 sec
2020-06-11T08:46:59.249Z INFO - Waiting for response to warmup request for container catz_0_39a9d511. Elapsed time = 226.0570954 sec
2020-06-11T08:47:03.323Z ERROR - Container catz_0_39a9d511 for site catz did not start within expected time limit. Elapsed time = 230.1311154 sec
2020-06-11T08:47:03.326Z ERROR - Container catz_0_39a9d511 didn't respond to HTTP pings on port: 8080, failing site start. See container logs for debugging.
2020-06-11T08:47:03.342Z INFO - Stopping site catz because it failed during startup.
How can I get the container to notice that the app is up and running? and not to time out?
Or is an AppService the wrong place to put a NextJS server?
It looks like your app is starting on port 3000 but the App Service is expecting it on port 8080.
Set the app setting WEBSITES_PORT to 3000. https://learn.microsoft.com/en-us/azure/app-service/containers/configure-custom-container
The suggestion here didn't work for me alas, it kept trying on 8080 no matter what :(
What did work is the approved answer here:
unable to deploy next js to azure
I would have preferred a much simpler solution though
As Silent mentioned. Kindly use app setting WEBSITES_PORT to set the port for your own docker image while for blessed images use PORT environment variable as the listening port.
In your application, please use the PORT or WEBSITES_PORT (as applicable) environment variable as the main web server’s listening port, instead of using a hardcoded port number ( on app start-up on locahost:3000). The PORT environment variable is automatically set by App Service platform at startup time.
As mentioned, you could try these ways:
Use the EXPOSE instruction in your Dockerfile to expose port 3000.
Use the WEBSITES_PORT app setting with a value of "3000" to expose that port.
If the issue still persist, just to isolate, you could change the script to - "/home/site/wwwroot/node_modules/next/dist/bin/next start" and change the change the port 80 and see if that helps.
I'm running a node JS app on Google Cloud Services using the cloud shell. I've deployed using gcloud app deploy, everything reports as a success. If I use gcloud app logs tail -s default I can see the logs, it says my app is listening on port 3000, that's the first debug message I see from my app.
When I invoke the endpoint without the port on the end, i.e.
https://myapp.appspot.com/myendpoint
I get an error,
"GET /myendpoint" 502
If I try with port 3000, i.e.
https://myapp.appspot.com:3000/myendpoint
The request just times out and I get no log messages from the shell.
I have port 3000 opened on the firewall, and my app.yaml is,
runtime: nodejs
env: flex
service: default
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
Update 1:
I've also tried adding a forwarding port to my app.yaml,
network:
forwarded_ports:
- 3000/tcp
And allowed port 3000 in the VPC Firewall, but this seems to make no difference.
Update 2:
I can SSH into the instance and access the endpoint using a wget http://127.0.0.1:3000/myendpoint command but still no external access.
Update 3:
I've also tried port 443 too, listening on IP 0.0.0.0. But it seems to bind to IPV6 ip address 0 and changes the port to 8443 (somehow). This is just insane...
I resolved the issue by binding my service to port 8080, and removing the "service" field from my app.yaml. the external calls are all routed to port 8080 by default.
External calls have no port specified.
Running a NodeJS Docker Container on an EC2 instance, I'm trying to remote debug it, but keep getting "connection refused" from the instance.
What I've tried -
Opening ports in EC2 security groups
Exposing ports in Dockerfile, both the port the app is listening on and the debug port
Forwarding the port within the Docker run command using the -p flag
Making sure the app is accessible directly through the port it's configured to listen to
After trying all of these, the debug port is still inaccessible by the remote debugger or even telnet.
Any ideas what could cause this?
I am trying to create a node app that runs a module called noodlejs. This starts its own server running on port 8888 (on my local version). I have pushed the changes to heroku and no errors are caused. However how do I now access the noodlejs server on port 8888? Is this possible or does it need to run on another port?
Thanks!
I don't think you can run the app on port 8888 or any other port for that matter on Heroku. You can only choose between 80 or 443. And to do that, you use process.env.PORT environment variable that Heroku exposes.