將發送佇列遷移至 Cloud Tasks (Python)

本頁說明如何將發送佇列程式碼從工作佇列遷移至 Cloud Tasks。Cloud Tasks 現已成為使用 App Engine 推送佇列的首選方式。

有了 Cloud Tasks，您就能使用透過 Task Queues RPC API 存取的服務。也就是說，您不需要重新建立現有的推送佇列和推送工作。不過，您必須遷移用於建立或與推送佇列或推送工作互動的程式碼，才能使用 Cloud Tasks API。

您可以使用 Cloud Tasks REST 和 RPC API、Cloud Tasks 用戶端程式庫、Google Cloud CLI 和 Google Cloud 主控台，建立及與推送佇列和推送工作互動。本頁面提供使用 gcloud CLI 和 Cloud Tasks 用戶端程式庫的範例。

在 Cloud Tasks 中，所有佇列都會以推送佇列的方式運作。在本指南的其餘部分和 Cloud Tasks 說明文件中，佇列一詞等同於推送佇列一詞。同樣地，task 一詞等同於 push task。

Cloud Tasks 不提供的功能

以下功能不適用於 Cloud Tasks：

  • 在 Datastore 交易中將工作排入佇列
  • 使用延遲工作程式庫而非工作站服務
  • 在多用戶群應用程式中處理工作
  • 使用本機開發伺服器進行模擬
  • 非同步新增工作

定價與配額

將發送佇列遷移至 Cloud Tasks 可能會影響應用程式的價格和配額。

定價

Cloud Tasks 有專屬的定價。與工作佇列一樣，透過工作傳送要求至 App Engine 應用程式，可能會導致應用程式產生費用。

配額

Cloud Tasks 配額與工作佇列的配額不同。與 Task Queues 一樣，從 Cloud Tasks 傳送要求至 App Engine 應用程式，可能會影響 App Engine 要求配額。

遷移前

如果您尚未設定 Python 開發環境，請使用與 Google Cloud相容的 Python 版本，並安裝測試工具來建立隔離的 Python 環境。

以下各節將說明將推送佇列遷移至 Cloud Tasks 之前的設定步驟。

遷移提取佇列

開始之前，請先遷移拉取佇列，再按照本指南中的說明遷移推送佇列。不建議在遷移發送佇列後再遷移接收佇列，因為必須使用 queue.yaml 檔案可能會導致 Cloud Tasks 出現非預期的行為。

保護佇列設定

開始遷移至 Cloud Tasks 後，修改 queue.yaml 檔案可能會導致非預期的行為，因此不建議這麼做。請按照下列步驟操作，避免佇列設定檔遭到 queue.yaml 檔案修改。

  1. 設定 gcloud CLI，以便在日後的部署作業中略過 queue.yaml 檔案。

    將 queue.yaml 檔案新增至 .gcloudignore 檔案。如要檢查是否已擁有 .gcloudignore 檔案，您可以在應用程式的頂層目錄中，在終端機中執行下列指令。如果檔案存在，這項指令會輸出檔案名稱。

    ls -a | grep .gcloudignore

    如要進一步瞭解 .gcloudignore 檔案，請參閱 .gcloudignore 參考資料。

  2. 限制 queue.yaml 檔案的權限。

    請按照佇列設定安全性指南中的最佳做法操作。

  3. 瞭解 Cloud Tasks 和 queue.yaml 檔案 (選用)。

    使用 Cloud Tasks API 管理佇列設定時，部署 queue.yaml 檔案會覆寫 Cloud Tasks 設定的設定，這可能會導致異常行為。如要進一步瞭解，請參閱「使用佇列管理功能和 queue.yaml」。

啟用 Cloud Tasks API

如要啟用 Cloud Tasks API，請在 API 程式庫中，按一下 Cloud Tasks API 上的「啟用」。如果畫面上顯示「管理」按鈕，而非「啟用」按鈕，表示您先前已為專案啟用 Cloud Tasks API，因此不必再次啟用。

向 Cloud Tasks API 驗證應用程式

您必須向 Cloud Tasks API 驗證應用程式。本節將討論兩種不同用途的驗證方式。

如要在本機開發或測試應用程式，建議您使用服務帳戶。如需設定服務帳戶並將其連結至應用程式的操作說明，請參閱「手動取得及提供服務帳戶憑證」。

如要在 App Engine 上部署應用程式，您不需要提供任何新的驗證資訊。應用程式預設憑證 (ADC) 會推斷 App Engine 應用程式的驗證詳細資料。

下載 gcloud CLI

如果您先前未安裝 gcloud CLI，請下載並安裝該工具，以便搭配 Cloud Tasks API 使用 gcloud CLI。如果您已安裝 gcloud CLI，請在終端機中執行下列指令。

gcloud components update

匯入 Cloud 用戶端程式庫

如要在 App Engine 應用程式中使用 Cloud Tasks 用戶端程式庫，請按照下列步驟操作：

  1. 更新 app.yaml 檔案。請按照您使用的 Python 版本的操作說明操作：

    Python 2

    如果是 Python 2 應用程式，請新增最新版本的 grpcio 和 setuptools 程式庫。

    以下是 app.yaml 檔案範例：

    runtime: python27
threadsafe: yes
api_version: 1

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

    Python 3

    針對 Python 3 應用程式，請在 app.yaml 檔案中使用支援的 Python 3 版本指定 runtime 元素。例如：

    runtime: python310 # or another support version

    Python 3 執行階段會自動安裝程式庫，因此您不需要從先前的 Python 2 執行階段指定內建程式庫。如果 Python 3 應用程式在遷移時使用其他舊版內含服務，您可以繼續指定必要的內建程式庫。否則，您可以刪除 app.yaml 檔案中不必要的資料行。

  2. 更新 requirements.txt 檔案。請按照您使用的 Python 版本操作說明進行操作：

    Python 2

    將 Cloud Tasks 的 Cloud 用戶端程式庫新增至 requirements.txt 檔案中的依附元件清單。

    google-cloud-tasks

    接著執行 pip install -t lib -r requirements.txt，更新應用程式可用的程式庫清單。

    Python 3

    將 Cloud Tasks 的 Cloud 用戶端程式庫新增至 requirements.txt 檔案中的依附元件清單。

    google-cloud-tasks

    在 Python 3 執行階段部署應用程式時，App Engine 會自動安裝這些依附元件，因此請刪除 lib 資料夾 (如果有)。

  3. 針對 Python 2 應用程式，如果應用程式使用內建或複製的程式庫，您必須在 appengine_config.py 檔案中指定這些路徑，該檔案位於與 app.yaml 檔案相同的資料夾中：

    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)

    appengine_config.py 檔案假設目前使用中的目錄是 lib 資料夾的所在位置。在某些情況下 (例如單元測試)，目前的使用中目錄可能會有所不同。為避免發生錯誤，您可以使用以下方式明確傳入 lib 資料夾的完整路徑：

    import os
path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')

  4. 在使用 Task Queues API 推送佇列的任何檔案中，匯入 Cloud Tasks 用戶端程式庫：

    from google.cloud import tasks

    成功完成將所有建立或與推送佇列互動的程式碼完整遷移至 Cloud Tasks 後，請移除匯入工作佇列 API 的陳述式，例如 from google.appengine.api import taskqueue。

建立及管理佇列

本節說明如何使用 Cloud Tasks API 建立及管理佇列。

使用 Cloud Tasks 時，您不需要使用 queue.yaml 檔案建立或管理佇列。而是改用 Cloud Tasks API。我們不建議同時使用 queue.yaml 檔案和 Cloud Tasks API，但這可能會是從工作佇列遷移至 Cloud Tasks 時不可避免的部分，具體取決於您的應用程式。請參閱「使用佇列管理功能與 queue.yaml」瞭解最佳做法。

建立佇列

如果應用程式會以程式輔助方式建立佇列，或是您想透過指令列建立其他佇列，請參閱本節。

在 Cloud Tasks 中，佇列名稱的格式為 projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID。佇列名稱中的 LOCATION_ID 部分對應至 Google Cloud 區域。佇列名稱的 QUEUE_ID 部分等同於 Task Queues 佇列 name 欄位。佇列名稱會在建立佇列時產生，並根據您指定的專案、區域和 QUEUE_ID 產生。

一般來說，佇列位置 (即區域) 必須與應用程式所在的區域相同。這項規則有兩個例外狀況，分別是使用 europe-west 區域的應用程式，以及使用 us-central 區域的應用程式。在 Cloud Tasks 中，這些區域分別稱為 europe-west1 和 us-central1。

您可以在建立佇列時指定選用的佇列設定，但也可以在建立佇列後更新佇列。

您不需要重新建立現有的佇列。請改為閱讀本指南的相關部分，遷移與現有佇列互動的程式碼。

重複使用佇列名稱

刪除佇列後，您必須等待 7 天，才能在相同的專案和位置 (即區域) 中建立具有相同佇列 ID 的佇列。

以下範例會使用 Cloud Tasks 建立兩個佇列。第一個佇列的佇列 ID 為 queue-blue，且已設定為以 5/s 的速率，將所有工作傳送至服務 task-module 的版本 v2。第二個佇列的佇列 ID 為 queue-red，且以 1/s 的速率調度工作。兩者都是在專案中建立，專案 ID 為 my-project-id，位於 us-central1。這與在工作佇列中建立佇列的 Cloud Tasks 功能相同。

gcloud

gcloud CLI 會從 gcloud CLI 設定中推斷專案和位置。

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

用戶端程式庫

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)

如需更多資訊，請參閱 Cloud Tasks 參考資料「建立 Cloud Tasks 佇列」。

設定佇列處理速率

下表列出 Task Queues 與 Cloud Tasks 的不同欄位。

「Task Queues」欄位 Cloud Tasks 欄位 說明
rate max_dispatches_per_second 調度佇列工作的最大頻率
max_concurrent_requests max_concurrent_dispatches 可從佇列調度的並行工作數上限
bucket_size max_burst_size

Cloud Tasks 會計算只讀屬性 max_burst_size，限制佇列中工作處理的速度，具體做法是根據 max_dispatches_per_second 的值。這個欄位可讓佇列享有高速率，讓工作在排入佇列後立即開始處理，但短時間內若有許多工作排入佇列，也足以限制資源的使用量。

對於使用 queue.yaml 檔案建立或更新的 App Engine 佇列，max_burst_size 一開始會等於 bucket_size。不過，如果稍後使用任何 Cloud Tasks 介面將佇列傳遞至 update 指令，max_burst_size 會根據 max_dispatches_per_second 的值重設，無論 max_dispatches_per_second 是否已更新。
total_storage_limit 已在 Cloud Tasks 中淘汰 Cloud Tasks 不支援設定自訂儲存空間限制

您可以在建立佇列時設定佇列處理率，也可以稍後更新。以下範例使用 Cloud Tasks 在已建立的 queue-blue 佇列中設定處理速率。如果您是使用 queue.yaml 檔案建立或設定 queue-blue，以下範例會根據 20 的 max_dispatches_per_second 值重設 max_burst_size。這與在工作佇列中設定佇列處理速率的 Cloud Tasks 功能相同。

gcloud

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

用戶端程式庫

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)

詳情請參閱「定義頻率限制」。

停用及接續處理佇列

Cloud Tasks 使用「pause」一詞的方式，與 Task Queues 使用「disable」一詞相同。暫停佇列後，系統會停止執行佇列中的工作，直到佇列恢復為止。不過，您可以繼續將工作新增至已暫停的佇列。Cloud Tasks 使用「resume」一詞的方式與 Task Queues 相同。

以下範例會暫停佇列 ID 為 queue1 的佇列。這在 Cloud Tasks 中等同於停用工作佇列。

gcloud

gcloud tasks queues pause 

queue1

用戶端程式庫

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)

詳情請參閱 Cloud Tasks 參考資料「暫停佇列」。

刪除佇列

刪除佇列後，您必須等待 7 天，才能建立名稱相同的佇列。如果無法等待 7 天，建議您清除佇列中的所有工作，然後重新設定佇列。

以下範例會刪除佇列 ID 為 queue1 的佇列。這與在工作佇列中刪除佇列的 Cloud Tasks 功能相同。

gcloud

gcloud tasks queues delete 

queue1

用戶端程式庫

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)

如需更多資訊，請參閱 Cloud Tasks 參考資料「刪除佇列」。

建立及管理工作

本節說明如何使用 Cloud Tasks API 建立及管理工作。

建立工作

下表列出 Task Queues 與 Cloud Tasks 的不同欄位。

「Task Queues」欄位 Cloud Tasks 欄位 說明
Cloud Tasks 新功能 app_engine_http_request 建立指定 App Engine 服務的要求。這些工作稱為 App Engine 工作。
method http_method 指定要求方法，例如 POST
url relative_uri 指定工作處理常式。請注意最後一個字母的差異：i 代表統一資源 ID，而非l 代表統一資源定位器
target app_engine_routing (非必要) 指定 App Engine 工作中的 App Engine service、version 和 instance。如未設定，系統會使用預設服務、版本和執行個體。

以下範例會建立工作，並透過 /update_counter 處理常式將工作路由至名為 worker 的 App Engine 服務。這是 Cloud Tasks 在工作佇列中建立工作的等價操作。

gcloud

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

用戶端程式庫

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}.")

如需更多資訊，請參閱 Cloud Tasks 參考資料「建立 App Engine 工作」。

指定目標服務和路由

您可以選擇為 App Engine 工作指定 App Engine 目標服務、版本和執行個體。根據預設，App Engine 工作會傳送至在嘗試執行工作時的預設服務、版本和執行個體。

在建立工作時設定工作的 app_engine_routing 屬性，為工作指定不同的 App Engine 服務、版本或執行個體。

如要將特定佇列中的所有工作轉送至相同的 App Engine 服務、版本和執行個體，您可以在佇列上設定 app_engine_routing_override 屬性。

如需更多資訊，請參閱 Cloud Tasks 參考資料「設定轉送」。

將資料傳送至處理常式

與工作佇列一樣，您可以使用 Cloud Tasks 以兩種方式將資料傳遞至處理常式。您可以將資料做為查詢參數，傳送至相對 URI；也可以使用 HTTP 方法 POST 或 PUT，將資料傳送至要求主體。

Cloud Tasks 使用「body」一詞的方式，與 Task Queues 使用「payload」一詞的方式相同。在 Cloud Tasks 中，預設的內容類型為八位元位元組串流，而非純文字。您可以在標頭中指定主體內容類型。

以下範例會以兩種不同的方式將鍵傳遞至處理程序 /update_counter 。這是 Cloud Tasks 在工作佇列中將資料傳遞至處理常的等效做法。

主控台

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'}"

用戶端程式庫

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)

命名工作

您可以選擇是否指定任務名稱。如果未指定工作名稱，Cloud Tasks 會為您建立工作名稱，方法是產生工作 ID，並根據您在建立工作時指定的佇列，推測專案和位置 (即區域)。

任務名稱的格式為 projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID/tasks/TASK_ID。工作名稱的 TASK_ID 部分等同於工作佇列工作 name 欄位。

重複使用工作名稱

您必須等待一段時間，才能重新使用工作名稱。您必須等待的時間長短，取決於調度工作任務的佇列是在 Cloud Tasks 還是 Task Queues 中建立。

如果是使用工作佇列 (包括預設佇列) 建立的佇列中的工作，您必須等待原始工作刪除或執行後約 9 天，如果是使用 Cloud Tasks 建立的佇列工作，您必須等待原始工作刪除或執行後約 1 小時。

以下範例會建立工作，並將 TASK_ID 設為 first-try，然後將工作新增至預設佇列。這與在工作佇列中命名工作的 Cloud Tasks 功能相同。

gcloud

gcloud CLI 會從設定中推斷專案和位置，藉此建構工作名稱。

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

/url/path

用戶端程式庫

如要使用用戶端程式庫指定 TASK_ID，您必須指定完整工作名稱。專案和位置必須與要新增工作所在的佇列相符。

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)

重試失敗的工作

您可以在建立佇列時，或透過更新佇列，為佇列設定工作重試設定。下表列出 Task Queues 欄位和對應的 Cloud Tasks 欄位。

「Task Queues」欄位 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

工作專屬重試參數

在工作佇列中設定的工作專屬重試參數可在 Cloud Tasks 中運作，但您無法編輯或在新工作中設定這些參數。如要變更具有任務專屬重試參數的任務的重試參數，請使用具有所需重試參數的 Cloud Tasks 佇列重新建立任務。

以下範例示範幾種重試情況：

  • 在 fooqueue 中，工作從第一次執行嘗試起，最多可以重試七次，為期最多兩天。如果兩項限制都已超過，這項工作就會永久失敗。
  • 在 barqueue 中，App Engine 會重試工作，並以線性方式逐漸拉長每次的重試間隔時間，直到輪詢上限為止，然後會以最長時間間隔無限期一直重試 (所以要求間隔為 10 秒、20 秒、30 秒、...、190 秒、200 秒、200 秒、...)。
  • 在 bazqueue 中，重試間隔從 10 秒開始，然後以雙倍增加三次、接著以線性方式增加，最後則按最長時間間隔無限期重試 (所以要求間隔為 10 秒、20 秒、40 秒、80 秒、160 秒、240 秒、300 秒、300 秒...)。

這是 Cloud Tasks 在工作佇列中重試工作的等價操作。

gcloud

設定指定秒數的選項時，請務必在整數後方加上 s (例如 200s，而非 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

用戶端程式庫

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)

如需更多資訊，請參閱 Cloud Tasks 參考資料「設定重試參數」。

刪除佇列中的工作

如果您刪除的工作是使用 queue.yaml 檔案建立的佇列，則必須等待 9 天才能建立名稱相同的工作；如果是使用 Cloud Tasks 建立的佇列，則必須等待 1 小時才能建立名稱相同的工作。

以下範例會從佇列 ID queue1 中刪除工作 ID foo 的工作。這與在工作佇列中刪除工作的 Cloud Tasks 功能相同。

gcloud

系統會根據 gcloud CLI 的預設專案推斷工作專案和位置。

gcloud tasks delete foo --queue=queue1

用戶端程式庫

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)

如需更多資訊，請參閱 Cloud Tasks 參考資料「從佇列中刪除工作」。

清除工作

以下範例會清除佇列 ID queue1 的佇列中所有工作。這是 Cloud Tasks 在工作佇列中清除工作的等價操作。

gcloud

佇列專案和位置會從 gcloud CLI 預設專案推斷。

gcloud tasks queues purge 

queue1

用戶端程式庫

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)

如需更多資訊，請參閱 Cloud Tasks 參考資料「從佇列中清除所有工作」。

後續步驟