אחסון בקשות 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 ברמת התור.
• איך לאגור בקשות HTTP בקלות רבה יותר באמצעות BufferTask API החדש.

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 ברמת המשימה, והספק מקבל יותר שליטה כי הוא יכול להגדיר את היעד של כל המשימות בתור (למשל, להפנות תנועה לקצה עורפי אחר אם הקצה העורפי המקורי מושבת).

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

• כותרות: כותרות ברמת התור, אם הן מצוינות ברמת התור, יעדכנו או יוסיפו (upsert) כותרות לכל המשימות בתור.
• HTTP Method: ה-method של ה-HTTP שצוינה ברמת התור תבטל את ה-method של ה-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 מ-HTTP מ-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 ברמת התור ואת BufferTask API החדש כדי ליצור בקלות רבה יותר משימות של יעד 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 בתור, או במילים אחרות, התכונה 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. אגירת בקשות HTTP באמצעות BufferTask API

בשלב הזה, תאגרו בקשות 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. שימו לב שזו בקשת 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 יכולות לעזור ליצור בקלות תור מאגר בין שירותים, אפשר לנסות את Cloud Tasks כמאגר בין Pub/Sub לבין Cloud Run.

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

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

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

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 ברמת התור.
• איך לאגור בקשות HTTP בקלות רבה יותר באמצעות BufferTask API החדש.