1

I am deploying my Spring Boot application as a compiled jar file running in a docker container deployed to gcp, and deploys it through gcloud cli in my pipeline:

gcloud beta run deploy $SERVICE_NAME --image $IMAGE_NAME --region europe-north1 --project

Which will work and give me the correct response when the application succeeds to start. However, when there's an error and the application fails to start:

Cloud Run error: The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable.

The next time the pipeline runs (with the errors fixed), the gcloud beta run deploy command fails and gives the same error as seen above. While the actual application runs without issues in Cloud Run. How can I solve this?

Currently I have to check Cloud Run manually as I cannot trust my pipeline, and I have to run it twice to make it succeed. Any help will be appreciated. Let me know if you want any extra information.

Carl Smestad
  • 119
  • 7
  • To confirm: if you have an existing, failing Cloud Run service deployment, when you redeploy (the same command `gcloud run deploy ...`), `gcloud` reports that the container failed to start even though it didn't? I think I've observed this behavior too but in a very specific configuration where I disregarded it. It may be interesting to add `--log-http` or `--verbosity=debug` to see whether `gcloud` or the service response is incorrect. – DazWilkin Jul 26 '22 at 20:44
  • 1
    Also note that [`gcloud beta run services replace`](https://cloud.google.com/sdk/gcloud/reference/beta/run/services/replace) now exists. This is akin to `kubectl apply` and permits applying knative `YAML` to the service rather than `gcloud`-eseque configs. This **may** also result in different behavior. It's unclear whether it exists as an alternative or replacement for `gcloud run deploy` – DazWilkin Jul 26 '22 at 20:46
  • 1
    SOmething is cooking. Stay tuned ;) – guillaume blaquiere Jul 26 '22 at 21:21
  • 1
    1) How long is your container taking to startup? You want that to be seconds. Do not configure a container (download packages, large files, etc) during cold start. 2) You cannot delay the health check. 3) Use the Cloud Run logs to measure cold startup time. – John Hanley Jul 27 '22 at 00:19
  • @DazWilkin. That's right! I will check if the added logging provides any useful information and also check out services replace. Thank you for the reply! – Carl Smestad Jul 27 '22 at 07:07
  • @JohnHanley The container startsup within seconds, but the application uses about 20-30s before the tomcat server exposes the port which I imagine Cloud Run uses as a health check. – Carl Smestad Jul 27 '22 at 07:09
  • It does not matter how fast the container starts, it is the total time until the container is ready to serve requests that matters. However, 20 seconds is OK, but it should be shorter. Therefore if the total time is 20 seconds, that is not causing the error message. – John Hanley Jul 27 '22 at 09:08
  • In the meantime, a new opportunity has emerged here: https://cloud.google.com/blog/products/serverless/cloud-run-healthchecks and https://cloud.google.com/run/docs/configuring/healthchecks – Ben Apr 14 '23 at 15:18

0 Answers0