Rashi
Rashi

Reputation: 1176

AppEngine Flex Deployment Failed - flex_await_healthy ... /bin/sh: gunicorn: not found

I tried to build AppEngine Flex instance using custom-runtime, contains

so, while running pip for installing the dependencies got into a warning that I am running pipas root, which is not recommended by pip maintainers even inside a container AFAIK.

so, in order to solve it I made changes to Dockerfile. Added a normal user and granted permissions to the files and created a virtualenv to install the dependencies.

After that, when I tried to run the service locally, the container is working fine, but when I pushed the same to AppEngine Flex environment it got failed showing following error:

ERROR: (gcloud.app.deploy) Error Response: [9] An internal error occurred while processing task /app-engine-flex/flex_await_healthy/flex_await_healthy>2023-12-29T14:42:11.900Z145758.jc.2: /bin/sh: gunicorn: not found

I tried setting the entrypoint in app.yaml file with full path to gunicorn inside virtualenv. This also failed to deploy.

After, installed gunicorn into the system python package. This also failed.

Installing the python dependencies as system packages will resolve the issue. but should I stick with virtualenv or ignore the pip's warning with the flag ?

Dockerfile

FROM python:3.11.7-alpine

RUN apk update
RUN apk add firefox
RUN adduser -h /app -g "" -D appuser
USER appuser
WORKDIR /app
ADD --chown=appuser ./app/requirements.txt /app
RUN python -m venv venv
ENV PATH="/app/venv/bin:$PATH"
RUN pip install -r requirements.txt
ADD --chown=appuser ./app /app/
EXPOSE 8080
ENTRYPOINT /app/venv/bin/gunicorn -b :$PORT main:app

UPDATE:

The error is appearing now regardless of configuration. I have removed virtualenv usage. And reverted the app.yaml and Dockerfile to last successful state, but it got failed showing the same error.

Upvotes: 0

Views: 66

Answers (1)

Rashi
Rashi

Reputation: 1176

I failed to deploy different configuration that is tested locally running in docker container, all of them stopped at the same error message.

After that, I changed the destination version to a new version name. It got deployed successfully. So, it was confirmed that the problem was not related to configuration. I assume, some kind of caching causing the issue at GCP side.

Finally got deployed to original version after removing the running version, and redeployed it. In between I had directed the traffic to a temporary version (it was not necessary in case of staging environment).

Upvotes: 0

Related Questions