פתרון בעיות בהצגת נכסים ב-App Engine

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

שגיאת הרשאה כשיוצרים אפליקציה באמצעות חשבון השירות שמוגדר כברירת מחדל

כשיוצרים אפליקציה אחרי שמפעילים את App Engine API בפעם הראשונה, יכול להיות שהפעולה תיכשל ויוצגו השגיאות הבאות:

‫CLI של gcloud

An internal error occurred while calling service consumer manager for service account.
Creating  App Engine application in projectPROJECT and REGION....failed. DEBUG: (gcloud.app.create) Error Response: [13] an internal error has occurred

יומני בקשות

Service account creation is not allowed on this project.

המסוף

Error while initialising App Engine.

השגיאה הזו עשויה להתרחש בגלל האכיפה של אילוץ מדיניות הארגון constraints/iam.disableServiceAccountCreation כשיוצרים את האפליקציה. המדיניות הזו מונעת את הקצאת חשבון השירות שמשמש כברירת מחדל של App Engine PROJECT_ID@appspot.gserviceaccount.com.

כדי לפתור את הבעיה, צריך להסיר באופן זמני את אילוץ מדיניות הארגון constraints/iam.disableServiceAccountCreation כדי לאפשר את היצירה והפריסה של חשבון השירות שמוגדר כברירת מחדל ב-App Engine. חשבון השירות שמוגדר כברירת מחדל נחוץ ליצירת האפליקציה, ואי אפשר לדלג על השלב הזה. ההגבלה הזו חלה גם כשמשתמשים בחשבון שירות לכל גרסה. אפשר למחוק את חשבון השירות של App Engine שמוגדר כברירת מחדל או להחליף אותו בחשבון שירות שיוצרים אחרי פריסה מוצלחת.

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

האפליקציה לא מציגה את השינויים האחרונים בקוד

אם האפליקציה לא מציגה את השינויים האחרונים בקוד אחרי ה-Deployment (פריסה), אפשר להשתמש במערכת הקבצים הבסיסית של הקונטיינר כדי לבדוק את התוכן. השלבים הבאים לפתרון בעיות מוסבר איך לאחזר את קובץ אימג' של קונטיינר ולייצא את מערכת קבצי הבסיס לניתוח נוסף:

משתמשים ב-Cloud Logging כדי לקבל את כתובת ה-URL של קובץ האימג' של הקונטיינר, עם המסנן GAE_FULL_APP_CONTAINER. אחרי שמחילים את המסנן, Cloud Logging מציג את כתובת ה-URL של קובץ אימג' של קונטיינר, עם שם הדומיין המוגדר במלואו (FQDN). לדוגמה: GAE_FULL_APP_CONTAINER: FQDN/PROJECT_ID/appengine/SERVICE_NAME.VERSION_ID@sha256:SHA256_DIGEST.
מריצים את הפקודה הבאה כדי לייצא את כתובת ה-URL של קובץ אימג' של קונטיינר:
```
export IMAGE_URL='FQDN/PROJECT_ID/appengine/SERVICE_NAME.VERSION_ID@sha256:SHA256_DIGEST'
```
מחליפים את:
- ‫FQDN בשם הדומיין שמוגדר במלואו של כתובת ה-URL של קובץ אימג' של קונטיינר.
- ‫PROJECT_ID במזהה הפרויקט של הפרויקט. Google Cloud
- ‫SERVICE_NAME מחליפים בשם השירות.
- ‫VERSION_ID עם מזהה הגרסה של השירות.
- ‫SHA256_DIGEST עם הערך SHA256.

יוצרים קונטיינר חדש עם כתובת ה-URL של קובץ אימג' של קונטיינר:

docker pull ${IMAGE_URL}
export CONTAINER_ID=$(docker create ${IMAGE_URL})
docker ps -a # the list should contain the newly created container with status `Created`

מייצאים את מערכת הקבצים הבסיסית (rootfs) של קובץ האימג' של הקונטיינר:
```
 docker export ${CONTAINER_ID} -o gae_app.tar
 mkdir gae_app
 mv -v gae_app.tar gae_app/
 cd gae_app/
 tar -xf gae_app.tar
 ls -la # inspect the container FS
```
לחלופין, אם לא צריך את הקובץ TAR, מריצים את הפקודה הבאה:
```
  mkdir gae_app
  cd gae_app/
  docker export ${CONTAINER_ID} | tar -xC <dest>
  ls -la # inspect the container FS
```
מנתחים את התוכן של מערכת קבצי הבסיס כדי לוודא ששינויי הקוד האחרונים קיימים.

מריצים את הפקודה הבאה כדי לנקות את התמונה:

docker container rm ${CONTAINER_ID}
docker image rm ${IMAGE_URL}
unset IMAGE_URL CONTAINER_ID

החיבור או יצירת הקשר של Nginx עם מאגר האפליקציות נכשלים

השגיאה הבאה מתרחשת רק בסביבה הגמישה של App Engine, ובדרך כלל מוחזרות שגיאות 502 מיד אחרי השגיאה:

recv() failed (104: Connection reset by peer) while reading response header from upstream

השגיאה הזו מציינת ש-nginx reverse proxy (nginx sidecar) לא מצליח להגיע למאגר האפליקציות. ביומנים, אפשר להשוות בין התזמון של השגיאה 502 ביומן של nginx לבין התזמון של היומן nginx.error. שגיאת nginx 502 שמופיעה מיד אחרי שגיאת nginx.error, היא כנראה הסיבה לשגיאת nginx 502.

השגיאה הזו מתרחשת לעיתים קרובות כשהזמן הקצוב לתפוגה של חיבור פעיל באפליקציה קצר יותר מהזמן הקצוב לתפוגה של חיבור פעיל ב-nginx. בסביבה הגמישה של App Engine, ל-nginx יש keepalive_timeout של 650 שניות, ולכן האפליקציות צריכות לשמור על חיבורים פעילים למשך הזמן הזה לפחות. כברירת מחדל, לאפליקציות Node.js יש keepAliveTimeout של 5,000 אלפיות השנייה. במקרה כזה, אפשר להגדיר את server.keepAliveTimeout ל-700,000 אלפיות השנייה.

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

אין מספיק זיכרון

השגיאה הבאה של חוסר זיכרון מתרחשת בסביבה הגמישה של App Engine, ובדרך כלל מוחזרת עם שגיאות 502:

kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

השגיאה הזו מציינת ש-App Engine הפסיק את האפליקציה.

השגיאה הזו מתרחשת כשאין מספיק זיכרון במופע. כברירת מחדל, בסביבה גמישה של App Engine יש 1GB של זיכרון, ורק 600MB זמינים למאגר האפליקציות.

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

אין מספיק חיבורים פתוחים לטיפול בבקשות נכנסות

יכול להיות שבאפליקציות תופיע שגיאה 502 אם המספר המקסימלי של חיבורים בהמתנה שווה ל-75% ממספר החיבורים הפעילים או גדול ממנו.

כדי לפתור את הבעיה, צריך לבדוק אם המדדים של Cloud Monitoring קטנים או שווים ל-75% ממספר החיבורים הפעילים.

מגבלת חיבורים של Nginx worker

בסביבה הגמישה של App Engine, ל-Nginx proxy יש מגבלה של 4,096 חיבורי עובדים לכל מופע. אם האפליקציה חורגת מהמגבלה הזו, יכול להיות שתיתקלו בשגיאות 502.

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

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