Diese Seite wurde von der Cloud Translation API übersetzt.

Push-Warteschlangen zu Cloud Tasks migrieren (Python)

Auf dieser Seite wird beschrieben, wie Sie Push-Warteschlangencode von Aufgabenwarteschlangen zu Cloud Tasks migrieren können. Cloud Tasks ist jetzt die bevorzugte Methode für die Arbeit mit App Engine-Push-Warteschlangen.

Mit Cloud Tasks greifen Sie auf denselben Dienst zu wie mit der Task Queues RPC API. Das bedeutet, dass Sie Ihre bestehenden Push-Warteschlangen und Push-Aufgaben nicht neu erstellen müssen. Sie müssen jedoch Code migrieren, der Push-Warteschlangen oder Push-Aufgaben erstellt oder damit interagiert, um die Cloud Tasks API zu verwenden.

Sie können Push-Warteschlangen und Push-Aufgaben mit der Cloud Tasks REST API, der Cloud Tasks RPC API, der Cloud Tasks-Clientbibliothek, dem Google Cloud CLI und der Google Cloud Console erstellen und damit interagieren. Auf dieser Seite finden Sie Beispiele mit der gcloud CLI und der Cloud Tasks-Clientbibliothek.

In Cloud Tasks arbeiten alle Warteschlangen als Push-Warteschlangen. Im Rest dieses Anleitung und in der Cloud Tasks-Dokumentation entspricht der Begriff Warteschlange dem Begriff Push-Warteschlange. Ebenso entspricht der Begriff Aufgabe dem Begriff Push-Aufgabe.

Funktionen, die in Cloud Tasks nicht verfügbar sind

Die folgenden Features sind in Cloud Tasks nicht verfügbar:

Warteschlange für Aufgaben in Datenspeichertransaktionen
Bibliothek für zurückgestellte Aufgaben anstelle eines Worker-Dienstes verwenden
Mit Aufgaben in Anwendungen mit mehreren Mandanten arbeiten
Mit dem lokalen Entwicklungsserver simulieren
Aufgaben asynchron hinzufügen

Preise und Kontingente

Die Migration von Push-Warteschlangen zu Cloud Tasks kann sich auf die Preise und Kontingente für Ihre Anwendung auswirken.

Preise

Für Cloud Tasks gelten eigene Preise. Wie bei Aufgabenwarteschlangen kann das Senden von Anfragen an Ihre App Engine-Anwendung mit einer Aufgabe dazu führen, dass die Anwendung Kosten verursacht.

Kontingente

Die Kontingente für Cloud Tasks unterscheiden sich von den Kontingenten für Aufgabenwarteschlangen. Wie bei Aufgabenwarteschlangen kann das Senden von Anfragen von Cloud Tasks an die App Engine-Anwendung Auswirkungen auf Ihre Anfragekontingente für App Engine haben.

Vor der Migration

Richten Sie die Python-Entwicklungsumgebung ein, falls Sie dies noch nicht getan haben, um eine mit Google Cloud kompatible Python-Version zu verwenden, und installieren Sie Testtools, um isoliertes Python zu erstellen. Umgebungen.

In folgenden Abschnitten werden die Einrichtungsschritte erläutert, bevor Sie Ihre Push-Warteschlangen zu Cloud Tasks migrieren.

Pull-Warteschlangen migrieren

Migrieren Sie Pull-Warteschlangen, bevor Sie der Anleitung zum Migrieren von Push-Warteschlangen folgen. Die Migration von Pull-Warteschlangen nach der Migration von Push-Warteschlangen wird nicht empfohlen, da die erforderliche Verwendung der Datei queue.yaml wahrscheinlich ein unerwartetes Verhalten bei Cloud Tasks verursacht.

Warteschlangenkonfiguration schützen

Wenn Sie mit der Migration zu Cloud Tasks beginnen, kann das Ändern der Datei queue.yaml zu unerwartetem Verhalten führen und wird nicht empfohlen. So können Sie Ihre Warteschlangenkonfiguration vor Änderungen durch die Datei queue.yaml schützen:

Konfigurieren Sie die gcloud CLI, um die queue.yaml-Datei in zukünftigen Bereitstellungen auszulassen.

Fügen Sie die Datei queue.yaml zu einer Datei .gcloudignore hinzu. Um zu prüfen, ob Sie bereits eine Datei .gcloudignore haben, können Sie den folgenden Befehl in Ihrem Terminal aus dem Verzeichnis der obersten Ebene Ihrer Anwendung ausführen. Dieser Befehl gibt den Dateinamen aus, wenn die Datei vorhanden ist.
```
ls -a | grep .gcloudignore
```
Weitere Informationen zu .gcloudignore-Dateien finden Sie in der .gcloudignore-Referenz.
Schränken Sie die Berechtigungen für die Datei queue.yaml ein.

Wenden Sie die Best Practices an, die in der Anleitung zum Sichern der Warteschlangenkonfiguration beschrieben sind.
Weitere Informationen zu Cloud Tasks und der Datei queue.yaml (optional)

Wenn Sie die Warteschlangenkonfiguration mit der Cloud Tasks API verwalten, überschreibt die Bereitstellung einer Datei queue.yaml die von Cloud Tasks festgelegte Konfiguration, was zu unerwartetem Verhalten führen kann. Lesen Sie Warteschlangenverwaltung im Vergleich zu queue.yaml, um weitere Informationen zu erhalten.

Cloud Tasks API aktivieren

Um die Cloud Tasks API zu aktivieren, klicken Sie bei der Cloud Tasks API in der API-Bibliothek auf Aktivieren. Wenn anstelle der Schaltfläche Aktivieren die Schaltfläche Verwalten angezeigt wird, haben Sie die Cloud Tasks API bereits für Ihr Projekt aktiviert und müssen dies nicht noch einmal tun.

Anwendung bei der Cloud Tasks API authentifizieren

Sie müssen Ihre Anwendung für die Cloud Tasks API authentifizieren. In diesem Abschnitt wird die Authentifizierung für zwei verschiedene Anwendungsfälle erläutert.

Wenn Sie Ihre Anwendung lokal entwickeln oder testen möchten, empfehlen wir die Verwendung eines Dienstkontos. Anleitungen zum Einrichten eines Dienstkontos und zum Verknüpfen des Dienstkontos mit Ihrer Anwendung finden Sie unter Dienstkonto-Anmeldedaten manuell abrufen und bereitstellen.

Zur Bereitstellung Ihrer Anwendung in App Engine müssen Sie keine neue Authentifizierung bereitstellen. Die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) leiten die Authentifizierungsdetails für App Engine-Anwendungen ab.

gcloud CLI herunterladen

Laden Sie die gcloud CLI herunter und installieren Sie sie, um die gcloud CLI mit der Cloud Tasks API zu verwenden, falls Sie sie noch nicht installiert haben. Führen Sie folgenden Befehl über Ihr Terminal aus, wenn Sie die gcloud CLI bereits installiert haben.

gcloud components update

Cloud-Clientbibliotheken importieren

So verwenden Sie die Cloud Tasks-Clientbibliothek mit Ihrer App Engine-Anwendung:

Aktualisieren Sie die Datei app.yaml. Folgen Sie der Anleitung für Ihre Python-Version:
Python 2
Fügen Sie für Python 2-Anwendungen die neuesten Versionen der Bibliotheken grpcio und setuptools hinzu.

Hier sehen Sie eine app.yaml-Beispieldatei:
```
runtime: python27
threadsafe: yes
api_version: 1

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest
```
Python 3
Geben Sie für Python 3-Anwendungen das runtime-Element in Ihrer app.yaml-Datei mit einer unterstützten Python 3-Version an. Beispiele:
```
runtime: python310 # or another support version
```
Die Python 3-Laufzeit installiert Bibliotheken automatisch. Sie müssen also keine integrierten Bibliotheken aus der vorherigen Python 2-Laufzeit angeben. Wenn Ihre Python 3-Anwendung bei der Migration andere gebündelte Legacy-Dienste verwendet, können Sie weiter die erforderlichen integrierten Bibliotheken angeben. Andernfalls können Sie die unnötigen Zeilen in der app.yaml-Datei löschen.
Aktualisieren Sie die Datei requirements.txt. Folgen Sie der Anleitung für Ihre Python-Version:
Python 2
Fügen Sie die Cloud-Clientbibliotheken für Cloud Tasks der Liste der Abhängigkeiten in der requirements.txt-Datei hinzu.
```
google-cloud-tasks
```
Führen Sie dann pip install -t lib -r requirements.txt aus, um die Liste der verfügbaren Bibliotheken für Ihre Anwendung zu aktualisieren.
Python 3
Fügen Sie die Cloud-Clientbibliotheken für Cloud Tasks der Liste der Abhängigkeiten in der requirements.txt-Datei hinzu.
```
google-cloud-tasks
```
App Engine installiert diese Abhängigkeiten während der Anwendungsbereitstellung in der Python 3-Laufzeit automatisch. Löschen Sie daher den Ordner lib, falls vorhanden.
Wenn Ihre Anwendung in Python 2-Anwendungen integrierte oder kopierte Bibliotheken verwendet, müssen Sie diese Pfade in der appengine_config.py-Datei angeben, die sich im selben Ordner wie die app.yaml-Datei befindet:
```
import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)
```
Die Datei appengine_config.py geht davon aus, dass sich der Ordner lib im aktuellen Arbeitsverzeichnis befindet. Das aktuelle Arbeitsverzeichnis kann jedoch, wie bei Einheitentests, abweichen. Sie können Fehler vermeiden und den vollständigen Pfad zum Ordner lib wie dargestellt explizit eingeben:
```
import os
path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
```
Importieren Sie die Cloud Tasks-Clientbibliothek in alle Dateien, die Push-Warteschlangen aus der Task Queues API verwenden:
```
from google.cloud import tasks
```
Nach Abschluss der vollständigen Migration Ihres gesamten Codes, der Push-Warteschlangen erstellt oder mit Cloud Tasks interagiert, entfernen Sie die Anweisungen zum Importieren der Task Queues API, z. B. from google.appengine.api import taskqueue.

Warteschlangen erstellen und verwalten

In diesem Abschnitt wird beschrieben, wie Sie Warteschlangen mit der Cloud Tasks API erstellen und verwalten.

Mit Cloud Tasks erstellen Sie keine queue.yaml-Datei und verwalten keine Warteschlangen. Stattdessen verwenden Sie die Cloud Tasks API. Die Verwendung einer Datei queue.yaml und der Cloud Tasks API wird nicht empfohlen, kann jedoch je nach Anwendung ein unvermeidlicher Teil der Migration von Aufgabenwarteschlangen zu Cloud Tasks sein. Weitere Informationen zu Best Practices finden Sie unter Warteschlangenverwaltung im Vergleich zu queue.yaml verwenden.

Warteschlangen erstellen

Lesen Sie diesen Abschnitt, wenn Ihre Anwendung Warteschlangen programmatisch erstellt oder wenn Sie zusätzliche Warteschlangen über die Befehlszeile erstellen möchten.

In Cloud Tasks haben Warteschlangennamen das Format projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID. Der Teil LOCATION_ID des Warteschlangennamens entspricht einer Google Cloud -Region. Der Teil QUEUE_ID des Warteschlangennamens entspricht dem Feld name der Cloud Tasks-Warteschlange. Der Warteschlangenname wird bei der Erstellung der Warteschlange basierend auf Grundlage des angegebenen Projekt, der Region und QUEUE_ID generiert.

Im Allgemeinen muss der Standort der Warteschlange mit der Region Ihrer Anwendung übereinstimmen. Die beiden Ausnahmen von dieser Regel gelten für Anwendungen mit der Region europe-west und Anwendungen mit der Region us-central. In Cloud Tasks werden diese Regionen europe-west1 bzw. us-central1 genannt.

Sie können während der Erstellung der Warteschlange eine optionale Warteschlangenkonfiguration angeben. Alternativ können Sie die Warteschlange aktualisieren, nachdem sie erstellt wurde.

Sie müssen vorhandene Warteschlangen nicht neu erstellen. Migrieren Sie stattdessen den Code, der mit Ihren vorhandenen Warteschlangen interagiert, indem Sie die relevanten Teile dieser Anleitung lesen.

Warteschlangennamen wiederverwenden

Sie müssen nach dem Löschen einer Warteschlange sieben Tage warten, um eine Warteschlange mit derselben Warteschlangen-ID im selben Projekt und am selben Ort (d. h. derselben Region) zu erstellen.

Im folgenden Beispiel werden zwei Warteschlangen mit Cloud Tasks erstellt. Die erste Warteschlange hat die Warteschlangen-ID queue-blue und ist so konfiguriert, dass alle Aufgaben mit einer Rate von 5/s an die Version v2 des Dienstes task-module gesendet werden. Die zweite Warteschlange hat die Warteschlangen-ID queue-red und sendet Aufgaben mit einer Rate von 1/s. Beide werden im Projekt mit der Projekt-ID my-project-id am Standort us-central1 erstellt. Dies ist die Cloud Tasks-Entsprechung zum Erstellen von Warteschlangen in Aufgabenwarteschlangen.

gcloud

Die gcloud CLI leitet das Projekt und den Speicherort von der Konfiguration der gcloud CLI ab.

gcloud tasks queues create queue-blue \
--max-dispatches-per-second=5 \
--routing-override=service:task-module,version:v2

gcloud tasks queues create queue-red \
--max-dispatches-per-second=1

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue_blue_name = 'queue-blue'
# queue_red_name = 'queue-red'

parent = f"projects/{project}/locations/{location}"

queue_blue = {
    "name": client.queue_path(project, location, queue_blue_name),
    "rate_limits": {"max_dispatches_per_second": 5},
    "app_engine_routing_override": {"version": "v2", "service": "task-module"},
}

queue_red = {
    "name": client.queue_path(project, location, queue_red_name),
    "rate_limits": {"max_dispatches_per_second": 1},
}

queues = [queue_blue, queue_red]
for queue in queues:
    response = client.create_queue(parent=parent, queue=queue)
    print(response)

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Cloud Tasks-Warteschlange erstellen.

Verarbeitungsrate der Warteschlange festlegen

In der folgenden Tabelle sind die Felder aufgeführt, die sich bei Aufgabenwarteschlangen und Cloud Tasks unterscheiden.

Feld in Aufgabenwarteschlangen	Feld in Cloud Tasks	Beschreibung
`rate`	`max_dispatches_per_second`	Die maximale Rate, mit der Aufgaben aus der Warteschlange weitergeleitet werden
`max_concurrent_requests`	`max_concurrent_dispatches`	Die maximale Anzahl gleichzeitiger Aufgaben, die aus der Warteschlange weitergeleitet werden können
`bucket_size`	`max_burst_size`	Cloud Tasks berechnet ein get-only-Attribut `max_burst_size`, das die Verarbeitungsgeschwindigkeit von Aufgaben in der Warteschlange entsprechend dem Wert von `max_dispatches_per_second` begrenzt. Dieses Feld ermöglicht der Warteschlange eine hohe Rate, sodass die Verarbeitung kurz nach dem Einreihen einer Aufgabe in die Warteschlange beginnt. Die Ressourcennutzung wird jedoch begrenzt, wenn viele Aufgaben in kurzer Zeit in die Warteschlange eingereiht werden. Bei App Engine-Warteschlangen, die mit einer Datei `queue.yaml` erstellt oder aktualisiert wurden, ist `max_burst_size` anfangs gleich `bucket_size`. Wenn die Warteschlange jedoch später über eine Cloud Tasks-Schnittstelle an den Befehl `update` übergeben wird, wird `max_burst_size` entsprechend dem Wert von `max_dispatches_per_second` zurückgesetzt, unabhängig davon, ob `max_dispatches_per_second` aktualisiert wird.
`total_storage_limit`	In Cloud Tasks verworfen	Cloud Tasks unterstützt nicht das Festlegen eines benutzerdefinierten Speicherlimits

Sie können die Verarbeitungsrate der Warteschlange beim Erstellen der Warteschlange festlegen oder sie anschließend aktualisieren. Im folgenden Beispiel wird Cloud Tasks verwendet, um die Verarbeitungsrate für eine Warteschlange mit dem Namen queue-blue festzulegen, die bereits erstellt wurde. Wenn queue-blue mit einer Datei queue.yaml erstellt oder konfiguriert wurde, wird im folgenden Beispiel max_burst_size entsprechend dem max_dispatches_per_second-Wert von 20 zurückgesetzt. Dies ist die Cloud Tasks-Entsprechung zum Festlegen der Verarbeitungsrate für die Warteschlange in Aufgabenwarteschlangen.

gcloud

gcloud tasks queues update queue-blue \
--max-dispatches-per-second=20 \
--max-concurrent-dispatches=10

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue-blue'

# Get queue object
queue_path = client.queue_path(project, location, queue)
queue = client.get_queue(name=queue_path)

# Update queue object
queue.rate_limits.max_dispatches_per_second = 20
queue.rate_limits.max_concurrent_dispatches = 10

response = client.update_queue(queue=queue)
print(response)

Weitere Informationen finden Sie unter Ratenbegrenzungen definieren.

Warteschlangen deaktivieren und fortsetzen

Cloud Tasks verwendet den Begriff pause auf die gleiche Weise wie Aufgabenwarteschlangen den Begriff disable. Durch das Pausieren einer Warteschlange wird die Ausführung der Aufgaben in der Warteschlange angehalten, bis die Warteschlange fortgesetzt wird. Sie können jedoch weiterhin Aufgaben zu einer Warteschlange hinzufügen, die pausiert wurde. Cloud Tasks verwendet den Begriff resume auf dieselbe Weise wie Aufgabenwarteschlangen.

Im folgenden Beispiel wird eine Warteschlange mit der Warteschlangen-ID queue1 pausiert. Dies ist die Cloud Tasks-Entsprechung zum Deaktivieren von Warteschlangen in Aufgabenwarteschlangen.

gcloud

gcloud tasks queues pause 

queue1

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

queue_path = client.queue_path(project, location, queue)
response = client.pause_queue(name=queue_path)

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Warteschlangen pausieren.

Warteschlangen löschen

Nachdem Sie eine Warteschlange gelöscht haben, müssen Sie sieben Tage warten, bevor Sie eine Warteschlange mit demselben Namen erstellen können. Sie könnten auch alle Aufgaben aus einer Warteschlange löschen und die Warteschlange neu konfigurieren, wenn Sie nicht sieben Tage warten können.

Im folgenden Beispiel wird die Warteschlange mit der Warteschlangen-ID queue1 gelöscht. Dies ist die Cloud Tasks-Entsprechung zum Löschen von Warteschlangen in Aufgabenwarteschlangen.

gcloud

gcloud tasks queues delete 

queue1

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

queue_path = client.queue_path(project, location, queue)
response = client.delete_queue(name=queue_path)

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Warteschlangen löschen.

Aufgaben erstellen und verwalten

In diesem Abschnitt wird beschrieben, wie Sie Aufgaben mit der Cloud Tasks API erstellen und verwalten.

Aufgaben erstellen

In der folgenden Tabelle sind die Felder aufgeführt, die sich bei Aufgabenwarteschlangen und Cloud Tasks unterscheiden.

Feld in Aufgabenwarteschlangen	Feld in Cloud Tasks	Beschreibung
NEU in Cloud Tasks	`app_engine_http_request`	Erstellt eine Anfrage, die auf einen App Engine-Dienst abzielt. Diese Aufgaben werden als App Engine-Aufgaben bezeichnet.
`method`	`http_method`	Gibt die Anfragemethode an, z. B. `POST`.
`url`	`relative_uri`	Gibt den Aufgaben-Handler an. Beachten Sie den Unterschied im letzten Buchstaben: `i` für uniform resource identifier statt `l` für uniform resource locator
`target`	`app_engine_routing`	Optional. Gibt die App Engine `service`, `version` und `instance` für eine App Engine-Aufgabe an. Wenn nicht festgelegt, werden der Standarddienst, die Standardversion und die Standardinstanz verwendet.

Im folgenden Beispiel wird eine Aufgabe erstellt, die mit dem Handler /update_counter an einen App Engine-Dienst namens worker weitergeleitet wird. Dies ist die Cloud Tasks-Entsprechung zum Erstellen von Aufgaben in Aufgabenwarteschlangen.

gcloud

gcloud tasks create-app-engine-task --queue=default \
--method=POST --relative-uri=/update_counter --routing=service:worker \
--body-content=10

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'default'
amount = 10

parent = client.queue_path(project, location, queue)

task = {
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.POST,
        "relative_uri": "/update_counter",
        "app_engine_routing": {"service": "worker"},
        "body": str(amount).encode(),
    }
}

response = client.create_task(parent=parent, task=task)
eta = response.schedule_time.strftime("%m/%d/%Y, %H:%M:%S")
print(f"Task {response.name} enqueued, ETA {eta}.")

Weitere Informationen finden Sie in der Cloud Tasks-Referenz App Engine-Aufgaben erstellen.

Zieldienst und Routing angeben

Die Angabe des App Engine-Zieldienstes, der Version und der Instanz für App Engine-Aufgaben ist optional. App Engine-Aufgaben werden standardmäßig an den Dienst, die Version und die Instanz weitergeleitet, die beim Ausführen der Aufgabe die Standardeinstellung sind.

Legen Sie das Attribut app_engine_routing der Aufgabe während der Aufgabenerstellung fest, um einen anderen App Engine-Dienst, eine andere Version oder eine andere App Engine-Instanz für Ihre Aufgabe anzugeben.

Um alle Aufgaben in einer bestimmten Warteschlange an denselben App Engine-Dienst, dieselbe Version und dieselbe Instanz weiterzuleiten, können Sie das Attribut app_engine_routing_override in der Warteschlange festlegen.

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Routing konfigurieren.

Daten an den Handler übergeben

Wie bei Aufgabenwarteschlangen können Sie mit Cloud Tasks Daten auf zwei Arten an den Handler übergeben. Sie können Daten entweder als Abfrageparameter im relativen URI oder im Anfragetext mit den HTTP-Methoden POST oder PUT übergeben.

Cloud Tasks verwendet den Begriff Text auf die gleiche Weise wie Aufgabenwarteschlangen Nutzlast. In Cloud Tasks ist der Standardtextinhaltstyp „octet-stream” statt „Nur Text”. Sie können den Inhaltstyp „Text“ im Header angeben, um ihn festzulegen.

Im folgenden Beispiel wird ein Schlüssel auf zwei verschiedene Arten an den Handler /update_counter übergeben. Dies ist die Cloud Tasks-Entsprechung zur Übergabe von Daten an den Handler in Aufgabenwarteschlangen.

Konsole

gcloud tasks create-app-engine-task --queue=default --method=GET  \
--relative-uri=

/update_counter

?key=blue --routing=service:worker

gcloud tasks create-app-engine-task --queue=default --method=POST \
--relative-uri=

/update_counter

 --routing=service:worker \
--body-content="{'key': 'blue'}"

Clientbibliothek

import json

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'default'

parent = client.queue_path(project, location, queue)

task1 = {
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.POST,
        "relative_uri": "/update_counter?key=blue",
        "app_engine_routing": {"service": "worker"},
    }
}

task2 = {
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.POST,
        "relative_uri": "/update_counter",
        "app_engine_routing": {"service": "worker"},
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"key": "blue"}).encode(),
    }
}

response = client.create_task(parent=parent, task=task1)
print(response)
response = client.create_task(parent=parent, task=task2)
print(response)

Aufgaben benennen

Die Angabe des Aufgabennamens ist optional. Wenn Sie den Aufgabennamen nicht angeben, wird er von Cloud Tasks durch Generieren einer Aufgaben-ID und Ableiten des Projekts und des Standorts (d. h. Region) basierend auf der Warteschlange erstellt, die Sie bei der Aufgabenerstellung angegeben haben.

Aufgabennamen haben das Format projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID/tasks/TASK_ID. Der Teil TASK_ID des Aufgabennamens entspricht dem Feld name der Aufgabenwarteschlange.

Aufgabennamen wiederverwenden

Sie müssen warten, bevor Sie den Namen einer Aufgabe wiederverwenden können. Wie lange Sie warten müssen, hängt davon ab, ob die Warteschlange, die die Aufgabe weiterleitet, in Cloud Tasks oder in Aufgabenwarteschlangen erstellt wurde.

Bei Aufgaben in Warteschlangen, die mithilfe von Aufgabenwarteschlangen erstellt wurden (einschließlich der Standardwarteschlange), müssen Sie etwa 9 Tage warten, nachdem die ursprüngliche Aufgabe gelöscht oder ausgeführt wurde. Bei Aufgaben in Warteschlangen, die mit Cloud Tasks erstellt wurden, müssen Sie etwa eine Stunde warten, nachdem die ursprüngliche Aufgabe gelöscht oder ausgeführt wurde.

Im folgenden Beispiel wird eine Aufgabe mit dem Wert TASK_ID auf first-try erstellt und der Standardwarteschlange hinzugefügt. Dies ist das die Cloud Tasks-Entsprechung zum Benennen von Aufgaben in Aufgabenwarteschlangen.

gcloud

Die gcloud CLI erstellt den Aufgabennamen, wozu sie Projekt und Standort aus der Konfiguration ableitet.

gcloud tasks create-app-engine-task first-try --queue=default \
--method=GET --relative-uri=

/url/path

Clientbibliothek

Bei der Clientbibliothek müssen Sie den vollständigen Aufgabennamen für TASK_ID angeben. Das Projekt und der Speicherort müssen mit dem Projekt und dem Speicherort der Warteschlange übereinstimmen, der die Aufgabe hinzugefügt wird.

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'default'
# task_name = 'first-try'

parent = client.queue_path(project, location, queue)

task = {
    "name": client.task_path(project, location, queue, task_name),
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.GET,
        "relative_uri": "/url/path",
    },
}
response = client.create_task(parent=parent, task=task)
print(response)

Fehlgeschlagene Aufgaben wiederholen

Sie können die Konfiguration der Aufgabenwiederholung für Warteschlangen während der Erstellung der Warteschlange oder durch Aktualisieren der Warteschlange festlegen. In der folgenden Tabelle sind das Feld „Aufgabenwarteschlangen“ und das entsprechende Cloud Tasks-Feld aufgeführt.

Feld in Aufgabenwarteschlangen	Feld in Cloud Tasks
`task_retry_limit`	`max_attempts`
`task_age_limit`	`max_retry_duration`
`min_backoff_seconds`	`min_backoff`
`max_backoff_seconds`	`max_backoff`
`max_doublings`	`max_doublings`

Aufgabenspezifische Wiederholungsparameter

Aufgabenspezifische Wiederholungsparameter, die in Aufgabenwarteschlangen konfiguriert wurden, funktionieren in Cloud Tasks. Sie können sie jedoch nicht bearbeiten oder für neue Aufgaben festlegen. Um die Wiederholungsparameter für eine Aufgabe mit aufgabenspezifischen Wiederholungsparametern zu ändern, erstellen Sie die Aufgabe mit einer Cloud Tasks-Warteschlange mit den gewünschten Wiederholungsparametern neu.

Im folgenden Beispiel werden verschiedene Wiederholungsszenarien demonstriert:

In fooqueue werden Aufgaben bis zu siebenmal und bis zu zwei Tage nach dem ersten Ausführungsversuch wiederholt. Nachdem beide Limits überschritten wurden, gilt die Ausführung als endgültig gescheitert.
In barqueue versucht App Engine, die Ausführung von Aufgaben zu wiederholen, wobei das Intervall zwischen den einzelnen Versuchen linear erhöht wird, bis das maximale Backoff erreicht ist. Die Versuche werden dann unbegrenzt im maximalen Intervall fortgesetzt. Die Intervalle zwischen den Anfragen betragen somit 10 s, 20 s, 30 s, ..., 190 s, 200 s, 200 s usw.
In bazqueue beginnt das Wiederholungsintervall bei 10 s, verdoppelt sich dreimal und steigt dann linear bis zum maximalen Intervall an, mit dem auf unbestimmte Zeit wiederholt wird. Die Intervalle zwischen den Anfragen betragen somit 10 s, 20 s, 40 s, 80 s, 160 s, 240 s, 300 s, 300 s usw.

Dies ist die Cloud Tasks-Entsprechung zum Wiederholen von Aufgaben in Aufgabenwarteschlangen.

gcloud

Wenn Sie Optionen festlegen, die eine Anzahl von Sekunden angeben, müssen Sie s nach der Ganzzahl einfügen (z. B. 200s, nicht 200).

gcloud tasks queues create fooqueue \
--max-attempts=7 \
--max-retry-duration=172800s  #2*60*60*24 seconds in 2 days

gcloud tasks queues create barqueue \
--min-backoff=10s \
--max-backoff=200s \
--max-doublings=0

gcloud tasks queues create bazqueue \
--min-backoff=10s \
--max-backoff=300s \
--max-doublings=3

Clientbibliothek

from google.protobuf import duration_pb2

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# fooqueue = 'fooqueue'
# barqueue = 'barqueue'
# bazqueue = 'bazqueue'

parent = f"projects/{project}/locations/{location}"

max_retry = duration_pb2.Duration()
max_retry.seconds = 2 * 60 * 60 * 24

foo = {
    "name": client.queue_path(project, location, fooqueue),
    "rate_limits": {"max_dispatches_per_second": 1},
    "retry_config": {"max_attempts": 7, "max_retry_duration": max_retry},
}

min = duration_pb2.Duration()
min.seconds = 10

max = duration_pb2.Duration()
max.seconds = 200

bar = {
    "name": client.queue_path(project, location, barqueue),
    "rate_limits": {"max_dispatches_per_second": 1},
    "retry_config": {"min_backoff": min, "max_backoff": max, "max_doublings": 0},
}

max.seconds = 300
baz = {
    "name": client.queue_path(project, location, bazqueue),
    "rate_limits": {"max_dispatches_per_second": 1},
    "retry_config": {"min_backoff": min, "max_backoff": max, "max_doublings": 3},
}

queues = [foo, bar, baz]
for queue in queues:
    response = client.create_queue(parent=parent, queue=queue)
    print(response)

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Wiederholungsparameter festlegen.

Aufgaben aus einer Warteschlange löschen

Nachdem Sie eine Aufgabe gelöscht haben, müssen Sie 9 Tage warten, bevor Sie eine Aufgabe mit demselben Namen erstellen, wenn sich die Aufgabe in einer Warteschlange befand, die mit einer Datei queue.yaml erstellt wurde. Wenn sich die Aufgabe in einer Warteschlange befand, die mit Cloud Tasks erstellt wurde, müssen Sie 1 Stunde warten.

Im folgenden Beispiel wird die Aufgabe mit der Aufgaben-ID foo aus der Warteschlange mit der Warteschlangen-ID queue1 gelöscht. Dies ist die Cloud Tasks-Entsprechung zum Löschen von Aufgaben in Aufgabenwarteschlangen.

gcloud

Aufgabenprojekt und Standort werden aus dem Standardprojekt der gcloud CLI abgeleitet.

gcloud tasks delete foo --queue=queue1

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

task_path = client.task_path(project, location, queue, "foo")
response = client.delete_task(name=task_path)

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Aufgabe aus einer Warteschlange löschen.

Aufgaben dauerhaft löschen

Im folgenden Beispiel werden alle Aufgaben aus der Warteschlange mit der Warteschlangen-ID queue1 dauerhaft gelöscht. Dies ist die Cloud Tasks-Entsprechung für das dauerhafte Löschen von Aufgaben in Aufgabenwarteschlangen.

gcloud

Das Warteschlangenprojekt und der Standort werden aus dem Standardprojekt der gcloud CLI abgeleitet.

gcloud tasks queues purge 

queue1

Clientbibliothek

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

queue_path = client.queue_path(project, location, queue)
response = client.purge_queue(name=queue_path)

Weitere Informationen finden Sie in der Cloud Tasks-Referenz Alle Aufgaben aus einer Warteschlange dauerhaft löschen.

Nächste Schritte

Dokumentation zu Cloud Tasks
Cloud Tasks-Clientbibliothek
Cloud Tasks-REST-Referenz – Übersicht
Cloud Tasks-RPC-Referenz – Übersicht
Eine Anleitung finden Sie im Codelab zur Migration von App Engine-Aufgaben-Push-Warteschlangen zu Cloud Tasks.

Push-Warteschlangen zu Cloud Tasks migrieren (Python)

Funktionen, die in Cloud Tasks nicht verfügbar sind

Preise und Kontingente

Preise

Kontingente

Vor der Migration

Pull-Warteschlangen migrieren

Warteschlangenkonfiguration schützen

Cloud Tasks API aktivieren

Anwendung bei der Cloud Tasks API authentifizieren

gcloud CLI herunterladen

Cloud-Clientbibliotheken importieren

Python 2

Python 3

Python 2

Python 3

Warteschlangen erstellen und verwalten

Warteschlangen erstellen

Warteschlangennamen wiederverwenden

gcloud

Clientbibliothek

Verarbeitungsrate der Warteschlange festlegen

gcloud

Clientbibliothek

Warteschlangen deaktivieren und fortsetzen

gcloud

Clientbibliothek

Warteschlangen löschen

gcloud

Clientbibliothek

Aufgaben erstellen und verwalten

Aufgaben erstellen

gcloud

Clientbibliothek

Zieldienst und Routing angeben

Daten an den Handler übergeben

Konsole

Clientbibliothek

Aufgaben benennen

Aufgabennamen wiederverwenden

gcloud

Clientbibliothek

Fehlgeschlagene Aufgaben wiederholen

Aufgabenspezifische Wiederholungsparameter

gcloud

Clientbibliothek

Aufgaben aus einer Warteschlange löschen

gcloud

Clientbibliothek

Aufgaben dauerhaft löschen

gcloud

Clientbibliothek

Nächste Schritte