בדף הזה מוסבר איך ליצור task handler ב-App Engine, שהוא קוד העובד שמטפל במשימה של App Engine. תור Cloud Tasks שולח בקשות HTTP ל-task handler. אחרי שהעיבוד מסתיים בהצלחה, ה-handler צריך לשלוח בחזרה לתור קוד סטטוס של HTTP בין 200 ל-299. כל ערך אחר מציין שהמשימה נכשלה והתור מנסה שוב לבצע את המשימה.
בקשות של תור המשימות של App Engine נשלחות מכתובת ה-IP 0.1.0.2.
אפשר גם לעיין בטווח כתובות ה-IP של בקשות שנשלחות לסביבת App Engine.
C#
המשך
Java
Node.js
PHP
Python
Ruby
חסימות זמניות
למשימות של App Engine יש הגדרות זמן קצוב לתפוגה ספציפיות, שמשתנות בהתאם לסוג ההתאמה לגודל של השירות שמריץ אותן.
לשירותי עובדים שפועלים בסביבה רגילה:
- התאמה אוטומטית לעומס (automatic scaling): עיבוד המשימה חייב להסתיים תוך 10 דקות.
- הגדלה ידנית ובסיסית: בקשות יכולות לפעול עד 24 שעות.
בשירותי Worker שפועלים בסביבת flex: כל הסוגים מוגבלים בזמן של 60 דקות.
אם המטפל לא יסיים את המשימה בזמן, התור יניח שהמשימה נכשלה וינסה לבצע אותה שוב.
קריאת כותרות של בקשות למשימות ב-App Engine
לבקשות שנשלחות ל-handler של App Engine מתור Cloud Tasks יש כותרות מיוחדות, שמכילות מידע ספציפי למשימה שה-handler עשוי להשתמש בו.
הכותרות האלה מוגדרות באופן פנימי. אם אחת מהכותרות האלה מופיעה בבקשה של משתמש חיצוני לאפליקציה, היא מוחלפת בכותרת הפנימית – למעט בקשות מאדמינים שמחוברים לאפליקציה, שמורשים להגדיר כותרות למטרות בדיקה.
בקשות למשימות ב-App Engine תמיד מכילות את הכותרות הבאות:
| כותרת | תיאור |
|---|---|
X-AppEngine-QueueName |
שם התור. |
X-AppEngine-TaskName |
השם ה "קצר" של המשימה, או, אם לא צוין שם כשנוצרה, מזהה ייחודי שנוצר על ידי המערכת. זהו הערך של my-task-id בשם המלא של המשימה. לדוגמה, task_name = projects/my-project-id/locations/my-location/queues/my-queue-id/tasks/my-task-id. |
X-AppEngine-TaskRetryCount |
מספר הפעמים שהמשימה ניסתה שוב. בניסיון הראשון, הערך הוא 0. המספר הזה כולל ניסיונות שבהם המשימה נכשלה בגלל חוסר במופעים זמינים, ולא הגיעה לשלב הביצוע. |
X-AppEngine-TaskExecutionCount |
מספר הפעמים שהמשימה בוצעה וקיבלה תגובה מהמטפל. מכיוון ש-Cloud Tasks מוחק את המשימה אחרי שמתקבלת תגובה מוצלחת, כל התגובות הקודמות של ה-handler הן כשלים. המספר הזה לא כולל כשלים שנובעים ממקרים שבהם לא היו מופעים זמינים. שימו לב: הערך של X-AppEngine-TaskExecutionCount יכול להיות שווה לערך של X-AppEngine-TaskRetryCount אם הוא מתעדכן לפני שמנסים להפעיל את הפונקציה. |
X-AppEngine-TaskETA |
בתחילה, השעה המקורית שנקבעה למשימה, שצוינה בשניות מאז 1 בינואר 1970. שימו לב שהערך הזה מייצג את זמן השילוח הצפוי. בניסיונות חוזרים, הערך מתעדכן קרוב יותר לשעה הנוכחית ואפשר להשתמש בו כדי למדוד את זמן האחזור של המסירה. אין להשתמש בו לביטול כפילויות של משימות. |
אם בקשת הטיפול מוצאת אחת מהכותרות שצוינו קודם, היא יכולה להניח שהבקשה היא בקשת Cloud Tasks.
בנוסף, בקשות מ-Cloud Tasks עשויות להכיל את הכותרות הבאות:
| כותרת | תיאור |
|---|---|
X-AppEngine-TaskPreviousResponse |
קוד תגובת ה-HTTP מהניסיון הקודם. |
X-AppEngine-TaskRetryReason |
הסיבה לניסיון החוזר של המשימה. |
X-AppEngine-FailFast |
מציין שמשימה נכשלת באופן מיידי אם מופע קיים לא זמין. |
ניתוב ליעד
במשימות של App Engine, גם התור וגם המטפל במשימות פועלים באותו Google Cloud פרויקט. התעבורה מוצפנת במהלך ההעברה ואף פעם לא יוצאת ממרכזי הנתונים של Google. אי אפשר להגדיר באופן מפורש את הפרוטוקול (למשל, HTTP או HTTPS). עם זאת, הבקשה ל-handler תופיע כאילו נעשה בה שימוש בפרוטוקול HTTP.
אפשר לשלוח משימות למטפלים מאובטחים במשימות, למטפלים לא מאובטחים במשימות ובזמני ריצה נתמכים, ל-URI שמוגבלים באמצעות login: admin.
מכיוון שהמשימות לא מופעלות כמשתמש כלשהו, אי אפשר לשלוח אותן לכתובות URI שמוגבלות באמצעות login: required.
גם בשליחת משימות אין מעקב אחרי הפניות אוטומטיות.
המאמרים הבאים
- מידע נוסף על משימות זמין במאמר בנושא הפניית API ל-RPC.
- מידע נוסף על משימות זמין בהפניית API בארכיטקטורת REST.