Cloud Run error: Container failed to start. Running a background task without exposing a PORT or URL

Question

I am facing the issue

(gcloud.run.deploy) Cloud Run error: Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable. Logs for this revision might contain more information.

There are a few post with this error but I couldn't find my particular case.

I am running a background task, nothing to expose, it connects to firebase process some data and store it back. I wanted this process to run on a container on Cloud Run so I made it a container, which runs perfectly locally, but when uploading it to CR it fails with the above error.

I tried to expose 8080 on dockerfile and a few more things but if you try to connect to they container it has no server running to connect to. It is a batch task.

Can anyone tell me if it is possible at all to upload this type of tasks to Cloud Run, I do not know how to solve the issue. I wouldnt believe google requires a server running on the container to allow it, I saw some posts with dev pulling an nginx on the image so they can expose the port but this would be totally unnecessary in my case.

Thanks for your advice

UPDATE

• Cloud Logging: The error simply say there was a fail to start the container, which is funny because the container starts and also shows some logs like if it were working but then it stops.
• Build on MAC yes.
• DockerFile is pretty simple.

  FROM openjdk:11
  
  ENV NOTIFIER_HOME /opt/app/
  ENV NOTIFIER_LOGS /opt/notifications/logs/
  RUN mkdir -p $NOTIFIER_HOME RUN mkdir -p $NOTIFIER_LOGS
  
  RUN apt update
  #RUN apt install curl
  
  COPY docker/* $NOTIFIER_HOME
  
  EXPOSE 8080
  
  ENV TMP_OPTS -Djava.io.tmpdir=/tmp ENV LOG4j_OPTS
  -Dlog4j.configurationFile=$NOTIFIER_HOME/logback.xml ENV NOTIFIER_OPTS $TMP_OPTS $LOG4j_OPTS
  
  ENV JAVA_GC_OPTS -Xms1g -Xmx1g
  
  WORKDIR $NOTIFIER_HOME ENTRYPOINT ["sh", "-c", "/opt/app/entrypoint.sh"]
  

Answer 1

You can't run background jobs on Cloud Run. Wrap it in a webserver as proposed by MBHA if the process take less than 1h.

Else you can you GKE Autopilot to run your container for a while. you pay only when your container run. And the first cluster is free. You can have a try on it!

As hack you can run your container in Cloud Build also, or in Vertex AI custom container training.

Answer 2

I've run in to a similar issue with building custom image on MAC + deploying in to Cloud Run. In my case, it turned out to be the docker platform causing the problem. The way I isolated this was by building the same image in Cloud Shell and that would work perfectly fine in Cloud Run.

Now, if you need to build it locally on MAC go ahead and test it by changing the Docker platform:

export DOCKER_DEFAULT_PLATFORM=linux/amd64
docker build -t mytag:myver .

Once the image has been built, you can inspect the architecture:

docker image inspect mytag:myver | grep -i Architecture

Then deploy it to Cloud Run.

Answer 3

The explanation is in your question:

I am running a background task, nothing to expose

A cloud run application, so your container, must be listening for incoming HTTP requests as stated in the Container runtime contract. That's why in all cloud run examples, java in your case, spring boot is used with @RestController. Other explanation can be found in this answer.

Update: So the solution is either to

• add a webserver to your code and wrap it with spring boot and controller logic
• use Cloud Function rather than Cloud Run and get rid of the Dockerfile and in the same time have simpler code and less configuration