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

1. מבוא

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

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

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

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

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

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

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

מה תלמדו

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

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

הגדרת סביבה בקצב אישי

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

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

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

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

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

הפעלת Cloud Shell

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

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

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

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

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

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

מהן משימות של יעד HTTP?

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

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

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

אפשר לקבוע את התצורה הבאה ברמת התור:

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

פריסה של שירות Cloud Run שני

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

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 קיבל בקשת HTTP 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

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

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

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

מהו BufferTask API?

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

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

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

כדי להשתמש ב-BufferTask API, צריך להגדיר בתור את ההגדרה של ה-URI של היעד. במילים אחרות, התכונה Queue-level Routing API היא דרישה מוקדמת לשימוש ב-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. שימו לב שמדובר בבקשת 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 יכולות לעזור ליצור בקלות תור למאגר נתונים זמני בין שירותים.

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

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

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

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