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

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

מבוא

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

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

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

למשל, נבחן את התרחיש הבא:

  1. קוראים ל-CreateQueue כדי ליצור תור בשם cloud-tasks-queue.

  2. מעלים קובץ queue.yaml עם התוכן הבא:

    queue:
- name: queue-yaml-queue

מה המצב הנוכחי של התורים בפרויקט הזה? התור שנקרא cloud-tasks-queue ותורים אחרים שהיו קיימים לפני כן נמצאים במצב DISABLED, והתור שנקרא queue-yaml-queue נמצא במצב RUNNING.

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

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

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

שיטות מומלצות

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

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

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

ניפוי באגים

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

    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_NAME] הושבת' תופיע ביומן הביקורת באמצעות השיטה com.google.appengine.legacy.queue_updated.

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

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

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

מכסות

אם אתם משתמשים ב-queue.yaml כדי ליצור תורים, כברירת מחדל אתם יכולים ליצור עד 100 תורים. כברירת מחדל, אפשר ליצור עד 1,000 תורים באמצעות Cloud Tasks API. כמו במקרים אחרים, שימוש משולב ב-queue.yaml וב-methods של Cloud Tasks API עלול להניב תוצאות לא צפויות. לדוגמה, נניח שאתם יוצרים כמה תורים באמצעות queue.yaml, ואז מקבלים הגדלה של המכסה ל-2,000, למשל. אם לאחר מכן תשתמשו בשיטה של Cloud Tasks API ליצירת תורים נוספים, תקבלו שגיאות על חריגה מהמכסה. כדי לפתור את הבעיה, צריך להגיש בקשה באמצעות Edit Quotas בדף Quotas של Google Cloud המסוף.

מידע נוסף על שיטות לניהול תורים ב-Cloud Tasks

הגדרת תור והשהיית ההפעלה של התור

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

‫Cloud Tasks ותור default App Engine

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

אם התור default לא קיים, הוא נוצר במקרים הבאים:

  1. כשמוסיפים משימה לdefaultתור באמצעות App Engine SDK.
  2. כשמעלים קובץ queue.yaml שמציין תור default.
  3. כשמתקשרים אל CreateQueue או אל UpdateQueue כדי ליצור את התור default.

כדי לשמור על תאימות ל-App Engine, ב-Cloud Tasks נאכפות ההגבלות הבאות:

  1. אם יוצרים תור בשם default, הוא חייב להיות תור שמשתמש במשימות של App Engine.
  2. אחרי שיוצרים תור, המשתמשים לא יכולים למחוק את התור default.

ב-Cloud Tasks API, ההגבלות הבאות חלות גם על התור default:

  1. ‫Cloud Tasks API לא יוצר באופן אוטומטי את התור default או תורים אחרים.
  2. בדומה לכל תור אחר, קריאה ל-GetQueue בתור default תגרום לשגיאה 'לא נמצא' אם הקריאה תתבצע לפני יצירת התור.
  3. באופן דומה, התור default לא מופיע בפלט של ListQueues לפני שהוא נוצר.
  4. אפשר לשנות את ההגדרה של התור default באמצעות הקריאה UpdateQueue.

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