בדף הזה מוסבר איך להעביר קוד של תור משימות מסוג pull מ-Task Queues ל-Pub/Sub. Pub/Sub היא עכשיו הדרך המומלצת לבצע עבודה בתור לשליפה ב-App Engine.
אם האפליקציה שלכם משתמשת גם בתורי משיכה וגם בתורי דחיפה, כדאי להשתמש במדריך הזה כדי להעביר את תורי המשיכה ל-Pub/Sub לפני שתעבירו את תורי הדחיפה לשירות החדש של תורי דחיפה Cloud Tasks. לא מומלץ להעביר את תורי ההמתנה למשיכות אחרי העברת תורי ההמתנה לדחיפות אל Cloud Tasks, כי השימוש הנדרש בקובץ queue.yaml עלול לגרום להתנהגות בלתי צפויה ב-Cloud Tasks.
תכונות שלא זמינות כרגע ב-Pub/Sub
התכונות הבאות של תורי משימות לא זמינות כרגע ב-Pub/Sub:
- הוספה לקבוצה לפי תג
- ביטול כפילויות אוטומטי
תמחור ומכסות
העברת תורי שליפה ל-Pub/Sub עשויה להשפיע על התמחור והמכסות של האפליקציה.
תמחור
ל-Pub/Sub יש תמחור משלו. בדומה ל-Task Queues, שליחת בקשות לאפליקציית App Engine באמצעות Pub/Sub עלולה לגרום להצטברות עלויות באפליקציה.
מכסות
המיכסות של Pub/Sub שונות מהמיכסות של Task Queues. בדומה לתורי משימות, שליחת בקשות לאפליקציית App Engine מ-Pub/Sub עשויה להשפיע על מכסות הבקשות של App Engine.
לפני ההעברה
אם עדיין לא עשיתם זאת, צריך להגדיר את סביבת הפיתוח בשפת Python כך שתשתמש בגרסת Python שתואמת ל- Google Cloud, ולהתקין כלי בדיקה ליצירת סביבות Python מבודדות.בקטעים הבאים מפורטים שלבי ההגדרה לפני העברת תורי ההמתנה למשיכות ל-Pub/Sub.
הפעלת Pub/Sub API
כדי להפעיל את Pub/Sub API, לוחצים על Enable ב-Pub/Sub API ב-API Library. אם מופיע לחצן Manage במקום לחצן Enable, סימן שהפעלתם בעבר את Pub/Sub API בפרויקט, ואין צורך לעשות זאת שוב.
אימות האפליקציה ב-Pub/Sub API
צריך לאמת את האפליקציה ב-Pub/Sub API. בקטע הזה נדון באימות בשני תרחישים שונים לדוגמה.
כדי לפתח או לבדוק את האפליקציה באופן מקומי, מומלץ להשתמש בחשבון שירות. הוראות להגדרת חשבון שירות ולחיבור שלו לאפליקציה מופיעות במאמר קבלת פרטי כניסה לחשבון שירות וצירופם באופן ידני.
כדי לפרוס את האפליקציה ב-App Engine, לא צריך לספק אימות חדש. פרטי האימות של אפליקציות App Engine מוסקים מ-Application Default Credentials (ADC).
הורדת Google Cloud CLI
הורידו והתקינו את Google Cloud CLI כדי להשתמש ב-ה-CLI של gcloud עם Pub/Sub API אם לא התקנתם אותו בעבר. אם כבר התקנתם את Google Cloud CLI, מריצים את הפקודה הבאה מהטרמינל.
gcloud components update
ייבוא ספריות לקוח של Cloud
כדי להשתמש בספריית הלקוח של Python ב-Pub/Sub באפליקציית App Engine קיימת, פועלים לפי השלבים הבאים:
מעדכנים את הקובץ
app.yaml. פועלים לפי ההוראות שמתאימות לגרסת Python:Python 2
באפליקציות Python 2, מוסיפים את הגרסאות האחרונות של ספריית
grpcio.קובץ
app.yamlלדוגמה:runtime: python27 threadsafe: yes api_version: 1 libraries: - name: grpcio version: latestPython 3
באפליקציות Python 3, מציינים את הרכיב
runtimeבקובץapp.yamlעם גרסה נתמכת של Python 3. לדוגמה:runtime: python310 # or another support versionסביבת זמן הריצה של Python 3 מתקינה ספריות באופן אוטומטי, כך שלא צריך לציין ספריות מובנות מסביבת זמן הריצה הקודמת של Python 2. אם האפליקציה שלכם ב-Python 3 משתמשת בשירותים אחרים מדור קודם שכלולים בחבילה במהלך ההעברה, אתם יכולים להמשיך לציין את הספריות המובנות הנדרשות. אחרת, אפשר למחוק את השורות המיותרות בקובץ
app.yaml.מעדכנים את הקובץ
requirements.txt. פועלים לפי ההוראות שמתאימות לגרסת Python:Python 2
מוסיפים את ספריות הלקוח של Cloud Pub/Sub לרשימת התלויות בקובץ
requirements.txt.google-cloud-pubsubלאחר מכן מריצים את הפקודה
pip install -t lib -r requirements.txtכדי לעדכן את רשימת הספריות שזמינות לאפליקציה.Python 3
מוסיפים את ספריות הלקוח של Cloud Pub/Sub לרשימת התלויות בקובץ
requirements.txt.google-cloud-pubsubApp Engine מתקין באופן אוטומטי את התלות האלה במהלך פריסת האפליקציה בסביבת זמן הריצה של Python 3, לכן צריך למחוק את התיקייה
libאם היא קיימת.באפליקציות Python 2, אם האפליקציה משתמשת בספריות מובנות או בספריות שהועתקו, צריך לציין את הנתיבים האלה בקובץ
appengine_config.pyשנמצא באותה תיקייה כמו קובץapp.yaml:import pkg_resources from google.appengine.ext import vendor # Set PATH to your libraries folder. PATH = 'lib' # Add libraries installed in the PATH folder. vendor.add(PATH) # Add libraries to pkg_resources working set to find the distribution. pkg_resources.working_set.add_entry(PATH)בדוגמה שלמעלה, הקובץ
appengine_config.pyמניח שספריית העבודה הנוכחית היא המקום שבו נמצאת התיקייהlib. במקרים מסוימים, כמו בדיקות יחידה, ספריית העבודה הנוכחית יכולה להיות שונה. כדי להימנע משגיאות, אפשר להעביר באופן מפורש את הנתיב המלא לתיקייהlibבאמצעות:import os path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
מייבאים את ספריית הלקוח של Pub/Sub Python לכל הקבצים שמשתמשים בתורי משימות של Task Queues API:
from google.cloud import pubsub
תורים של Pub/Sub ושל שליפה
השוואה בין תכונות
Pub/Sub שולח עבודה לעובדים דרך קשר של מפרסם/מנוי. מינוי מסוג pull ב-Pub/Sub דומה לתור pull ב-Task Queues, כי המנוי מושך את ההודעה מהנושא. בטבלה שבהמשך מפורטת התכונה העיקרית של תורי משיכה (pull queue) ב-Task Queues, והתכונה המקבילה של מינויי שליפה ב-Pub/Sub.
| התכונה 'תורי משימות' | תכונת Pub/Sub |
|---|---|
| תור | נושא |
| משימה | הודעה |
| קובץ שירות | משתמש רשום |
מידע נוסף על ארכיטקטורת Pub/Sub זמין במאמר Cloud Pub/Sub: שירות העברת הודעות עם מלוא היכולות של Google.
השוואה בין תהליכי עבודה
בהמשך מוצגת השוואה בין תהליך עבודה אופייני לתור משימות מסוג pull ב-Task Queues לבין מינוי מסוג pull ב-Pub/Sub.
| תהליך העבודה עם תורי משימות | זרימת עבודה ב-Pub/Sub |
|---|---|
| אתם יוצרים את תור ההמתנה למשיכת נתונים | יוצרים את הנושא ומצרפים אליו את המשתמש הרשום (כלומר, העובד) |
| יוצרים את המשימה ומכניסים אותה לתור | יוצרים את ההודעה ומפרסמים אותה בנושא |
| העובד שוכר את המשימה | המנוי מושך את ההודעה מהנושא |
| העובד מעבד את המשימה | המנוי מעבד את ההודעה |
| העובד מוחק את המשימה מהתור | המנוי מאשר את ההודעה |
| החוזה יפוג | הנושא מוחק את ההודעה כשכל המנויים שלו אישרו את קבלת ההודעה. |
יצירת מינויים לשליפה ב-Pub/Sub
אפשר להשתמש במינוי pull של Pub/Sub כמו בתור pull של תורי משימות. המינויים לנושא לא פוקעים, ויכולים להתקיים בו-זמנית בכמה עובדים. כלומר, הודעה יכולה לעבור עיבוד על ידי יותר מעובד אחד, וזה אחד מתרחישי השימוש העיקריים ב-Pub/Sub. כדי ליצור מחדש את תורי המשימות שלכם כמנויים לשליפה של Pub/Sub, צריך ליצור נושא לכל עובד ולהירשם רק לעובד המשויך לנושא. כך אפשר לוודא שכל הודעה תעובד על ידי עובד אחד בלבד, כמו בתורי משימות. מידע על יצירה וניהול של מינויי שליפה זמין במאמר בנושא ניהול נושאים ומינויים.
מחיקת תורים להעברת נתונים
אחרי שמעבירים את תורי המשימות שלכם לתורי משימות של Pub/Sub, צריך למחוק אותם מתורי המשימות באמצעות קובץ ה-queue.yaml. מומלץ למחוק כל תור משיכה (pull queue) לפני העברת התור הבא. כך האפליקציה לא תשכפל את העבודה שהיא מקבלת מהמינוי החדש של Pub/Sub pull בזמן שאתם מעבירים את תורי ההמתנה האחרים של pull. שימו לב: מחיקה של תורי משימות מסוג pull אחד בכל פעם, במקום פריסה אחת, עשויה להשפיע יותר על מכסת הפריסה של App Engine.
אחרי שמוחקים את כל תורי ההמתנה לשליפה מ-Task Queues, אפשר להשמיט את הקובץ queue.yaml מהפריסות העתידיות של האפליקציה.
אם האפליקציה שלכם משתמשת רק בתורים של משיכות, צריך להסיר מהקוד את כל ההפניות אל Task Queues API. אם האפליקציה משתמשת גם בתורים מסוג pull וגם בתורים מסוג push, אפשר להסיר את ההפניות ל-Task Queues API שמופיעות בקבצים שמשתמשים רק בתורים מסוג pull, או לחכות עד שתבצעו גם את ההעברה של התורים מסוג push ואז להסיר את ההפניות ל-Task Queues API מכל הקבצים.
המאמרים הבאים
- מסמכי Pub/Sub
- העברת תורים של הודעות Push
- מדריך מעשי בנושא זמין במאמר Migrate from App Engine Task Queue pull queues to Pub/Sub codelab.