Ermöglichen Sie die schnelle Ausführung von Python-Skripten in Cloud Run mithilfe des Responders

Zusammenfassung

Cloud Run war GA. Ich wollte ein Python-Skript ausprobieren, das früher lokal ausgeführt wurde, und etwas Zeit für die Ausführung in Cloud Run benötigen. In Cloud Run ausgeführte Container müssen in der Lage sein, Anforderungen über HTTP zu empfangen und auszuführen. Cloud Run muss auch Anforderungszeitlimits berücksichtigen. Ich werde den Responder vorstellen, da es einfach war, das Skript schnell auszuführen, ohne das Zeitlimit für die Anforderung zu berücksichtigen.

Prämissengeschichte

Versuchte Umgebung

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

responder

Das HTTP-Service-Framework von Python. Da es ASGI (Asynchronous Server Gateway Interface) implementiert, kann es auch eine asynchrone Verarbeitung durchführen, wie der Name Asynchronous impliziert. Die asynchrone Verarbeitung selbst kann mit anderen Frameworks durchgeführt werden. Als ich mir jedoch kurz Flask und Django ansah, die für das Python-Framework bekannt sind, musste ich zusätzliche Pakete installieren und die Konfigurationsdatei ändern. Mit Blick auf den Beispielcode des Responders schien es einfach zu installieren und zu implementieren, also habe ich versucht, ihn zu verwenden.

Was ich getan habe

Informationen zur Verzeichnisstruktur und zu jeder Datei

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

Jede Python-Datei führt Folgendes aus:

• sample.py: Der Hauptprozess, den Sie ausführen möchten
• webapp.py: Prozess zum Akzeptieren von HTTP-Anforderungen

Dies ist alles require.txt.

responder==2.0.4

Aktualisieren Sie in der Docker-Datei das Paket mit apt und installieren Sie das in den Anforderungen.txt beschriebene Paket.

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

Verarbeitung zum Akzeptieren von HTTP-Anforderungen mithilfe des Responders. Stellen Sie "def" einfach "async" voran und die Funktion ist asynchron.

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()

Das Protokoll wird ausgegeben, da es zur Laufzeit mit Croud Run bestätigt werden kann. Wie der Routenname andeutet, wird beim Zugriff auf den Root-Pfad / Async eine asynchrone Verarbeitung ausgeführt, und beim Zugriff auf den Root-Pfad / die Synchronisierung wird die Motivationsverarbeitung ausgeführt. Dieses Mal habe ich versucht, für den Wert des Abfrageparameters zu schlafen.

sample.py

import time
import logging

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

Bestätigung des Ausführungsergebnisses in Cloud Run

Stellen Sie nun das Zeitlimit für Cloud Run-Anforderungen auf 30 Sekunden ein und führen Sie es aus. (Da das Warten auf 5 Minuten mühsam ist, habe ich den Standardwert geändert.)

** Synchrone Ausführung: Ausführungszeit 10 Sekunden **

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)$

→ Normal fertig

** Synchrone Ausführung: Ausführungszeit 40 Sekunden **

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)$

→ Zeitüberschreitung

** Asynchrone Ausführung: Ausführungszeit 10 Sekunden **

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)$

→ Normal beendet

** Asynchrone Ausführung: Ausführungszeit 40 Sekunden **

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)$

→ Normal fertig

Was ich übrigens bestätigt habe

Übrigens betrug das Zeitlimit für HTTP-Anforderungen auf dem Einstellungsbildschirm bis zu 900 Sekunden, dies ist jedoch nicht die Ausführungszeit Es ist die Zeit, die benötigt wird, um eine Anfrage zu empfangen und eine Antwort zurückzugeben, und ich konnte bestätigen, dass dies 900 Sekunden oder länger möglich ist, wenn es asynchron gemacht wird. Das Folgende ist das Ergebnis einer asynchronen Ausführung für 1200 Sekunden.

Schließlich

• Einführung in die einfache Implementierung der asynchronen Verarbeitung mithilfe des Responders.
• Ich denke, es kann verwendet werden, wenn Sie ein Batch-Python-Skript ausführen möchten, das mit Cloud Run lange dauert.
• Cloud Run wird nach der Verarbeitungszeit berechnet, nicht nach der HTTP-Antwortzeit, wie auf der Preisseite angegeben. Bitte beachten Sie, dass selbst wenn es asynchron ist, der Zeitpunkt, zu dem der Prozess ausgeführt wird, für diesen Betrag berechnet wird.