שימוש בקובץ queue.yaml לניהול תורים

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

‫Cloud Tasks API מספק ממשק עצמאי לשירות App Engine Task Queue. באמצעות הממשק הזה, אתם יכולים לנהל תורים דרך מסוף Google Cloud או Google Cloud CLI. לתורים שיוצרים באמצעות Cloud Tasks API יש גישה אל App Engine SDK – אוסף של ממשקי API ספציפיים לפלטפורמה, כלים עצמאיים וקבצים בזמן ריצה – ולתורים שנוצרים באמצעות App Engine SDK יש גישה אל Cloud Tasks API.

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

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

אם אתם משתמשים חדשים ב-Cloud Tasks או ב-App Engine, אתם צריכים להשתמש רק ב-Cloud Tasks API כדי לנהל את התורים, ולא להשתמש ב-queue.yaml. שיטות הניהול של תורי Cloud Tasks מספקות לכם יותר אפשרויות ליצירה, לעדכון ולמחיקה של תורים.

אם אתם משתמשים ב-queue.yaml, כדאי לעבור לשיטות ניהול תורים של Cloud Tasks רק אם אתם מבינים את הסיכונים בשילוב של שיטות ניהול תורים.

אכיפת שיטה לניהול תור

כדי למנוע שימוש בכמה שיטות לניהול תורים, אתם יכולים ליצור אפליקציית אינטרנט או כלי לשורת הפקודה כדי ליצור, לעדכן ולמחוק תורים. האם הכלי הזה משתמש בשיטות לניהול תורים של Cloud Tasks או ב-queue.yaml, זה פרט שקשור להטמעה והמשתמשים לא צריכים לדעת עליו. אפשר להגדיר שהשימוש בכלי יהיה חובה כדי לוודא שלא יהיה ערבוב לא מכוון של שיטות. מקצים לכלי את התפקיד Cloud Tasks Queue Admin (אדמין של תור Cloud Tasks) בניהול הזהויות והרשאות הגישה (IAM) ודורשים מהמשתמשים לבצע אימות. מידע נוסף על ניהול גישה זמין במאמר הגדרת תור מאובטח.

עיכובים בהגדרת התור

יכול להיות שיחלפו כמה דקות עד שהשינויים בהגדרות התור ייכנסו לתוקף. לדוגמה, אחרי שמתקשרים אל CreateQueue או אל UpdateQueue, יכול להיות שיחלפו כמה דקות לפני שתוכלו להתקשר בהצלחה אל CreateTask בתור הזה.

תור default של App Engine

התור App Engine שנקרא default מקבל יחס מיוחד ב-App Engine SDK וב-Cloud Tasks API.

מתי נוצר התור default?

אם תור ההמתנה default לא קיים, הוא נוצר במצבים הבאים:
  • כשמוסיפים משימה לראשונה לתור default באמצעות App Engine SDK
  • כשמעלים קובץ queue.yaml שמציין תור default
  • כשמתקשרים אל CreateQueue או אל UpdateQueue כדי ליצור את התור default
אילו הגבלות נאכפות ב-Cloud Tasks?

כדי לשמור על תאימות ל-App Engine,‏ Cloud Tasks אוכף את ההגבלות האלה לגבי התור default:
  • ‫Cloud Tasks API לא יוצר באופן אוטומטי את התור default או תור אחר
  • אם נוצר תור בשם default, הוא חייב להיות תור באמצעות משימות App Engine
  • הפעלת הפונקציה GetQueue בתור default מחזירה שגיאה not found אם התור עדיין לא קיים.
  • תור ההשמעה default לא מופיע בפלט ListQueues עד שהוא נוצר
  • אפשר לשנות את הגדרת התור default באמצעות הקריאה UpdateQueue
  • אחרי שיוצרים את התור default, אי אפשר למחוק אותו

הסיכונים בשימוש בכמה שיטות לניהול תורים

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

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

תרחיש 1

מפעילים את הפקודה CreateQueue כדי ליצור תור בשם cloud-tasks-queue ואז מעלים קובץ queue.yaml עם התוכן הבא:

queue:
- name: queue-yaml-queue

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

  • התור בשם cloud-tasks-queue וכל התורים הקיימים האחרים נמצאים במצב DISABLED.
  • התור שנקרא queue-yaml-queue נמצא במצב RUNNING.

תרחיש 2

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

תרחיש 3

אתם מוחקים תור באמצעות המתודה DeleteQueue, והוא מופיע מאוחר יותר בקובץ queue.yaml. יכול להיות שההעלאה של queue.yaml תיכשל כי אי אפשר לעשות שימוש חוזר בשמות של תורים במשך כמה ימים אחרי המחיקה.

ניפוי באגים באמצעות יומני ביקורת

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

לדוגמה, אם העלאה של queue.yaml משביתה תור קיים, אפשר להריץ את הפקודה הבאה כדי להחזיר הודעת יומן של Disabled queue QUEUE_NAME באמצעות השיטה com.google.appengine.legacy.queue_updated:

gcloud logging read \
  'protoPayload.methodName=
   (com.google.appengine.legacy.queue_created OR
    com.google.appengine.legacy.queue_updated OR
    google.cloud.tasks.v2.CloudTasks.CreateQueue OR
    google.cloud.tasks.v2.CloudTasks.UpdateQueue OR
    google.cloud.tasks.v2.CloudTasks.DeleteQueue)'

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

המשך הפעלת "הבאים בתור" שהושבתה בגלל העלאה של queue.yaml

אם משלבים שיטות לניהול תורים, יכול להיות שכשמעלים קובץ queue.yaml משביתים בטעות תור שנוצר באמצעות Cloud Tasks API. כדי להמשיך את התור, אפשר להתקשר אל ResumeQueue בתור או להוסיף אותו אל queue.yaml ולהעלות אותו.

אם הגדרתם בעבר rate עיבוד מותאם אישית בqueue.yaml, ResumeQueue מאפס את התור לrate ברירת המחדל. המידע הזה מופיע בשדה maxDispatchesPerSecond בתגובה לבקשת ResumeQueue.

פתרון בעיות שקשורות למכסות

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

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

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