בעיות מוכרות בסביבה הגמישה של 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) בתור 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 במהלך כשל בבדיקת התקינות

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