פריסת אפליקציית App Engine בסביבה הרגילה ב-Cloud Run

מזהה אזור

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

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

במדריך הזה מוסבר איך לפרוס את האפליקציות הקיימות בסביבה הרגילה ב-Cloud Run. ההוראות רלוונטיות לדור השני של סביבות זמן ריצה שלא משתמשות בשירותים המצורפים מדור קודם של App Engine.

השלבים שמתוארים במדריך הזה לא משפיעים על הפונקציונליות של אפליקציית App Engine הקיימת או על זרימת התנועה שלה. שירות Cloud Run שנוצר הוא העתק של שירות App Engine, ואפשר לבדוק אותו בנפרד.

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

כדי לפרוס ל-Cloud Run, בוחרים באחת מהאסטרטגיות הבאות:

  • שימוש בהגדרה המקומית של קובץ app.yaml (מומלץ): בוחרים באפשרות הזו כדי ליצור קובץ אימג' של קונטיינר ישירות מקוד המקור המקומי ולפרוס אותו ב-Cloud Run. כך תוכלו לוודא שכל השינויים המקומיים שבוצעו לאחרונה בקוד או בהגדרה כלולים בפריסה החדשה.

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

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

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

  2. מפעילים את Cloud Run Admin API ואת Artifact Registry API:

    הפעלת ממשקי API

  3. מגדירים את הפרויקט והאזור באמצעות הפקודה הבאה:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud config set run/region REGION
gcloud components update

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: האזור שבו רוצים לפרוס את שירות Cloud Run.

  4. בודקים אם יש תכונות לא תואמות באפליקציה ומסירים אותן לפני המעבר ל-Cloud Run. כדי לבדוק אם האפליקציה לא תואמת בלי לבצע העברה או פריסה, מריצים את הפקודה הבאה:

    gcloud beta app migrate-to-run --dry-run

    בודקים את תוצאות בדיקת התאימות ומבצעים את השינויים המומלצים אם יש צורך.

  5. בודקים את ההבדלים הבאים ב-Cloud Run:

    • ב-Cloud Run משתמשים במונח Revision במקום במונח Version כדי לייצג כל פעם שפורסים שינויים בשירות מסוים. כשפורסים אפליקציה לשירות ב-Cloud Run בפעם הראשונה, נוצרת הגרסה הראשונה שלה. כל פריסה עוקבת של שירות יוצרת גרסה נוספת. מידע נוסף על פריסה ב-Cloud Run

    • אתם יכולים לפרוס את קוד המקור ב-Cloud Run באמצעות ה-CLI של gcloud או מסוף Google Cloud כדי להגדיר ולנהל את הגדרות האפליקציה. ב-Cloud Run לא נדרשת הגדרה מבוססת-קובץ, אבל יש תמיכה בהגדרת YAML.

    • כל שירות שפורסים ב-Cloud Run משתמש בדומיין run.app בכתובת ה-URL כדי לגשת לשירות באופן ציבורי.

    • בניגוד לשירותי App Engine שמוגדרים כציבוריים כברירת מחדל, שירותי Cloud Run מוגדרים כפרטיים כברירת מחדל, וצריך להגדיר אותם כדי לאפשר גישה ציבורית (ללא אימות).

התפקידים הנדרשים

אתם יכולים ליצור חשבון שירות חדש או להשתמש באותו חשבון שירות שמנוהל על ידי המשתמש ב-Cloud Run שבו אתם משתמשים בסביבה הרגילה. אתם או האדמין שלכם צריכים להעניק לחשבון הפריסה ולחשבון השירות של Cloud Build את תפקידי ה-IAM הבאים.

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

כדי לקבל את ההרשאות שדרושות לבנייה ולפריסה ממקור, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

לחצו כדי לראות את התפקידים הנדרשים לחשבון השירות של Cloud Build

Cloud Build משתמש אוטומטית בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build כדי לבנות את קוד המקור ואת משאב Cloud Run, אלא אם משנים את ההתנהגות הזו. כדי ש-Cloud Build יוכל לבצע build של המקורות, צריך לבקש מהאדמין להעניק את התפקיד Cloud Run Builder (roles/run.builder) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

מחליפים את PROJECT_NUMBER במספר הפרויקט ואת PROJECT_ID במזהה הפרויקט. Google CloudGoogle Cloudהוראות מפורטות לאיתור מזהה הפרויקט ומספר הפרויקט זמינות במאמר יצירה וניהול של פרויקטים.

הענקת תפקיד ה-builder ב-Cloud Run לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לוקחת כמה דקות עד שהיא מופצת.

רשימת ההרשאות והתפקידים ב-IAM שמשויכים ל-Cloud Run מופיעה במאמרים תפקידי IAM ב-Cloud Run והרשאות IAM ב-Cloud Run. אם שירות Cloud Run שלכם מתקשר עםGoogle Cloud ממשקי API, כמו ספריות לקוח ב-Cloud, כדאי לעיין במדריך להגדרת זהות שירות. מידע נוסף על מתן תפקידים זמין במאמרים הרשאות פריסה וניהול גישה.

שימוש בתצורה המקומית של קובץ app.yaml

פורסים את ההגדרה המקומית של App Engine ב-Cloud Run באמצעות מסוף Google Cloud או ה-CLI של gcloud.

המסוף

  1. נכנסים לדף App Engine במסוף Google Cloud .

    מעבר אל App Engine

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

  3. בוחרים את השירות שרוצים להעביר ולוחצים על בדיקת תאימות.

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

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

  6. מעתיקים את הפקודה בקטע Deploy through gcloud ומפעילים פתרונות חכמים אותה בספריית הפרויקט.

  7. כדי לראות את שירותי App Engine שפרוסים ב-Cloud Run, לוחצים על View deployed versions (הצגת גרסאות פרוסות).

gcloud

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

  1. במסוף, עוברים לספריית קובצי המקור שבה נמצא הקובץ app.yaml.

  2. מריצים את הפקודה הבאה כדי לפרוס את השירות ב-Cloud Run:

    gcloud beta app migrate-to-run

    הפקודה הזו יוצרת את קובץ התצורה service.yaml עבור Cloud Run ושומרת אותו באופן מקומי באותה ספרייה שבה נמצא הקובץ app.yaml. מידע נוסף זמין במאמר gcloud beta app migrate-to-run.

    • כשמופיעה ההנחיה Proceed with the deployment?, מזינים Y כדי ליצור קובץ אימג' של קונטיינר מקוד המקור ולפרוס את השירות ב-Cloud Run.

  3. כדי להיכנס לשירות Cloud Run שפרסתם, פותחים את כתובת ה-URL של השירות בדפדפן אינטרנט.

    אופציונלי:

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

      gcloud beta app migrate-to-run --appyaml=PATH

      מחליפים את PATH בנתיב לקובץ app.yaml.

    • כדי ליצור ולייצא את ההגדרה של Cloud Run service.yaml בלי לפרוס את השירות, משתמשים בדגל --export-only:

      gcloud beta app migrate-to-run --export-only=EXPORT_PATH

      מחליפים את EXPORT_PATH בספרייה או בנתיב שבהם רוצים לשמור את הקובץ service.yaml.

שימוש בתמונה שנבנתה בעבר

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

לא צריך את קוד המקור של האפליקציה כדי להפעיל את הפריסה הזו.

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

    gcloud beta app migrate-to-run --service=SERVICE --version=VERSION --from-image

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות App Engine.
    • ‫VERSION: מזהה הגרסה של השירות.

    הפקודה הזו מאחזרת את ההגדרות של השירות והגרסה שצוינו כדי ליצור את קובץ service.yaml עבור Cloud Run. מידע נוסף זמין במאמר gcloud beta app migrate-to-run.

    • כשמוצגת ההודעה Proceed with the deployment?, מזינים Y כדי לייצא את קובץ האימג' הקיים של קונטיינר App Engine ולפרוס את השירות ב-Cloud Run.

  2. כדי להיכנס לשירות Cloud Run שפרסתם, פותחים את כתובת ה-URL של השירות בדפדפן אינטרנט.

    אופציונלי:

    • כדי ליצור את הגדרת Cloud Run service.yaml בלי לפרוס את השירות, מריצים את הפקודה הבאה:

      gcloud beta app migrate-to-run --service=SERVICE \
    --version=VERSION \
    --from-image \
    --export-only=EXPORT_PATH

      מחליפים את EXPORT_PATH בספרייה או בנתיב שבהם רוצים לשמור את קובץ service.yaml.

תכונות לא תואמות

פקודת ההעברה נכשלת אם קובץ ה-app.yaml מכיל אחת מההגדרות הלא נתמכות הבאות:

  • שירותים נכנסים:

    inbound_services:
- warmup

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

  • דפי שגיאה בהתאמה אישית:

    error_handlers:
 - file: default_error.html
 - error_code: over_quota
 file: over_quota.html

    פתרון: מוחקים את הקטע error_handlers מהקובץ app.yaml ופועלים לפי אחת מהאסטרטגיות הבאות או לפי שתיהן:

    • הטמעת טיפול בשגיאות ישירות בקוד האפליקציה. אפשר לזהות קודי שגיאות רגילים של HTTP, כמו 404 או 500, ולהציג דפי שגיאה מותאמים אישית ב-HTML מתוך הלוגיקה של האפליקציה.
    • אם אתם משתמשים ב-Cloud Load Balancing עם Cloud Run, אתם צריכים להגדיר תגובות שגיאה מותאמות אישית ברמת מאזן העומסים. כך תוכלו להציג דפי שגיאה מותאמים אישית מ-Cloud Storage על סמך קוד התגובה משירות Cloud Run.

  • חבילות שירותים לסביבות זמן ריצה מהדור השני:

    app_engine_apis: true

    פתרון: מוחקים את ההגדרה app_engine_apis מהקובץ app.yaml ועוברים במקום זאת לשימוש בממשקי API של Google Cloud או בחלופות של צד שלישי. מידע נוסף זמין במאמר בנושא העברה מחבילות של שירותים.

  • זמני ריצה מהדור הראשון:

    runtime: python27

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

המאמרים הבאים