אחסון בקשות HTTP ב-Cloud Tasks

1. מבוא

הגדרת ניתוב משימות ברמת התור ו-BufferTaskAPI הן תכונות בתוכנית Public Preview. שתי התכונות כפופות לתנאי השימוש במוצרים בגרסת טרום-GA של התנאים וההגבלות של Google Cloud. יכול להיות שהתמיכה בתכונות בגרסת טרום-GA תהיה מוגבלת, ושינויים בתכונות בגרסת טרום-GA לא יהיו תואמים לגרסאות אחרות של טרום-GA. מידע נוסף זמין בקטע תיאורים של שלבי ההשקה.

‫Cloud Tasks הוא שירות מנוהל של תורי משימות, שמאפשר לנהל את הביצוע, השליחה והמסירה של מספר גדול של משימות.

שירות Cloud Tasks מאפשר להפריד בין חלקי עבודה, שנקראים משימות, שאפשר לבצע באופן עצמאי (למשל, משימה לעדכון רשומה במסד נתונים), מחוץ לזרימת האפליקציה הראשית, ולשלוח אותם לעיבוד אסינכרוני באמצעות פונקציות handler שיוצרים.

המשימה שהועברה מתווספת לתור, שבו היא נשמרת עד שהיא מבוצעת בהצלחה או עד שהיא נכשלת. בהתאם להגדרה, התור יכול לשמש גם ככלי לבקרה על זרימת נתונים של הפצה. אתם יוצרים ומגדירים את התור, ואז הוא מנוהל על ידי שירות Cloud Tasks. אחרי שמוסיפים משימות, התור שולח אותן ומוודא שהעובדים מעבדים אותן בצורה מהימנה.

אלה כמה מהתכונות העיקריות של Cloud Tasks:

• יעדי HTTP: אפשר להוסיף משימות שמכוונות לכל שירות HTTP שפועל ב-Compute Engine, ב-Google Kubernetes Engine, ב-Cloud Run, ב-Cloud Functions או במערכות מקומיות בצורה מאובטחת באמצעות אימות OAuth/OIDC לפי תקנים בתעשייה.
• ביטול כפילויות של משימות: משימות שנוספו כמה פעמים יישלחו רק פעם אחת.
• מסירה מובטחת: המשימות מועברות לפחות פעם אחת, ורוב המשימות מועברות בדיוק פעם אחת.
• אמצעי בקרה של קצב וניסיון חוזר: אפשר לשלוט בהרצה על ידי הגדרת הקצב שבו המשימות נשלחות, מספר הניסיונות המקסימלי ומשך הזמן המינימלי להמתנה בין הניסיונות.
• תזמון עתידי: שליטה בזמן שבו המשימה תופעל.

ב-Codelab הזה תלמדו קודם איך ליצור תור רגיל של Cloud Tasks ולהשתמש בו למשימות של יעד HTTP. בהמשך תלמדו איך להשתמש בביטול ברירת המחדל של URI של HTTP ברמת התור וב-BufferTask API החדש כדי לבצע בקלות רבה יותר אחסון בזיכרון מטמון של בקשות HTTP באמצעות Cloud Tasks.

מה תלמדו

• איך יוצרים משימות של יעד HTTP.
• איך יוצרים משימות של HTTP Target עם החלפה חדשה של URI ברמת התור.
• איך משנים את המשימות בהמתנה באמצעות החלפת מזהה משאבים אחיד (URI) ברמת התור.
• איך לבצע בקלות רבה יותר בקשות HTTP באמצעות ה-API החדש של BufferTask.

2. הגדרה ודרישות

הגדרת סביבה בקצב עצמי

1. נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

• שם הפרויקט הוא השם המוצג של הפרויקט הזה למשתתפים. זו מחרוזת תווים שלא נמצאת בשימוש ב-Google APIs. תמיד אפשר לעדכן את המיקום.
• מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שהוא מוגדר. מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית, ובדרך כלל לא צריך לדעת מה היא. ברוב ה-Codelabs, תצטרכו להפנות למזהה הפרויקט (בדרך כלל מסומן כ-PROJECT_ID). אם אתם לא אוהבים את המזהה שנוצר, אתם יכולים ליצור מזהה אקראי אחר. אפשר גם לנסות שם משתמש משלכם ולבדוק אם הוא זמין. אי אפשר לשנות את ההגדרה הזו אחרי השלב הזה, והיא תישאר לאורך הפרויקט.
• לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. במאמרי העזרה מפורט מידע נוסף על שלושת הערכים האלה.

שימו לב: מזהה הפרויקט הוא ייחודי גלובלית, ואחרי שתבחרו אותו אף אחד אחר לא יוכל להשתמש בו. אתם המשתמשים היחידים במזהה הזה. גם אם פרויקט נמחק, אי אפשר להשתמש שוב במזהה שלו.

הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את המיקום שמוגדר כברירת מחדל כללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.

2. בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API של Cloud. השלמת ה-codelab הזה לא תעלה לכם הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים נוספים אחרי שתסיימו את המדריך הזה, תוכלו למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.

הפעלת Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-codelab הזה תשתמשו ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-מסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

יחלפו כמה רגעים עד שההקצאה והחיבור לסביבת העבודה יושלמו. בסיום התהליך, אמור להופיע משהו כזה:

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-codelab הזה בדפדפן. לא צריך להתקין שום דבר.

3. יצירת תור רגיל למשימות של יעד HTTP

בשלב הראשון הזה תלמדו איך ליצור תור רגיל של Cloud Tasks ולהוסיף לו משימות HTTP כדי לטרגט שירות Cloud Run.

מהן משימות של HTTP Target?

משימות של יעד HTTP יכולות להיות מיועדות לכל שירות HTTP שפועל ב-Compute Engine, ב-Google Kubernetes Engine, ב-Cloud Run, ב-Cloud Functions או במערכות מקומיות בצורה מאובטחת באמצעות אימות OAuth/OIDC בתקן התעשייה.

פריסת שירות Cloud Run

קודם צריך לוודא שממשקי ה-API הנדרשים מופעלים:

gcloud services enable \
  cloudtasks.googleapis.com \
  run.googleapis.com

פריסת שירות Cloud Run שישמש כיעד של משימות HTTP:

SERVICE1=hello1
REGION=us-central1

gcloud run deploy $SERVICE1 \
  --allow-unauthenticated \
  --image=gcr.io/cloudrun/hello \
  --region=$REGION

יצירת תור של Cloud Tasks

יצירת תור רגיל ב-Cloud Tasks:

QUEUE1=http-queue
LOCATION=us-central1

gcloud tasks queues create $QUEUE1 --location=$LOCATION

משהים את התור באופן זמני, כדי שתוכלו לראות את משימות ה-HTTP בזמן שהן נוצרות:

gcloud tasks queues pause $QUEUE1 --location=$LOCATION

4. יצירה ובדיקה של משימת HTTP

בשלב הזה, תיצרו משימת HTTP שתכוון לתור שיצרתם קודם.

יצירת משימת HTTP

אפשר ליצור משימות HTTP באמצעות gcloud:

gcloud tasks create-http-task \
    --queue=$QUEUE1 \
    --location=$LOCATION \
    --url=$SERVICE1_URL \
    --method=GET

אופציונלי: אפשר גם ליצור משימת HTTP באמצעות ספריות לקוח. לדוגמה, אפשר לעיין ב- Program.cs כדי לראות דוגמה ל-C# שבה בקשת HTTP עטופה ב-Task וב-TaskRequest לפני שהיא נשלחת ל-Cloud Tasks באמצעות CloudTasksClient:

var taskRequest = new CreateTaskRequest
{
    Parent = new QueueName(projectId, location, queue).ToString(),
    Task = new Task
    {
        HttpRequest = new HttpRequest
        {
            HttpMethod = HttpMethod.Get,
            Url = url
        }
    }
};

var client = CloudTasksClient.Create();
var response = client.CreateTask(taskRequest);

כדי ליצור את המשימה ולהוסיף אותה לתור, מריצים את הפקודה הבאה:

dotnet run $PROJECT_ID $LOCATION $QUEUE1 $SERVICE1_URL

בדיקת משימת ה-HTTP

בשלב הזה, המשימה נוצרת אבל היא עדיין לא מבוצעת כי התור מושהה. כדי לבדוק את זה, אפשר להציג את רשימת התורים:

gcloud tasks queues list --location=$LOCATION

אתם אמורים לראות את התור במצב PAUSED:

QUEUE_NAME  STATE
http-queue  PAUSED

המשך הפעלת "הבאים בתור":

gcloud tasks queues resume $QUEUE --location=$LOCATION

בודקים את היומנים של שירות Cloud Run:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1

אפשר לראות ששירות Cloud Run קיבל בקשת GET מ-Cloud Tasks:

httpRequest:
  latency: 0.227597158s
  protocol: HTTP/1.1
  remoteIp: 35.243.23.192
  requestMethod: GET
  requestSize: '415'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.32.53
  status: 200
  userAgent: Google-Cloud-Tasks

5. יצירת תור עם הגדרות ניתוב

בשלב הזה נסביר איך ליצור תור של Cloud Tasks עם הגדרת ניתוב כדי להוסיף החלפה של URI מסוג HTTP באמצעות התכונה הגדרת ניתוב משימות ברמת התור. לאחר מכן תוסיפו אליו משימות HTTP כדי לטרגט את שירות Cloud Run הראשון, ותראו שהגדרת הניתוב מבטלת את ה-URI כדי לנתב משימות לשירות Cloud Run השני.

מהי הגדרת ניתוב משימות ברמת התור?

הגדרת ניתוב משימות ברמת התור משנה את ניתוב משימות ה-HTTP לכל התור, לכל המשימות שממתינות ולכל המשימות החדשות. כך קל יותר ליצור משימות, כי לא צריך להגדיר את יעד ה-HTTP ברמת המשימה, והספק מקבל יותר שליטה כי הוא יכול להגדיר את היעד של כל המשימות בתור (למשל, להפנות תנועה לקצה עורפי אחר אם הקצה העורפי המקורי מושבת).

אפשר להגדיר את ההגדרה הבאה ברמת התור:

• כותרות: כותרות ברמת התור, אם הן מצוינות ברמת התור, יעדכנו את הכותרות של כל המשימות בתור.
• HTTP Method: שיטת HTTP שמוגדרת ברמת התור תבטל את שיטת ה-HTTP של כל המשימות בתור.
• יעד URI: אפשר לבטל בנפרד את המארח, הנתיב, השאילתה, היציאה והסכימה (HTTP או HTTPS).
• הרשאה: הגדרת OIDC/OAuth ברמת התור תבטל את הגדרת OIDC/OAuth ברמת המשימה.

פריסת שירות שני ב-Cloud Run

פורסים שירות Cloud Run שני שישמש כיעד של החלפת ה-URI של ה-HTTP בהמשך:

SERVICE2=hello2
REGION=us-central1

gcloud run deploy $SERVICE2 \
  --allow-unauthenticated \
  --image=gcr.io/cloudrun/hello \
  --region=$REGION

שומרים את המארח של כתובת ה-URL של השירות למועד מאוחר יותר:

SERVICE2_URL=$(gcloud run services describe $SERVICE2 --region $REGION --format 'value(status.url)')
SERVICE2_HOST=$(echo $SERVICE2_URL | sed 's,http[s]*://,,g')

יצירת תור של Cloud Tasks עם הגדרת ניתוב

יוצרים תור עם הגדרת ניתוב עם החלפה של URI של HTTP לשירות השני של Cloud Run.

QUEUE2=http-queue-uri-override

gcloud beta tasks queues create $QUEUE2 \
  --http-uri-override=host:$SERVICE2_HOST \
  --location=$LOCATION

שימו לב ששינוי ה-URI מתייחס לשירות השני של Cloud Run. כל משימת HTTP שנוספת לתור תגרום לדריסה של מארח ה-URI המקורי שלה. אפשר לראות את הגדרות התור:

gcloud beta tasks queues describe $QUEUE2 --location=$LOCATION

אמורה להופיע הכתובת httpTarget עם uriOverride שמצביע על המארח של השירות השני:

httpTarget:
  uriOverride:
    host: hello2-idcwffc3yq-uc.a.run.app
    pathOverride: {}
    queryOverride: {}
...

משהים את התור באופן זמני, כדי שתוכלו לראות את משימות ה-HTTP בזמן שהן נוצרות:

gcloud tasks queues pause $QUEUE2 --location=$LOCATION

6. יצירה ובדיקה של משימת HTTP לתור עם הגדרות הניתוב

בשלב הזה תיצרו משימת HTTP שמכוונת לשירות הראשון, ותראו שה-URI שלה מוחלף על ידי התור כדי להפנות לשירות השני.

יצירת משימת HTTP

יוצרים משימת HTTP עם כתובת ה-URL של השירות הראשון:

gcloud tasks create-http-task \
    --queue=$QUEUE2 \
    --location=$LOCATION \
    --url=$SERVICE1_URL \
    --method=GET

בדיקת משימת ה-HTTP

המשך הפעלת "הבאים בתור":

gcloud tasks queues resume $QUEUE2 --location=$LOCATION

אפשר לראות שהשירות השני (לא הראשון) ב-Cloud Run קיבל בקשת GET מ-Cloud Tasks בגלל הדריסה:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE2" --limit 1

---
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello2-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

7. שינוי המשימות בהמתנה באמצעות הגדרות הניתוב

אפשר גם להשתמש בהגדרות הניתוב כדי לשנות את ה-URI של HTTP של כל המשימות בהמתנה בתור. האפשרות הזו שימושית אם שירות לקצה העורפי מושבת ואתם רוצים להפנות במהירות לשירות אחר. בשלב הזה נראה איך זה עובד.

להשהות שוב את התור:

gcloud tasks queues pause $QUEUE2 --location=$LOCATION

יוצרים משימת HTTP עם google.com ככתובת ה-URL של המשימה:

gcloud tasks create-http-task \
    --queue=$QUEUE2 \
    --location=$LOCATION \
    --url=https://www.google.com \
    --method=GET

המשימה במצב המתנה כי התור מושהה.

עכשיו מעדכנים את החלפת מזהה המשאבים האחיד (URI) של HTTP כך שיפנה לשירות הראשון. הפעולה הזו תגרום לשינוי של השרת המארח של המשימה בהמתנה מ-google.com לשרת המארח של השירות הראשון:

SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)')
SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g')

gcloud beta tasks queues update $QUEUE2 \
  --http-uri-override=host:$SERVICE1_HOST \
  --location=$LOCATION

המשך הפעלת "הבאים בתור":

gcloud tasks queues resume $QUEUE2 --location=$LOCATION

אפשר לראות שהשירות הראשון ב-Cloud Run קיבל בקשת GET מ-Cloud Tasks בגלל הדריסה (במקום google.com):

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1
---
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

8. יצירת תור עבור BufferTask API

בדרך כלל, יוצרים משימות באמצעות Tasks API, או מ-gcloud או מספריות הלקוח של Tasks. הדבר מטיל עומס על האפליקציות, כי הן צריכות לתחום בקשות HTTP במשימות באמצעות ספריות לקוח, וגם יוצר תלות בין האפליקציות לבין ספריות הלקוח של Tasks.

בשלב הזה נסביר איך לנצל את ההחלפה של ה-URI של HTTP ברמת התור ואת ה-API החדש של BufferTask כדי ליצור בקלות רבה יותר משימות של יעד HTTP, פשוט על ידי שליחת בקשת HTTP. כל אפליקציה שיכולה לשלוח בקשות HTTP יכולה עכשיו ליצור משימות של יעד HTTP.

מה זה BufferTask API?

‫CreateTask API היא הדרך הישנה ליצירת משימות, והיא מחייבת את הלקוח לשלוח אובייקט משימה ל-API עם כל השדות הנדרשים.

‫BufferTask API הוא תכונה חדשה שמאפשרת למשתמשים ליצור משימת HTTP בלי לספק הגדרות משימה (כתובת URL מסוג HTTP, כותרות, הרשאה), כך שאתם יכולים פשוט לשלוח הודעה או את גוף הבקשה אל Buffer API.

השינוי הזה מאפשר שילוב קל יותר עם שירותים, כי עכשיו אפשר לפרוס את Cloud Tasks לפני השירות בלי לבצע שינויים בקוד בצד הלקוח. כל בקשת HTTP שרירותית שנשלחת אל BufferTask API נעטפת כאובייקט Task ונמסרת ליעד שהוגדר ברמת התור.

כדי להשתמש ב-BufferTask API, צריך להגדיר את התור עם הגדרת Target URI (כתובת URI של יעד). במילים אחרות, התכונה Queue-level Routing Configuration (הגדרת ניתוב ברמת התור) היא תנאי מוקדם לשימוש ב-BufferTask API.

יצירת תור של Cloud Tasks עם הגדרת ניתוב

יוצרים תור עם הגדרת ניתוב שמפנה לשירות הראשון שפרסנו בשלב הקודם:

SERVICE1=hello1
SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)')
SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g')
QUEUE3=http-queue-uri-override-buffer

gcloud beta tasks queues create $QUEUE3 \
  --http-uri-override=host:$SERVICE1_HOST \
  --location=$LOCATION

משהים את התור באופן זמני, כדי שתוכלו לראות את משימות ה-HTTP בזמן שהן נוצרות:

gcloud tasks queues pause $QUEUE3 --location=$LOCATION

9. שימוש ב-BufferTask API כדי לשמור בקשות HTTP במאגר זמני

בשלב הזה, תאגרו בקשות פשוטות של HTTP GET או POST באמצעות BufferTask API. מתחת לפני השטח, Cloud Tasks עוטף את בקשות ה-HTTP האלה במשימות HTTP עם הגדרות ברירת המחדל של תצורת הניתוב בתור.

קודם כל, מתחברים כדי לקבל אסימון גישה ומגדירים כמה משתנים:

gcloud auth application-default login
ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
PROJECT_ID=$(gcloud config get-value project)
TASKS_QUEUES_API="https://cloudtasks.googleapis.com/v2beta3/projects/$PROJECT_ID/locations/$LOCATION/queues"

יצירת משימת HTTP

יוצרים משימת HTTP באמצעות BufferTask API. שימו לב שזו בקשת HTTP GET פשוטה, בלי צורך ליצור משימה:

curl -X GET "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

יוצרים עוד משימת HTTP עם HTTP POST וגוף:

curl -X POST "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -d "{'message': 'Hello World'}"

אופציונלי: אפשר גם ליצור משימת HTTP באמצעות ספריות לקוח. לדוגמה, אפשר לעיין בProgram.cs כדי לראות דוגמה ב-C# ‎ שבה בקשת HTTP GET נשלחת ישירות אל BufferTask API בלי לעטוף אותה ב-Task או בלי להשתמש בספריית הלקוח של Cloud Tasks:

var BufferTaskApiUrl = $"https://cloudtasks.googleapis.com/v2beta3/projects/{ProjectId}/locations/{Location}/queues/{Queue}/tasks:buffer";

using (var client = new HttpClient())
{
    client.DefaultRequestHeaders.Add("Authorization", $"Bearer {AccessToken}");
    var response = await client.GetAsync(BufferTaskApiUrl);
    var content = await response.Content.ReadAsStringAsync();
    Console.WriteLine($"Response: {content}");
}

אפשר להריץ אותו כך:

dotnet run $PROJECT_ID $LOCATION $QUEUE3 $ACCESS_TOKEN

‫BufferTask API יוצר משימה מבקשות ה-HTTP ומוסיף את כתובת ה-URL מהגדרות התצורה של הניתוב בתור ל-URI.

בדיקת משימת ה-HTTP

המשך הפעלת "הבאים בתור":

gcloud tasks queues resume $QUEUE3 --location=$LOCATION

אפשר לראות שהשירות Cloud Run קיבל בקשות HTTP GET ו-POST מ-Cloud Tasks:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 4

---
httpRequest:
  latency: 0.002279292s
  protocol: HTTP/1.1
  remoteIp: 35.243.23.42
  requestMethod: POST
  requestSize: '777'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5450'
  serverIp: 216.239.32.53
  status: 200
  userAgent: Google-Cloud-Tasks
...
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

10. מזל טוב

כל הכבוד, סיימתם את ה-Codelab!

כמעקב, אפשר לנסות את Cloud Tasks כמאגר נתונים זמני בין Pub/Sub לבין Cloud Run כדי לראות דוגמה מהעולם האמיתי לאופן שבו התכונות החדשות האלה של Cloud Tasks יכולות לעזור ליצור בקלות תור במאגר נתונים זמני (buffer queue) בין שירותים.

ניקוי (אופציונלי)

כדי להימנע מחיובים, מומלץ למחוק את המשאבים.

אם לא צריך את הפרויקט, אפשר פשוט למחוק אותו:

gcloud projects delete $PROJECT_ID

אם אתם צריכים את הפרויקט, אתם יכולים למחוק משאבים בנפרד.

מוחקים את שירותי Cloud Run:

gcloud run services delete $SERVICE1 --region $REGION
gcloud run services delete $SERVICE2 --region $REGION

מחיקת תורי Cloud Tasks:

gcloud tasks queues delete $QUEUE1 --location=$LOCATION
gcloud tasks queues delete $QUEUE2 --location=$LOCATION
gcloud tasks queues delete $QUEUE3 --location=$LOCATION

מה נכלל

• איך יוצרים משימות של יעד HTTP.
• איך יוצרים משימות של HTTP Target עם החלפה חדשה של URI ברמת התור.
• איך משנים את המשימות בהמתנה באמצעות החלפת מזהה משאבים אחיד (URI) ברמת התור.
• איך לבצע בקלות רבה יותר בקשות HTTP באמצעות ה-API החדש של BufferTask.