Reputation: 1176
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 pip
as 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 ?
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
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
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