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

מזהה אזור

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

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

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

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

כדי לבדוק את האפליקציה לפני הפריסה, מריצים אותה בסביבה המקומית באמצעות כלי הפיתוח שבהם אתם משתמשים בדרך כלל. מומלץ להשתמש בכלים סטנדרטיים של Python, כמו virtualenv ליצירת סביבות מבודדות ו-pytest להרצת בדיקות יחידה ובדיקות שילוב, במקום להסתמך על dev_appserver, שרת הפיתוח המקומי שמסופק עם ה-SDK של Google Cloud.

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

python main.py

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

python manage.py runserver

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

gunicorn -b :$PORT main:app

לפני שמפעילים את האפליקציה

לפני שמפעילים את האפליקציה:

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

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

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

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

פריסת שירות

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

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

gcloud app deploy

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

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

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

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

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

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

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

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

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

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

צפייה ביומני בנייה

ב-Cloud Build אפשר לראות בסטרימינג את היומנים של תהליכי הבנייה והפריסה. היומנים האלה מוצגים בקטע Build history של Cloud Build ב Google Cloud מסוף. כדי לראות גרסאות Build באזור של האפליקציה, משתמשים בתפריט Region (אזור) כדי לסנן לפי האזור.

ניהול תמונות build

בכל פעם שמפעילים גרסה חדשה:

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

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

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

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

צפייה בבקשה

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

gcloud app browse

בדיקה ב-App Engine לפני העברת תנועה

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

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

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

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

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

מערכת App Engine מנתבת בקשות שנשלחות אל 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.

שימוש בשרת הפיתוח המקומי

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

הפעלת שרת הפיתוח המקומי

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

כדי לקבל פרטי כניסה לחשבון המשתמש, מריצים את הפקודה:
```
gcloud auth login
```
מאפשרים לאפליקציה המקומית להשתמש באופן זמני בפרטי הכניסה של המשתמש כדי לגשת ל-API:
```
gcloud auth application-default login
```
כדי להפעיל את שרת הפיתוח המקומי:

בספרייה שמכילה את קובץ התצורה app.yaml, מריצים את הפקודה dev_appserver.py ומציינים את מזהה הפרויקט ואת הנתיב לקובץ app.yaml:
```
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml
```
כדי לשנות את הניוד, כוללים את האפשרות --port:
```
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
כדי לבדוק אפליקציית Python 3, מריצים את הפקודה dev_appserver.py עם מתורגמן Python 3. צריך לציין את הקובץ הבינארי של Python 3 בדגל --runtime_python_path, לדוגמה:
```
python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999
```
dev_appserver.pyמידע נוסף על אפשרויות הפקודה
כשהשרת המקומי לפיתוח מופעל, הוא מגדיר סביבת פיתוח שבה מותקנות מראש התלויות שנמצאות בקובץ requirements.txt.
שרת הפיתוח המקומי פועל עכשיו ומאזין לבקשות. כדי לראות את האפליקציה בפעולה, עוברים אל http://localhost:8080/ בדפדפן האינטרנט.

אם ציינתם יציאה מותאמת אישית באמצעות האפשרות --port, אל תשכחו לפתוח את הדפדפן ליציאה הזו.
כדי להפסיק את השרת המקומי משורת הפקודה, מקישים על Control-C במקלדת.

זיהוי סביבת זמן הריצה של האפליקציה

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

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

שימוש בשרת פיתוח מקומי עם שירותי Google Cloud

אפשר לשלב את dev_appserver עם רכיבים אחרים של Google Cloud .

ספריות לקוח ב-Cloud

הרבה ספריות לקוח של Google Cloud מסתמכות על משתנה הסביבה GOOGLE_CLOUD_PROJECT, שצריך להיות מוגדר כמזהה הפרויקטGoogle Cloud . כדי לראות את הערך שלו, מריצים את הפקודה gcloud config list project או מעיינים בדף הפרויקט ב-Google Cloud console.

כדי לוודא שמשתנה הסביבה הזה מוגדר בצורה נכונה במהלך פיתוח מקומי, צריך להפעיל את dev_appserver באמצעות הפרמטר --application=PROJECT_ID כמו בדוגמה שלמעלה.

אמולטורים של Cloud

אפשר לבדוק את האפליקציה באמצעות אמולטורים של Cloud Datastore,‏ Cloud Bigtable ו-Cloud Pub/Sub.

שינוי של הוספת כסף אוטומטית `requirements.txt` ו`app.yaml`

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

ניהול מופעים וניתוב בשרת הפיתוח

גילוי כתובות של מופעים

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

אלה הפורטים של אפליקציה שמגדירה שלושה שירותים:

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

כשמשתמשים בכתובת של שירות, למשל http://localhost:8082/, השרת יוצר או בוחר מופע של השירות ושולח את הבקשה למופע הזה.

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

INFO Starting admin server at: http://localhost:8000

הכתובת הזו מובילה למסוף של שרת האדמין. לוחצים על Instances (מופעים) כדי לראות את המצב הדינמי של המופעים של האפליקציה.

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

קובצי dispatch

אם האפליקציה כוללת קובץ dispatch.yaml, זרם הודעות היומן כולל יציאת dispatcher:

INFO Starting dispatcher running at: http://localhost:8080

בקשות ליציאה זו מנותבות בהתאם לכללים בקובץ dispatch. השרת לא תומך בכללי קובץ dispatch.yaml שכוללים שמות מארחים, לדוגמה, url: "customer1.myapp.com/*". כללים עם תבניות של נתיבים יחסיים (url: "*/fun"), כן פועלים, כך שאפשר להשתמש בכתובות URL כמו http://localhost/fun/mobile כדי להגיע למופעים. השרת מדווח על שגיאה בזרם היומן אם מנסים להפעיל אפליקציה עם קובץ dispatch.yaml שמכיל כללים שמבוססים על מארח.

שימוש ב-Cloud Trace

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

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