search

apollographql / router

A configurable, high-performance routing runtime for Apollo Federation 🚀
https://www.apollographql.com/docs/router/
Other
813 stars 271 forks source link

router container image isn't working on GCP Cloud Run #3517

Open garypen opened 1 year ago

garypen commented 1 year ago

The issue has been reported as:

"/usr/bin/env: 'bash ': No such file or directory"

which is quite unusual since the error message implies that the root a/c doesn’t have bash in the PATH...

The problem appears to be confined to GCP Cloud run, since the container executes fine in other environments (docker, k8s, etc...)

abernix commented 1 year ago

Google Cloud Run doesn't let you run from a non-GCP registry, but I was able to reproduce this relatively simply by:

  1. Setting up a Google Cloud Platform environment. My existing one happens to be called burner-gateway. (Don't ask. 🙉 )

  2. Running:

    gcloud auth configure-docker
docker pull ghcr.io/apollographql/router:v1.26.0
docker tag ghcr.io/apollographql/router:v1.26.0 gcr.io/burner-gateway/router:v1.26.0
docker push  gcr.io/burner-gateway/router:v1.26.0
gcloud run deploy router-run-jesse --image gcr.io/burner-gateway/router:v1.26.0

  3. Following the output until it fails and provides a link to the logs, which shows exactly this error.

jesse-apollo commented 8 months ago

This is still a problem with Cloud Run. A workaround is to run gcloud run deploy with the --command=/dist/router.

abernix commented 8 months ago

Any idea what's wrong, @jesse-apollo? This feels like it must be something silly something is doing.

jesse-apollo commented 8 months ago

I'm not entirely sure. I'm guessing the gVisor runtime sandbox is executing the container in such a way that /usr/bin/env doesn't have the appropriate path to locate bash.

However, I see using a shebang of #!/usr/bin/env bash as unnecessary in this situation. This style of shell script shebang is really only used to increase cross-portability of shell scripts across various linux/*nix OSes which might have weird interpreter paths. In a container this is not the case. The filesystem is immutable and well defined. I suggest we change the entrypoint script to use a normal shebang of #!/bin/bash.