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

מזהה אזור

‫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.

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

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

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

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

אם מפעילים את הבדיקות המעודכנות של תקינות המערכת, הפריסות מוחזרות אם האפליקציה לא מגיעה לסטטוס תקין. כשפורסים את האפליקציה הראשונה בסביבה הגמישה, יכול להיות שיהיה עיכוב בזמן ההגדרה של המכונה הווירטואלית (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:

מעלים את התמונות למאגר ב-Artifact Registry. מידע נוסף זמין במאמר Push and pull images (העלאה והורדה של תמונות).
פורסים ל-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:

פורסים את הגרסה החדשה וכוללים את הדגל --no-promote:
```
gcloud app deploy --no-promote
```
כדי לגשת לגרסה החדשה, עוברים לכתובת ה-URL הבאה:

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

הערה: אפשר למצוא את מזהה הגרסה בGoogle Cloud מסוף, או לציין אותו כשמבצעים פריסה באמצעות הפרמטר version.

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

בקשות שנשלחות אל https://PROJECT_ID.REGION_ID.r.appspot.com עדיין ינותבו לגרסה שהוגדרה קודם לקבלת תנועה.
כשרוצים לשלוח תעבורה לגרסה החדשה, משתמשים במסוףGoogle Cloud כדי להעביר את התעבורה:

ניהול גרסאות

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

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

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

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

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

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

משתני סביבה של סביבת 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

יכול להיות שהפרויקט לא יופעל אם app.yaml לא מוגדר בצורה נכונה. Google Cloud כדאי לבדוק את יומני האפליקציה כדי לראות הודעות שגיאה מפורטות יותר.

[13] An internal error occurred while creating a Cloud Storage bucket.

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

סוכן השירות של הסביבה הגמישה של App Engine לא קיים בפרויקט או שאין לו את התפקיד App Engine flexible environment Service Agent. אפשר להוסיף את חשבון השירות של הסוכן בחזרה לפרויקט על ידי הקצאת הרשאות IAM מתאימות. כך משחזרים סוכן שירות שנמחק
חשבון השירות של App Engine שמוגדר כברירת מחדל לא קיים בפרויקט. אם חשבון השירות של App Engine הוסר לפני שחלפו 30 ימים מאז המחיקה שלו, אפשר לשחזר אותו.
הפרויקט שלכם נמצא בארגון שמחיל את המדיניות constraints/gcp.resourceLocations, והארגון לא מאפשר ליצור משאבים באותו אזור שבו נוצרה אפליקציית App Engine. צריך לבטל את מדיניות constraints/gcp.resourceLocations שנאכפת בפרויקט ולאפשר את המיקומים במספר אזורים באותו אזור שבו נוצרה אפליקציית App Engine.

לדוגמה, אם אפליקציית 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 משותף. נסו:

מוודאים שההגדרה של app.yaml תקינה.
מוודאים שסביבת App Engine הגמישה עומדת בכל הדרישות להגדרת VPC משותף. שימוש בסביבה הגמישה של App Engine ברשת VPC משותפת
מוודאים שיש בפרויקט חשבונות שירות מוגדרים. אם לא, צריך לשחזר את החשבונות. האזור של תת-הרשת בפרויקט המארח של ה-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 גמישה.