בדיקה ופריסה של האפליקציה

מזהה אזור

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

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

בקורס תלמדו איך להריץ את האפליקציה באופן מקומי, לפרוס אותה ולבדוק אותה ב-App Engine.

הרצה באופן מקומי

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

python main.py

מפעילים אפליקציות Django באמצעות:

python manage.py runserver

כדי לדמות סביבת ייצור של App Engine, אתם יכולים להריץ את ממשק כניסה לשרתי אינטרנט ‏ (WSGI) המלא באופן מקומי. משתמשים באותה פקודה שצוינה כ-entrypoint בקובץ app.yaml, לדוגמה:

gunicorn -b :$PORT main:app

פריסת האפליקציה

פורסים את האפליקציה ב-App Engine באמצעות הפקודה gcloud app deploy.

שירות Cloud Build יוצר באופן אוטומטי את הפריסה שלכם כקובץ אימג' של קונטיינר ופורס את קובץ האימג' בסביבה הגמישה של App Engine. הקונטיינר כולל את כל השינויים המקומיים שביצעתם בקובץ האימג' של סביבת זמן הריצה.

כדי לפרוס את האפליקציות באופן פרוגרמטי, צריך להשתמש ב-Admin API.

לפני שמתחילים

לפני שפורסים את האפליקציה:

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

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

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

אם הפריסה נכשלת, צריך לוודא ש-Cloud Build API מופעל בפרויקט. ‫App Engine מפעיל את ה-API הזה באופן אוטומטי בפעם הראשונה שפורסים אפליקציה, אבל אם מישהו השבית את ה-API מאז, הפריסות ייכשלו.

פריסת שירות

כדי לפרוס את האפליקציה ב-App Engine, פורסים גרסאות של השירותים של האפליקציה ושל כל אחד מקובצי ההגדרות שלהם.

כדי לפרוס את השירות של האפליקציה, מריצים את הפקודה הבאה מהספרייה שבה נמצא הקובץ app.yaml של השירות:

gcloud app deploy

כברירת מחדל, הפקודה gcloud app deploy פורסת רק את הקובץ app.yaml בספרייה הנוכחית. בכל פעם שמריצים את הפקודה הזו, App Engine יוצר מזהה ייחודי לגרסה שפורסים, פורס את הגרסה בפרויקטGoogle Cloud שהגדרתם לשימוש ב-CLI של gcloud ומנתב את כל התנועה לגרסה החדשה. הגרסה החדשה הופכת לגרסת ברירת המחדל.

אפשר לשנות את התנהגות ברירת המחדל של פקודת הפריסה על ידי בחירת קבצים ספציפיים, ציון גרסאות או הוספת פרמטרים נוספים:

  • אפשר לפרוס את קבצי ההגדרות האחרים של השירות על ידי טירגוט ופריסה של כל קובץ בנפרד, למשל:

    gcloud app deploy cron.yaml
gcloud app deploy dispatch.yaml
gcloud app deploy index.yaml

  • כדי לציין מזהה גרסה מותאם אישית, משתמשים בדגל --version.

  • כדי למנוע ניתוב אוטומטי של תנועה לגרסה החדשה, משתמשים בדגל --no-promote.

  • כדי לפרוס לפרויקט ספציפי Google Cloud , משתמשים בדגל --project.

לדוגמה, כדי לפרוס את השירות שמוגדר בקובץ app.yaml לפרויקטGoogle Cloud ספציפי, צריך להקצות לשירות מזהה גרסה בהתאמה אישית ולמנוע ניתוב של תנועה לגרסה החדשה:

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

מידע נוסף זמין במאמר בנושא gcloud app deploy.

אתם יכולים להגדיר מאפיינים ל-CLI של gcloud וליצור ולנהל הגדרות SDK כדי שלא תצטרכו לציין דגלים כמו --project בכל פעם שתפעילו פריסה.

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

פריסת כמה שירותים

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

לפני שמתחילים:

  • לפני שתוכלו ליצור ולפרוס שירותים נוספים, תצטרכו לפרוס בהתחלה גרסה של האפליקציה בשירות default.

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

כדי לפרוס כמה שירותים, צריך לפרוס בנפרד את קובץ app.yaml של כל שירות, לדוגמה:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

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

gcloud app deploy service1/app.yaml service2/app.yaml

התעלמות מקבצים

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

מידע נוסף על התחביר של קובץ .gcloudignore זמין במאמר בנושא gcloud.

יצירה ידנית של קונטיינר לפריסה

כדי ליצור קובצי אימג' של קונטיינרים מחוץ ל- Google Cloud:

  1. מעלים את התמונות למאגר ב-Artifact Registry. מידע נוסף זמין במאמר בנושא העלאה והורדה של תמונות.
  2. פורסים ל-App Engine באמצעות הפקודה gcloud app deploy.

לדוגמה, אם אתם מפתחים גרסאות build מקומיות של קובצי אימג' בקונטיינר באמצעות Docker, אתם יכולים להעביר את קובצי האימג' האלה אל Artifact Registry ולציין את כתובת ה-URL של קובץ האימג' באמצעות הסימון --image-url של הפקודה:

gcloud app deploy --image-url LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE

מחליפים את:

  • ‫LOCATION עם המיקום של המאגר שבו התמונה מאוחסנת.

  • ‫PROJECT-ID עם Google Cloud מזהה הפרויקט.

  • REPOSITORY בשם המאגר שבו מאוחסן קובץ האימג'.

  • IMAGE בשם של קובץ האימג' בקונטיינר.

שימוש בצינורות אוטומטיים לפריסה רציפה

אתם יכולים להשתמש ב-Cloud Build כדי להפוך את הפריסות לאוטומטיות בצינורות של פריסה רציפה (CD). מידע נוסף זמין במאמרים בנושא פריסה ב-App Engine ויצירה וניהול של טריגרים לבנייה בתיעוד של Cloud Build.

תמונות בסיס של Docker

אם רוצים ליצור אפליקציית זמן ריצה בהתאמה אישית, אפשר לעיין במאמר בנושא יצירת קובץ Docker.

צפייה בבקשה

אחרי שמפעילים את האפליקציה ב-App Engine, אפשר להריץ את הפקודה הבאה כדי להפעיל את הדפדפן ולראות אותה בכתובת https://PROJECT_ID.REGION_ID.r.appspot.com:

gcloud app browse

בדיקה ב-App Engine

לפני שמגדירים גרסה חדשה לקבלת תעבורת נתונים, אפשר לבדוק אותה ב-App Engine. לדוגמה, כדי לבדוק גרסה חדשה של השירות default:

  1. פורסים את הגרסה החדשה וכוללים את הדגל --no-promote: 

    gcloud app deploy --no-promote

  2. כדי לגשת לגרסה החדשה, עוברים לכתובת ה-URL הבאה:

    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

    עכשיו אפשר לבדוק את הגרסה החדשה בסביבת זמן הריצה של App Engine. אפשר לנפות באגים באפליקציה על ידי צפייה ביומנים שלה ב-Logs Explorer במסוףGoogle Cloud . מידע נוסף זמין במאמר בנושא כתיבת יומני רישום של אפליקציות.

    בקשות שנשלחות אל https://PROJECT_ID.REGION_ID.r.appspot.com עדיין ינותבו לגרסה שהוגדרה קודם לקבלת תנועה.

  3. כשרוצים להפנות תנועה לגרסה החדשה, משתמשים במסוףGoogle Cloud כדי להעביר את התנועה:

    ניהול גרסאות

    בוחרים את הגרסה שזה עתה פרסתם ולוחצים על העברת תנועה.

אפשר להשתמש באותו תהליך כדי לבדוק גרסאות חדשות של שירותים אחרים. לשם כך, מחליפים את default בכתובת ה-URL בשם השירות:

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

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

שימוש במשתני סביבה של גרסת ה-build

אפשר להגדיר משתני סביבה של סביבת build עבור סביבות זמן ריצה שתומכות בbuildpacks.

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

לפני שמתחילים:

  • המפתחות צריכים להתחיל באות גדולה ב-ASCII, ויכולים לכלול אותיות גדולות ב-ASCII, ספרות וקווים תחתונים.
  • מומלץ להימנע מיצירת משתנים עם קידומת של GOOGLE_* key.
  • המפתחות הבאים שמורים לשימוש של Google:
    • GOOGLE_RUNTIME
    • GOOGLE_RUNTIME_VERSION
    • GOOGLE_ENTRYPOINT
    • GOOGLE_DEVMODE
  • אפשר להשתמש בכל מפתח שנתמך על ידי buildpacks.

כדי להשתמש במשתני סביבה עם buildpacks, מציינים את השדה build_env_variables בקובץ app.yaml.

מידע נוסף על חבילות Buildpack

שימוש ב-Cloud Trace

כדאי להשתמש ב-Cloud Trace כדי להבין איך בקשות מועברות באפליקציה. אתם יכולים לבדוק מידע מפורט על זמן האחזור של בקשה יחידה או לראות את זמן האחזור המצטבר של כל האפליקציה.

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

פתרון בעיות

ריכזנו כאן הודעות שגיאה נפוצות שאולי תיתקלו בהן כשאתם פורסים אפליקציות:

PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.
אם הפרויקט Google Cloud לא כולל את האפליקציה הנדרשת של App Engine, יכול להיות שהפקודה gcloud app deploy תיכשל כשהיא תנסה להפעיל את הפקודה gcloud app create. רק לחשבונות עם תפקיד הבעלים יש את ההרשאות הנדרשות ליצירת אפליקציות App Engine.
502 Bad Gateway
יכול להיות שהפרויקט לא יופעל אם Google Cloud ההגדרה של app.yaml שגויה. כדאי לבדוק את יומני האפליקציה כדי לראות הודעות שגיאה מפורטות יותר.
[13] An internal error occurred while creating a Cloud Storage bucket.

‫App Engine יוצר בשמכם קטגוריה אזורית של Cloud Storage שמוגדרת כברירת מחדל באותו אזור שבו הוא יוצר את האפליקציה. הוא צריך את הקטגוריה הזו כדי לאחסן את התוכן של האפליקציה. השגיאה מוחזרת אם אי אפשר ליצור את הקטגוריה הזו, למשל בתרחישים הבאים:

לדוגמה, אם אפליקציית App Engine שלכם נוצרה באזור europe-west, למרות שהאזור ממופה למיקומים europe-west1, אתם צריכים לשנות את האילוץ כדי לאפשר משאבים ב-in:eu-locations, שכולל את כל האזורים EU. הדבר נדרש כי הקטגוריות שנוצרו על ידי App Engine הן קטגוריות במספר אזורים. אם אפליקציית App Engine נוצרה באזור US, צריך לאפשר את in:us-locations, ואם האפליקציה נוצרה באזורים ASIA, צריך לאפשר את in:asia-locations.

[13] An internal error occurred.

השגיאה הזו יכולה להתרחש אם אתם פורסים את השירות עם הגדרת רשת שמשתמשת בהגדרת VPC משותף. נסו:

  1. מוודאים שההגדרה של app.yaml תקינה.
  2. מוודאים שסביבת App Engine הגמישה עומדת בכל הדרישות להגדרת VPC משותף. מידע נוסף על שימוש בסביבה הגמישה של App Engine ברשת VPC משותפת
  3. מוודאים שהגדרתם חשבונות שירות בפרויקט. אם לא, צריך לשחזר את החשבונות. האזור של תת-הרשת בפרויקט המארח של ה-VPC המשותף צריך להיות זהה למיקום שבו נוצר סביבת App Engine.

אם הבעיה נמשכת, צריך לפרוס מחדש את השירות באמצעות Google Cloud SDK. חשוב להוסיף את הדגל --verbosity=debug. פונים אל Google Cloud התמיכה ומספקים את הפלט של הפקודה.

IP space of {USER_SUBNETWORK_NAME} is exhausted and needs to be expanded.

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