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

מזהה אזור

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

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

אישור

Go Java Node.js PHP Python Ruby

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

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

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

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

python main.py

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

python manage.py runserver

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

gunicorn -b :$PORT main:app

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

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

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

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

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

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

כשפורסים גרסה חדשה עם אותו שם כמו גרסה קיימת, מערכת 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 ופריסה שאפשר לראות בקטע Build history של Cloud Build במסוף Google Cloud . כדי לראות גרסאות build באזור של האפליקציה, משתמשים בתפריט Region כדי לסנן לפי האזור.

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

שימו לב: הוצאנו משימוש את Container Registry. החל מ-18 במרץ 2025, שירות Container Registry ייסגר, ולא תהיה אפשרות לכתוב תמונות ב-Container Registry. פרטים על הוצאה משימוש ועל העברה ל-Artifact Registry זמינים במאמר בנושא הוצאה משימוש של Container Registry.

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

1. ‫App Engine יוצר קובץ אימג' של קונטיינר באמצעות שירות Cloud Build.

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

3. ‫App Engine מאחסן תמונות של קונטיינרים שנבנו ב-Artifact Registry. אתם יכולים להוריד את התמונות האלה כדי לשמור אותן או להשתמש בהן במקום אחר.

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

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

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

הערה: אם יש לכם קובץ .gcloudignore, אי אפשר לציין את השדה skip_files בקובץ app.yaml.

צפייה בבקשה

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

gcloud app browse

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

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

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

   gcloud app deploy --no-promote

2. כדי לגשת לגרסה החדשה, עוברים לכתובת ה-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 אל הגרסה שהוגדרה קודם לקבלת תנועה.

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

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

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

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

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

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

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

   gcloud auth login
   

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

   gcloud auth application-default login
   

3. כדי להפעיל את שרת הפיתוח המקומי:

   בספרייה שמכילה את קובץ ההגדרות 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 זמין במאמר אפשרויות של שרת פיתוח מקומי.

4. כשהשרת המקומי לפיתוח מופעל, הוא מגדיר סביבת פיתוח שבה מותקנות מראש התלויות שנמצאות בקובץ requirements.txt.

5. שרת הפיתוח המקומי פועל עכשיו ומאזין לבקשות. כדי לראות את האפליקציה בפעולה, עוברים אל http://localhost:8080/ בדפדפן האינטרנט.

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

6. כדי להפסיק את השרת המקומי משורת הפקודה, מקישים על 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.