Siguiendo el tutorial aquí tengo los siguientes 2 archivos:
from flask import Flask, request app = Flask(__name__) @app.route('/', methods=['GET']) def hello(): """Return a friendly HTTP greeting.""" who = request.args.get('who', 'World') return f'Hello {who}!\n' if __name__ == '__main__': # Used when running locally only. When deploying to Cloud Run, # a webserver process such as Gunicorn will serve the app. app.run(host='localhost', port=8080, debug=True) # Use an official lightweight Python image. # https://hub.docker.com/_/python FROM python:3.7-slim # Install production dependencies. RUN pip install Flask gunicorn # Copy local code to the container image. WORKDIR /app COPY . . # Service must listen to $PORT environment variable. # This default value facilitates local development. ENV PORT 8080 # Run the web service on container startup. Here we use the gunicorn # webserver, with one worker process and 8 threads. # For environments with multiple CPU cores, increase the number of workers # to be equal to the cores available. CMD exec gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 app:appLuego los construyo y ejecuto usando Cloud Build y Cloud Run:
PROJECT_ID=$(gcloud config get-value project) DOCKER_IMG="gcr.io/$PROJECT_ID/helloworld-python" gcloud builds submit --tag $DOCKER_IMG gcloud run deploy --image $DOCKER_IMG --platform managedEl código parece funcionar bien y puedo acceder a la aplicación en la URL dada. Sin embargo, los registros parecen indicar un error crítico y los trabajadores siguen reiniciando. Aquí está el archivo de registro de Cloud Run después de iniciar la aplicación y realizar algunas solicitudes en mi navegador web:
2020-03-05T03:37:39.392Z Cloud Run CreateService helloworld-python ... 2020-03-05T03:38:03.285477Z[2020-03-05 03:38:03 +0000] [1] [INFO] Starting gunicorn 20.0.4 2020-03-05T03:38:03.287294Z[2020-03-05 03:38:03 +0000] [1] [INFO] Listening at: http://0.0.0.0:8080 (1) 2020-03-05T03:38:03.287362Z[2020-03-05 03:38:03 +0000] [1] [INFO] Using worker: threads 2020-03-05T03:38:03.318392Z[2020-03-05 03:38:03 +0000] [4] [INFO] Booting worker with pid: 4 2020-03-05T03:38:15.057898Z[2020-03-05 03:38:15 +0000] [1] [INFO] Starting gunicorn 20.0.4 2020-03-05T03:38:15.059571Z[2020-03-05 03:38:15 +0000] [1] [INFO] Listening at: http://0.0.0.0:8080 (1) 2020-03-05T03:38:15.059609Z[2020-03-05 03:38:15 +0000] [1] [INFO] Using worker: threads 2020-03-05T03:38:15.099443Z[2020-03-05 03:38:15 +0000] [4] [INFO] Booting worker with pid: 4 2020-03-05T03:38:16.320286ZGET200 297 B 2.9 s Safari 13 https://helloworld-python-xhd7w5igiq-ue.a.run.app/ 2020-03-05T03:38:16.489044ZGET404 508 B 6 ms Safari 13 https://helloworld-python-xhd7w5igiq-ue.a.run.app/favicon.ico 2020-03-05T03:38:21.575528ZGET200 288 B 6 ms Safari 13 https://helloworld-python-xhd7w5igiq-ue.a.run.app/ 2020-03-05T03:38:27.000761ZGET200 285 B 5 ms Safari 13 https://helloworld-python-xhd7w5igiq-ue.a.run.app/?who=me 2020-03-05T03:38:27.347258ZGET404 508 B 13 ms Safari 13 https://helloworld-python-xhd7w5igiq-ue.a.run.app/favicon.ico 2020-03-05T03:38:34.802266Z[2020-03-05 03:38:34 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:4) 2020-03-05T03:38:35.302340Z[2020-03-05 03:38:35 +0000] [4] [INFO] Worker exiting (pid: 4) 2020-03-05T03:38:48.803505Z[2020-03-05 03:38:48 +0000] [5] [INFO] Booting worker with pid: 5 2020-03-05T03:39:10.202062Z[2020-03-05 03:39:09 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:5) 2020-03-05T03:39:10.702339Z[2020-03-05 03:39:10 +0000] [5] [INFO] Worker exiting (pid: 5) 2020-03-05T03:39:18.801194Z[2020-03-05 03:39:18 +0000] [6] [INFO] Booting worker with pid: 6Tenga en cuenta los tiempos de espera y los reinicios de los trabajadores al final de los registros. El hecho de que sea un error CRÍTICO me hace pensar que no debería estar pasando. ¿Es este el comportamiento esperado? ¿Es este un efecto secundario de que la maquinaria de Cloud Run inicie y detenga mi servicio a medida que las solicitudes van y vienen?
Este es un ejemplo práctico de una aplicación Flask en ejecución en la nube. Supongo que su última línea o el archivo Decker y la última parte de su archivo python son los que causan este comportamiento.
principal.py
# main.py #gcloud beta run services replace service.yaml from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): msg = "Hello World" return msgDockerfile (la parte apt-get no es necesaria)
# Use the official Python image. # https://hub.docker.com/_/python FROM python:3.7 # Install manually all the missing libraries RUN apt-get update RUN apt-get install -y gconf-service libasound2 libatk1.0-0 libcairo2 libcups2 libfontconfig1 libgdk-pixbuf2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libxss1 fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils # Install Python dependencies. COPY requirements.txt requirements.txt RUN pip install -r requirements.txt ENV APP_HOME /app WORKDIR $APP_HOME COPY . . CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 main:appluego construye usando:
gcloud builds submit --tag gcr.io/[PROJECT]/[MY_SERVICE]y desplegar:
gcloud beta run deploy [MY_SERVICE] --image gcr.io/[PROJECT]/[MY_SERVICE] --region europe-west1 --platform managedACTUALIZAR He comprobado de nuevo los registros que has proporcionado. Recibir este tipo de advertencia/error es normal al principio después de una nueva implementación, ya que sus instancias anteriores no están manejando ninguna solicitud, sino que están inactivas en ese momento hasta que se apagan por completo.
Gunicorn también tiene un tiempo de espera predeterminado de 30 segundos que coincide con el tiempo entre el momento del "trabajador de arranque" y el momento en que ve el error.
Cloud Run ha reducido una de sus instancias, y el árbitro gunicorn está considerando que se ha estancado.
Debe agregar --timeout 0 a su invocación de gunicorn para deshabilitar el tiempo de espera del trabajador por completo, no es necesario para Cloud Run.
estaba enfrentando el error [11229] [CRITICAL] WORKER TIMEOUT (pid:11232) en heroku, cambié mi Procfile a este
web: gunicorn --workers=3 app:app --timeout 200 --log-file - y arregló mi problema aumentando el tiempo de --timeout