Autoriser l'exécution rapide des scripts Python dans Cloud Run à l'aide du répondeur

Résumé

Cloud Run a été diffusé en GA. Je voulais essayer un script python qui s'exécutait en local et prenait un peu de temps à s'exécuter dans Cloud Run. Les conteneurs exécutés dans Cloud Run doivent pouvoir recevoir et exécuter des requêtes via HTTP. Cloud Run doit également prendre en compte les délais d'expiration des demandes. Je vais vous présenter le répondeur car il était facile d'exécuter le script rapidement sans tenir compte du délai d'expiration de la requête.

Histoire de prémisse

Environnement éprouvé

• OS: Mac OS 10.14.6
• docker desktop community: 2.1.0.5
• docker image: python:3.7.5-buster

responder

le cadre de service HTTP de python. Puisqu'il implémente ASGI (Asynchronous Server Gateway Interface), il peut également effectuer un traitement asynchrone comme l'indique le nom Asynchronous. Le traitement asynchrone lui-même peut être effectué avec d'autres frameworks. Cependant, lorsque j'ai jeté un coup d'œil rapide à Flask et Django, qui sont célèbres pour le framework python, j'ai dû installer des packages supplémentaires et modifier le fichier de configuration. En regardant l'exemple de code du répondeur, il semblait facile à installer et à implémenter, j'ai donc essayé de l'utiliser.

Ce que j'ai fait

À propos de la structure des répertoires et de chaque fichier

vaivailx@MacBook-Pro-2 responder_sample_for_cloudrun % tree -L 3 .
.
├── Dockerfile
├── requirements.txt
└── src
    ├── sample.py
    └── webapp.py

Chaque fichier python effectue les opérations suivantes:

• sample.py: le processus principal que vous souhaitez effectuer
• webapp.py: Processus d'acceptation des requêtes HTTP

C'est tout le fichier requirements.txt.

responder==2.0.4

Dans le Dockerfile, mettez à jour le package avec apt et installez le package décrit dans requirements.txt.

FROM python:3.7.5-buster

ENV APP_HOME /app
WORKDIR $APP_HOME
ADD ./requirements.txt /app
ADD ./src /app

# Avoid warnings by switching to noninteractive
ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update \
    && apt-get -y install --no-install-recommends apt-utils dialog 2>&1 \
    # Install pylint
    && pip --disable-pip-version-check --no-cache-dir install pylint \
    # Update Python environment based on requirements.txt
    && pip --disable-pip-version-check --no-cache-dir install -r requirements.txt \
    && rm -rf requirements.txt \
    # Clean up
    && apt-get autoremove -y \
    && apt-get clean -y \
    && rm -rf /var/lib/apt/lists/*

# Switch back to dialog for any ad-hoc use of apt-get
ENV DEBIAN_FRONTEND=

# run app
ENV PORT '8080'
CMD python3 webapp.py
EXPOSE 8080

Traitement pour accepter les requêtes HTTP à l'aide du répondeur. Préfixez simplement def avec ʻasync` et la fonction sera asynchrone.

webapp.py

import logging

import responder

from sample import process_sample

logging.basicConfig(filename=f'/var/log/webapp.log', level=logging.DEBUG)

api = responder.API()

@api.route("/async")
async def asyncsample(req, resp):

    @api.background.task
    def process_param(params):
        t = int(params.get('time', 10))
        process_sample(t)

    process_param(req.params)
    resp.media = {'async success': True}

@api.route("/sync")
def syncsample(req, resp):

    t = int(req.params.get('time', 10))
    process_sample(t)
    resp.media = {'sync success': True}

if __name__ == '__main__':
    api.run()

Le journal est généré car il peut être confirmé au moment de l'exécution avec Croud Run. Comme le nom de la route l'indique, accéder au chemin racine / asynchrone exécutera un traitement asynchrone, et accéder au chemin racine / sync exécutera le traitement de motivation. Cette fois, j'ai essayé de dormir pour la valeur du paramètre de requête.

sample.py

import time
import logging

def process_sample(secs):
    logging.debug('process starts.')
    time.sleep(secs)
    logging.debug('process ends.')

Confirmation du résultat de l'exécution dans Cloud Run

Maintenant, définissons le délai d'expiration de la requête Cloud Run sur 30 secondes et exécutons-le. (Comme attendre 5 minutes est gênant, je l'ai changé par rapport à la valeur par défaut.)

** Exécution synchrone: temps d'exécution 10 secondes **

vaivailx@cloudshell:~ (cloudrun-test-259804)$ date;curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://responderasync-jpwo3ltkhq-an.a.run.app/sync?time=10
Fri Dec 13 09:52:59 +09 2019
{"sync success": true}vaivailx@cloudshell:~ (cloudrun-test-259804)$

→ Terminé normalement

** Exécution synchrone: temps d'exécution 40 secondes **

vaivailx@cloudshell:~ (cloudrun-test-259804)$ date;curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://responderasync-jpwo3ltkhq-an.a.run.
app/sync?time=40
Fri Dec 13 09:55:45 +09 2019
upstream request timeoutvaivailx@cloudshell:~ (cloudrun-test-259804)$

→ Délai d'expiration

** Exécution asynchrone: temps d'exécution 10 secondes **

vaivailx@cloudshell:~ (cloudrun-test-259804)$ date;curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://responderasync-jpwo3ltkhq-an.a.run.app/async?time=10
Fri Dec 13 10:02:31 +09 2019
{"async success": true}vaivailx@cloudshell:~ (cloudrun-test-259804)$

→ Terminé normalement

** Exécution asynchrone: temps d'exécution 40 secondes **

vaivailx@cloudshell:~ (cloudrun-test-259804)$ date;curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://responderasync-jpwo3ltkhq-an.a.run.app/async?time=40
Fri Dec 13 10:03:57 +09 2019
{"async success": true}vaivailx@cloudshell:~ (cloudrun-test-259804)$

→ Terminé normalement

Ce que j'ai confirmé en passant

À propos, le délai d'expiration de la requête HTTP était jusqu'à 900 secondes sur l'écran de réglage, mais ce n'est pas le temps d'exécution C'est le temps qu'il faut pour recevoir une demande et renvoyer une réponse, et j'ai pu confirmer que cela peut être fait pendant 900 secondes ou plus s'il est rendu asynchrone. Ce qui suit est le résultat d'une exécution asynchrone pendant 1 200 secondes.

finalement

• Présentation de la façon dont vous pouvez facilement implémenter le traitement asynchrone en utilisant le responder.
• Je pense qu'il peut être utilisé lorsque vous souhaitez exécuter un script python par lots qui prend beaucoup de temps avec Cloud Run.
• Cloud Run est facturé en fonction du temps de traitement, et non du temps de réponse HTTP, comme indiqué sur la page Prix. Veuillez noter que même s'il est asynchrone, l'heure à laquelle le processus est exécuté sera facturée pour ce montant.