Auf dieser Seite wird beschrieben, wie Sie einen App Engine-Aufgaben-Handler erstellen. Das ist der Worker-Code, mit dem eine App Engine-Aufgabe verarbeitet wird. Die Cloud Tasks-Warteschlange sendet HTTP-Anfragen an den Aufgaben-Handler. Nach erfolgreicher Verarbeitung muss der Handler einen HTTP-Status zwischen 200
und 299
an die Warteschlange zurücksenden. Jeder andere Wert gibt an, dass die Aufgabe fehlgeschlagen ist und die Warteschlange die Aufgabe wiederholt.
Anfragen der App Engine-Aufgabenwarteschlange werden von der IP-Adresse 0.1.0.2
gesendet.
Weitere Informationen finden Sie unter IP-Bereich für Anfragen, die an die App Engine-Umgebung gesendet werden.
C#
Python
Java
PHP
Einfach loslegen (Go)
Node.js
Ruby
Zeitlimits
Für App Engine-Aufgaben gelten bestimmte Zeitlimits, die vom Skalierungstyp des Dienstes abhängen, der sie ausführt.
Für Worker-Dienste, die in der Standardumgebung ausgeführt werden:
- Automatische Skalierung: Die Verarbeitung der Aufgabe muss in zehn Minuten abgeschlossen sein.
- Manuelle und grundlegende Skalierungsanfragen können bis zu 24 Stunden ausgeführt werden.
Für Worker-Dienste, die in der flexiblen Umgebung ausgeführt werden: Alle Typen haben ein Zeitlimit von 60 Minuten.
Wenn die Frist für den Handler verstrichen ist, geht die Warteschlange davon aus, dass die Aufgabe fehlgeschlagen ist, und wiederholt sie.
App Engine-Aufgabenanfrage-Header lesen
Anfragen, die von einer Cloud Tasks-Warteschlange an Ihren App Engine-Handler gesendet werden, haben spezielle Header mit aufgabenspezifischen Informationen, die der Handler möglicherweise verwenden möchte.
Diese Header werden intern festgelegt. Wenn einer dieser Header in einer externen Nutzeranfrage an Ihre Anwendung vorhanden ist, werden sie durch die internen ersetzt. Eine Ausnahme bilden Anfragen von angemeldeten Administratoren der Anwendung, die Header für Testzwecke festlegen dürfen.
App Engine-Aufgabenanfragen enthalten immer die folgenden Header:
Header | Beschreibung |
---|---|
X-AppEngine-QueueName |
Der Name der Warteschlange. |
X-AppEngine-TaskName |
Der "kurze" Name der Aufgabe oder, wenn bei der Erstellung kein Name festgelegt wurde, eine vom System generierte eindeutige ID. Dies ist der Wert my-task-id im vollständigen Aufgabennamen, z. B. task_name = projects/my-project-id/locations/my-location/queues/my-queue-id/tasks/my-task-id . |
X-AppEngine-TaskRetryCount |
Die Anzahl der Wiederholungsversuche für die Aufgabe. Für den ersten Versuch lautet dieser Wert 0 . Diese Anzahl enthält Versuche, bei denen die Aufgabe aufgrund fehlender verfügbarer Instanzen fehlgeschlagen ist und die Ausführungsphase nicht erreicht wurde. |
X-AppEngine-TaskExecutionCount |
Die Häufigkeit, mit der die Task ausgeführt und eine Antwort vom Handler erhalten hat. Da Cloud Tasks die Aufgabe löscht, nachdem eine erfolgreiche Antwort empfangen wurde, sind alle vorherigen Handler-Antworten Fehler. Für diesen Wert werden Fehler aufgrund fehlender verfügbarer Instanzen nicht berücksichtigt. X-AppEngine-TaskExecutionCount kann gleich X-AppEngine-TaskRetryCount sein, wenn sie vor dem Versuch aktualisiert wird, sie auszuführen. |
X-AppEngine-TaskETA |
Die geplante Zeit für eine Aufgabe, angegeben in Sekunden seit dem 1. Januar 1970. |
Wenn der Anfrage-Handler einen der oben aufgeführten Header ermittelt, ist sicher, dass es sich bei der Anfrage um eine Anfrage von Cloud Tasks handelt.
Außerdem können Anfragen von Cloud Tasks die folgenden Header enthalten:
Header | Beschreibung |
---|---|
X-AppEngine-TaskPreviousResponse |
Der HTTP-Antwortcode aus der vorangegangenen Wiederholung. |
X-AppEngine-TaskRetryReason |
Der Grund für die Wiederholung der Aufgabe. |
X-AppEngine-FailFast |
Zeigt an, dass eine Aufgabe sofort fehlschlägt, wenn eine vorhandene Instanz nicht verfügbar ist. |
Ziel-Routing
Bei App Engine-Aufgaben werden die Warteschlange und der Aufgaben-Handler im selben Google Cloud-Projekt ausgeführt. Der Traffic wird während der Übertragung verschlüsselt und verlässt niemals Google-Rechenzentren. Sie können das Protokoll (z. B. HTTP oder HTTPS) nicht explizit festlegen. Es erscheint jedoch so, als hätte die Anfrage an den Handler das HTTP-Protokoll verwendet.
Aufgaben können an sichere und unsichere Aufgaben-Handler sowie in unterstützten Laufzeiten an URIs mit der Einschränkung login: admin
weitergeleitet werden.
Da Aufgaben nicht im Namen von Nutzern ausgeführt werden, können sie nicht an URIs weitergeleitet werden, die durch login: required
eingeschränkt sind.
Auch folgen Aufgabenweiterleitungen nicht den sonstigen Weiterleitungen.
Nächste Schritte
- Weitere Informationen zu Aufgaben in der RPC-API-Referenz
- Weitere Informationen zu Aufgaben finden Sie in der Referenz zur REST API.