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

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

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

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

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

המסוף

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

    כניסה ל-App Engine

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

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

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

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

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

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

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

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

    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

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

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