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

מזהה אזור

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

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

במדריך הזה מוסבר איך לפרוס את האפליקציות הקיימות בסביבה הגמישה ב-Cloud Run.

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

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

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

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

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

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

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

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