העברת תורי דחיפה ל-Cloud Tasks‏ (Go)

לפני שמשדרגים לגרסה האחרונה של SDK של שירותי App Engine, כדאי לעיין בסקירה הכללית של המעבר.

שדרוג לספריות הלקוח של Cloud Tasks

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

עם Cloud Tasks, אתם ניגשים לאותו שירות שאליו אתם ניגשים באמצעות Task Queues RPC API. המשמעות היא שלא צריך ליצור מחדש את תורי ההודעות הקיימים ואת משימות ה-Push. עם זאת, כדי להשתמש ב-Cloud Tasks API, צריך להעביר קוד שיוצר תורים של הודעות בדחיפה או מקיים אינטראקציה עם משימות בדחיפה.

אפשר ליצור תורים של משימות מסוג push ומשימות מסוג push ולבצע איתם אינטראקציה באמצעות ממשקי ה-API ל-REST ול-RPC של Cloud Tasks, ספריית הלקוח של Cloud Tasks, Google Cloud CLI ומסוףGoogle Cloud . בדף הזה מובאות דוגמאות לשימוש ב-CLI של gcloud ובספריית הלקוח של Cloud Tasks.

תכונות שלא זמינות ב-Cloud Tasks

התכונות הבאות לא זמינות ב-Cloud Tasks להעברה של ספריות הלקוח של Cloud Tasks:

• הוספת משימות לתור בעסקאות ב-Datastore
• שימוש בספריית המשימות שמושהות במקום בשירות worker
• עבודה עם משימות באפליקציות לפי עקרון ה-Multi-tenancy
• סימולציה באמצעות שרת הפיתוח המקומי
• הוספת משימות באופן אסינכרוני

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

תמחור ומכסות

העברת תורי הדחיפה ל-Cloud Tasks עשויה להשפיע על התמחור והמכסות של האפליקציה.

תמחור

לפני המעבר, כדאי לעיין בתמחור של Cloud Tasks כדי להעריך את העלות החודשית.

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

מכסות

בקשות Cloud Tasks נספרות גם במכסות הבקשות של App Engine.

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

לפני שמתחילים

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

העברה של תורים של בקשות משיכה

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

הגנה על הגדרות התור

אחרי שמתחילים את תהליך ההעברה ל-Cloud Tasks, שינוי הקובץ queue.yaml עלול לגרום להתנהגות בלתי צפויה, ולכן לא מומלץ. כדי להגן על הגדרת התור מפני שינויים בקובץ queue.yaml, מבצעים את השלבים הבאים.

1. מגדירים את ה-CLI של gcloud כך שקובץ 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. בקטע הזה נדון באימות בשני תרחישי שימוש שונים.

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

כדי לפרוס את האפליקציה ב-App Engine, לא צריך לספק אימות חדש. פרטי האימות של אפליקציות App Engine מוסקים מ-Application Default Credentials‏ (ADC).

ייבוא ספריות לקוח של Cloud

כדי להשתמש בספריית הלקוח של Cloud Tasks באפליקציית App Engine:

1. מורידים את התלות בספריית הלקוח של Cloud Tasks:

   go get cloud.google.com/go/cloudtasks/apiv2

2. מייבאים את התלויות של ספריית הלקוח Cloud Tasks בקבצים שאחראים ליצירה ולהוספה לתור של המשימות:

   import (
     "context"
     "fmt"
   
     cloudtasks "cloud.google.com/go/cloudtasks/apiv2"
     taskspb "cloud.google.com/go/cloudtasks/apiv2/cloudtaskspb"
   )

יצירה וניהול של תורים

בקטע הזה מוסבר איך ליצור ולנהל תורים באמצעות Cloud Tasks API.

ב-Cloud Tasks, לא משתמשים בקובץ queue.yaml כדי ליצור תורים או לנהל אותם. במקום זאת, משתמשים ב-Cloud Tasks API. לא מומלץ להשתמש גם בקובץ queue.yaml וגם ב-Cloud Tasks API, אבל יכול להיות שזה יהיה חלק בלתי נמנע מהמעבר מ-Task Queues ל-Cloud Tasks, בהתאם לאפליקציה שלכם. כדאי לקרוא את המאמר שימוש בניהול תורים לעומת queue.yaml כדי ללמוד על שיטות מומלצות.

יצירת תורים

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

ב-Cloud Tasks, שמות התורים הם בפורמט projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID. החלק LOCATION_ID בשם התור תואם ל Google Cloud אזור. החלק QUEUE_ID בשם התור שווה לשדה name של התור ב-Task Queues. שם התור נוצר במהלך יצירת התור על סמך הפרויקט, האזור ו-QUEUE_ID שאתם מציינים.

באופן כללי, המיקום של התור (כלומר, האזור) צריך להיות זהה לאזור של האפליקציה. יש שני חריגים לכלל הזה: אפליקציות שמשתמשות באזור europe-west ואפליקציות שמשתמשות באזור us-central. ב-Cloud Tasks, האזורים האלה נקראים europe-west1 ו-us-central1 בהתאמה.

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

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

הערה: שירות תור המשימות של App Engine יוצר באופן אוטומטי תור ברירת מחדל בשם default. Cloud Tasks לא יוצר את התור הזה באופן אוטומטי.

שימוש חוזר בשמות של תורים

צריך להמתין 7 ימים אחרי מחיקת תור כדי ליצור תור עם אותו מזהה תור באותו פרויקט ובאותו מיקום (כלומר, באותו אזור).

בדוגמה הבאה נוצרות שתי תורים באמצעות Cloud Tasks. לרשימת ההמתנה הראשונה יש מזהה רשימת המתנה queue-blue, והיא מוגדרת לשליחת כל המשימות לגרסה v2 של השירות task-module בקצב של 5/s. לתור השני יש מזהה תור queue-red והוא משבץ משימות בקצב של 1/s. שניהם נוצרים בפרויקט עם מזהה הפרויקט במיקום us-central1. זהו המקבילה ב-Cloud Tasks ליצירת תורים ב-Task Queues.

gcloud

ה-CLI של gcloud מסיק את הפרויקט והמיקום מתוך ההגדרות האישיות של ה-CLI של gcloud.

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

מידע נוסף זמין במאמר בנושא יצירת תור של 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. השדה הזה מאפשר לתור להגיע לקצב גבוה כדי שהעיבוד יתחיל זמן קצר אחרי שהמשימה תתווסף לתור, אבל עדיין מגביל את השימוש במשאבים כשמתווספות לתור הרבה משימות בפרק זמן קצר. בתורים של App Engine שנוצרו או עודכנו באמצעות קובץ, הערך של max_burst_size שווה בהתחלה לערך של bucket_size. עם זאת, אם התור יועבר בהמשך לפקודה update באמצעות ממשק Cloud Tasks כלשהו, הערך של max_burst_size יתאפס על סמך הערך של max_dispatches_per_second, בלי קשר לעדכון של max_dispatches_per_second.
total_storage_limit	הוצא משימוש ב-Cloud Tasks	ב-Cloud Tasks אין תמיכה בהגדרת מגבלת אחסון מותאמת אישית

אפשר להגדיר את קצב העיבוד של התור כשיוצרים את התור או כשמעדכנים אותו בהמשך. בדוגמה הבאה נעשה שימוש ב-Cloud Tasks כדי להגדיר את קצב העיבוד בתור שנקרא queue-blue שכבר נוצר. אם queue-blue נוצר או הוגדר באמצעות קובץ queue.yaml, הדוגמה הבאה מאפסת את max_burst_size על סמך הערך max_dispatches_per_second של 20. זהו הערך המקביל ב-Cloud Tasks להגדרת קצב העיבוד של התור ב-Task Queues.

gcloud

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

מידע נוסף זמין במאמר בנושא הגדרת מגבלות קצב.

השבתה והפעלה מחדש של תורים

ב-Cloud Tasks, המונח השהיה משמש באותו אופן שבו המונח השבתה משמש ב-Task Queues. השהיית התור מפסיקה את ביצוע המשימות בתור עד להמשך הפעלת התור. אבל אפשר להמשיך להוסיף משימות לתור שהושהה. ב-Cloud Tasks, המונח resume (המשך) משמש באותו אופן כמו ב-Task Queues.

בדוגמה הבאה מושהה תור עם מזהה התור queue1. זוהי הפעולה המקבילה ב-Cloud Tasks להשבתת תורים ב-Task Queues.

gcloud

gcloud tasks queues pause queue1

מידע נוסף זמין במאמר בנושא Cloud Tasks, בקטע השהיית תורים.

מחיקת תורים

אחרי שמוחקים תור, צריך להמתין 7 ימים לפני שיוצרים תור עם אותו שם. אם אתם לא יכולים לחכות 7 ימים, כדאי למחוק את כל המשימות מתור מסוים ולהגדיר מחדש את התור.

בדוגמה הבאה נמחקת התור עם מזהה התור queue1. זהו המקבילה ב-Cloud Tasks למחיקת תורים ב-Task Queues.

gcloud

gcloud tasks queues delete queue1

מידע נוסף זמין במאמר בנושא Cloud Tasks מחיקת תורים.

יצירה וניהול של משימות

בקטע הזה מוסבר איך ליצור משימות ולנהל אותן באמצעות Cloud Tasks API.

יצירת משימות

בטבלה הבאה מפורטים השדות ששונים בין Task Queues לבין Cloud Tasks.

השדה Task Queues (תורי משימות)	שדה Cloud Tasks	תיאור
לא רלוונטי	app_engine_http_request	יצירת בקשה שמיועדת לשירות App Engine. המשימות האלה נקראות משימות של App Engine.
method	http_method	מציינת את שיטת הבקשה, לדוגמה, POST
url	relative_uri	מציין את המטפל במשימה. שימו לב להבדל באות האחרונה: i במזהה משאבים אחיד במקום l במען משאבים אחיד
target	app_engine_routing	זה שינוי אופציונלי. מציינים את service,‏ version ו-instance של App Engine עבור משימת App Engine. אם לא מגדירים את המאפיין, המערכת משתמשת בגרסה, במופע ובשירות שמוגדרים כברירת מחדל.

בדוגמה הבאה נוצרת משימה שמופנית אל ה-handler‏ /update_counter בשירות ברירת המחדל של App Engine. זהו המקבילה ב-Cloud Tasks ליצירת משימות ב-Task Queues.

gcloud

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

מידע נוסף זמין במאמר בנושא יצירת משימות App Engine במאמרי העזרה של Cloud Tasks.

ציון שירות היעד והניתוב

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

מגדירים את המאפיין app_engine_routing של המשימה במהלך יצירת המשימה כדי לציין שירות, גרסה או מופע שונים של App Engine למשימה.

כדי להפנות את כל המשימות בתור מסוים לאותו שירות, גרסה ומופע של App Engine, אפשר להגדיר את המאפיין app_engine_routing_override בתור.

מידע נוסף זמין במאמר בנושא הגדרת ניתוב.

העברת נתונים אל ה-handler

בדומה לתורי משימות, אפשר להעביר נתונים ל-handler בשתי דרכים באמצעות Cloud Tasks. אפשר להעביר נתונים כפרמטרים של שאילתה ב-URI היחסי, או להעביר נתונים בגוף הבקשה באמצעות שיטות HTTP‏ POST או PUT.

ב-Cloud Tasks משתמשים במונח body באותו אופן שבו משתמשים במונח payload ב-Task Queues. ב-Cloud Tasks, סוג התוכן שמוגדר כברירת מחדל לגוף הבקשה הוא octet-stream ולא טקסט פשוט. אפשר להגדיר את סוג התוכן של גוף ההודעה על ידי ציון שלו בכותרת.

בדוגמה הבאה מועבר מפתח ל-handler‏ /update_counter בשתי דרכים שונות. זהו המקבילה ב-Cloud Tasks להעברת נתונים ל-handler בתורי משימות.

gcloud

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

מציינים את שם המשימה.

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

שמות המשימות הם בפורמט projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID/tasks/TASK_ID. החלק TASK_ID בשם המשימה שווה לשדה name של המשימה ב-Task Queues.

שימוש חוזר בשמות של משימות

צריך לחכות לפני שמשתמשים שוב בשם של משימה. משך הזמן שצריך להמתין לפני שמבצעים את הפעולה משתנה בהתאם לשאלה אם תור המשימות ששולח את המשימה נוצר ב-Cloud Tasks או ב-Task Queues.

לגבי משימות בתורים שנוצרו באמצעות Task Queues (כולל תור ברירת המחדל), צריך להמתין כ-9 ימים אחרי שהמשימה המקורית נמחקה או בוצעה. לגבי משימות בתורים שנוצרו באמצעות Cloud Tasks, צריך להמתין כשעה אחרי שהמשימה המקורית נמחקה או בוצעה.

בדוגמה הבאה נוצרת משימה עם הערך TASK_ID שמוגדר ל-first-try, והיא מתווספת לתור ברירת המחדל. זהו המקבילה ב-Cloud Tasks למתן שמות למשימות ב-Task Queues.

gcloud

ה-CLI של gcloud יוצר את שם המשימה על ידי הסקת הפרויקט והמיקום מההגדרות האישיות.

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

ניסיון חוזר של משימות שנכשלו

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

שימוש בפרמטרים ספציפיים למשימה לניסיון חוזר

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

בדוגמה הבאה מוצגים תרחישי ניסיון חוזר שונים:

• ב-fooqueue, המערכת מנסה לבצע מחדש משימות עד שבע פעמים, למשך עד יומיים מניסיון ההפעלה הראשון. אחרי שמגיעים לשתי המגבלות, הפעולה נכשלת באופן סופי.
• ב-barqueue,‏ App Engine מנסה לבצע מחדש משימות, ומגדיל את המרווח בין כל ניסיון חוזר באופן לינארי עד שמגיע להשהיה לפני ניסיון חוזר (backoff) המקסימלית, ואז מנסה שוב ללא הגבלה במרווח המקסימלי (כך שהמרווחים בין הבקשות הם 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

מידע נוסף זמין במאמר בנושא Cloud Tasks הגדרת פרמטרים של ניסיון חוזר.

מחיקת משימות מתור

כשמוחקים משימה, צריך לחכות 9 ימים לפני שיוצרים משימה עם אותו שם אם המשימה הייתה בתור שנוצר באמצעות קובץ queue.yaml, או שעה אחת אם המשימה הייתה בתור שנוצר באמצעות Cloud Tasks.

בדוגמה הבאה נמחקת המשימה עם מזהה המשימה foo מהתור עם מזהה התור queue1. זהו המקבילה ב-Cloud Tasks למחיקת משימות בתורי משימות.

gcloud

הפרויקט והמיקום של המשימה נגזרים מפרויקט ברירת המחדל של ה-CLI של gcloud.

gcloud tasks delete foo --queue=queue1

מידע נוסף זמין במאמר בנושא Cloud Tasks מחיקת משימה מתור.

מחיקה לצמיתות של משימות

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

gcloud

הפרויקט והמיקום של התור נגזרים מפרויקט ברירת המחדל של ה-CLI של gcloud.

gcloud tasks queues purge queue1

מידע נוסף זמין במאמר בנושא מחיקת כל המשימות מתור בתיעוד של Cloud Tasks.

המאמרים הבאים

• מאמרי העזרה של Cloud Tasks
• ספריית הלקוח של Cloud Tasks
• סקירה כללית על Cloud Tasks REST reference
• סקירה כללית של חומר עזר של Cloud Tasks RPC