פתרון בעיות בהצגת נכסים ב-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 [e-mail].

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

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

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

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

1. משתמשים ב-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.

2. מריצים את הפקודה הבאה כדי לייצא את כתובת ה-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.

3. יוצרים קונטיינר חדש עם כתובת ה-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`
   

4. ייצוא של מערכת הקבצים הבסיסית (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
   

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

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

   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. שגיאת nginx 502 שמופיעה מיד אחרי nginx.error, היא כנראה הסיבה לשגיאת nginx 502.

השגיאה הזו מתרחשת לעיתים קרובות כשזמן הקצוב לתפוגה של שמירת החיבור בחיים באפליקציה קצר יותר מזמן הקצוב לתפוגה של שמירת החיבור בחיים ב-nginx. ב-nginx בסביבה הגמישה של App Engine, הערך של keepalive_timeout הוא 650 שניות, ולכן האפליקציות צריכות לשמור את החיבורים בחיים למשך הזמן הזה לפחות. כברירת מחדל, הערך של keepAliveTimeout באפליקציות Node.js הוא 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% ממספר החיבורים הפעילים.

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

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

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