בעיות מוכרות בסביבה הגמישה של App Engine

מזהה אזור

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, המחרוזת REGION_ID.r כלולה בכתובות ה-URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

מידע נוסף על מזהי אזורים

אישור

רשימה מלאה של בעיות מוכרות ודיווח על בעיה חדשה זמינים בכלי למעקב אחרי בעיות.

• אחרי שמפעילים את האפליקציה באמצעות gcloud app deploy, יכול להיות שתצטרכו לחכות דקה או שתיים עד שהאפליקציה תתחיל לפעול בכתובת https://PROJECT_ID.REGION_ID.r.appspot.com. עד אז, יכול להיות שיוצגו שגיאות HTTP 503.

  לעתים קרובות, שגיאות כאלה נרשמות ביומנים של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) ב-App Engine כ-backend_timeout או כ-failed_to_pick_backend. מאזן העומסים הגלובלי החיצוני של אפליקציות שולח בקשות לשירות בסביבה הגמישה של App Engine, בלי קשר למצב התקינות של מופעים ספציפיים. אחרי פריסת גרסה חדשה, לוקח זמן עד שמאזן העומסים הגלובלי החיצוני של אפליקציות מעדכן את ההגדרה שלו עם מופעי הבק-אנד החדשים. במהלך המעבר הזה, הזמינות של שירותי הבק-אנד לא עקבית. כשמעבירים תעבורה לגרסה החדשה, מאזן העומסים הגלובלי החיצוני של אפליקציות עשוי לנסות לשלוח תעבורה למופעים שלא מוכנים לגמרי לקבל בקשות, וכתוצאה מכך מתקבלות שגיאות 503. יכול להיות שיתקבלו גם שגיאות 502, במיוחד כשמשתמשים במאזן עומסים קלאסי של אפליקציות.

• אם יש מדיניות ארגונית בפרויקט שמגבילה את הגישה לכתובות IP חיצוניות, לא תוכלו לפרוס אפליקציה של סביבה גמישה ב-App Engine עם כתובות IP חיצוניות. לדוגמה, מדיניות הארגון יכולה להיראות כך:

  • המדיניות שבתוקף לגבי constraints/compute.vmExternalIpAccess מוגדרת כ-DENY_ALL.
  • המדיניות האפקטיבית עבור constraints/compute.vmExternalIpAccess מוגדרת כך שתאפשר רק למכונות וירטואליות ספציפיות.
  • המדיניות שבתוקף לגבי constraints/compute.requireOsConfig מושבתת בפרויקט כדי למנוע עדכונים של מטא-נתונים.

  המערכת לא מזהה את המגבלות האלה באופן אוטומטי, ויכול להיות שהפריסות ייכשלו בגלל חריגה מזמן קצוב לתפוגה. כדי לבדוק את מדיניות הארגון של הפרויקט, מריצים את הפקודה gcloud beta resource-manager org-policies describe compute.vmExternalIpAccess --project=my-project --effective. אפשר גם לשנות את מדיניות הארגון עבור פרויקט ספציפי.

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

• אחרי שפורסים גרסה חדשה של שירות קיים בסביבה הגמישה של App Engine עם gcloud app deploy, יכול להיות שהמדד 'ספירה/שנייה' שמוצג בתרשים 'סיכום' בלוח הבקרה של App Engine ירד באופן משמעותי. המדד יחזור בהדרגה למספר הבקשות הצפוי ב-5 עד 10 הדקות הבאות.

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

  כדי לוודא שהמדד הזה לא מושפע מפריסת גרסה חדשה:

  1. פורסים את הגרסה החדשה באמצעות gcloud app deploy --no-promote.
  2. מחכים 15 דקות אחרי שהפריסה מסתיימת.
  3. העברת התנועה לגרסה החדשה.

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

• בסביבה הגמישה של App Engine, אי אפשר להגדיר את app.yaml כך שהאפליקציה תפנה אוטומטית בקשות לשימוש ב-HTTPS. זה שונה מהסביבה הרגילה של App Engine, שבה אפשר להשתמש בהגדרה secure.

  לחלופין, אפשר לטפל בהפניה האוטומטית בתוך קוד האפליקציה על ידי ניתוח הערך של הכותרת X-Forwarded-Proto. אפשר גם לעודד לקוחות להשתמש בכותרת Strict-Transport-Security.

• אם מקצים חשבון שירות שמנוהל על ידי המשתמש לגרסה של סביבה גמישה ב-App Engine, יכול להיות שהפרויקט יחויב על מדדים עם הקידומת agent.googleapis.com. בדרך כלל, הפרויקט לא מחויב על מדדי הסוכן האלה. מומלץ להמשיך להשתמש בחשבון השירות שמשמש כברירת המחדל של App Engine עד שהבעיה הזו תיפתר.

• אי אפשר ליצור חיבור SSH למופע של מכונה וירטואלית באמצעות IAP.

הפחתה לא צפויה במספר המופעים

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

  1. השקת עדכונים למופעים של סביבה גמישה
  2. כשל אזורי (בעיות במלאי, למשל כשהאזור הגיע לקיבולת המקסימלית של המעבד שבחרתם וכו')

  בסביבה גמישה של App Engine נעשה שימוש ב-3 אזורים כדי להפיץ את המכונות שלכם, ובמקרה כזה מומלץ להקצות 50% יותר מכונות מהנדרש.

מדדים לא עקביים של Cloud Load Balancing

בלוח הבקרה של הסביבה הגמישה של App Engine מוצגים כל המדדים רק לבקשות שמנותבות דרך קצה עורפי שמנוהל על ידי סביבה גמישה. אם אתם משתמשים בסביבה הגמישה של App Engine עם Cloud Load Balancing, מדדים מסוימים בטבלת המדדים של App Engine מדווחים כמדדים מהטבלה loadbalancing. מידע נוסף זמין במאמר בנושא רישום ביומן ומעקב של איזון עומסים ב-HTTP(S).

‫InterruptedException ב-runtimes באמצעות JVM במהלך כשל בבדיקת התקינות

כשבדיקת תקינות נכשלת, מכונת ה-VM מושבתת. כסימפטום לכך שמסגרת האפליקציה הופכת ללא תקינה, ה-JVM מגיב בשגיאות InterruptedException ו-NullPointerException. ה-handler יכול להגיב לאות SIGTERM שנשלח על ידי הקונטיינר במהלך הכיבוי, כדי לבצע פעולות ניקוי או ניפוי באגים שנדרשות, וכך למנוע חריגים.