השוואה בין App Engine לבין Cloud Run

מזהה אזור

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

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

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

סקירה כללית

‫Cloud Run הוא השלב האחרון באבולוציה של Google Cloud Serverless, שמבוסס על הניסיון בהפעלת App Engine במשך יותר מעשור. ‫Cloud Run פועל על חלק גדול מאותה תשתית כמו סביבת App Engine סטנדרטית, ולכן יש הרבה דמיון בין שתי הפלטפורמות האלה.

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

סיכום ההשוואה

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

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

נקודות קצה של כתובות URL
כתובת URL של האפליקציה
(default service) 		https://PROJECT_ID.REGION_ID.r.appspot.com לא רלוונטי
כתובת ה-URL של השירות https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://SERVICE_IDENTIFIER.run.app
כתובת URL של גרסה או שינוי https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://TAG---SERVICE_IDENTIFIER.run.app

התאמה להיקף
התאמה אוטומטית לעומס כן כן כן
שינוי גודל ידני כן כן כן
צמצום הפעולה לאפס כן לא כן
בקשות חימום ניתן להגדרה לא אוטומטי
זמן קצוב לתפוגה של מופע ללא פעילות (אחרי סיום הבקשה האחרונה) עד 15 דקות תלוי בהגדרת החיוב. שימוש בחיוב על בסיס מופע כדי לדמות את ההתנהגות של App Engine
משך הבקשה הסתיים
  • התאמה אוטומטית לעומס: 10 דקות
  • הגדלה ידנית/בסיסית של נפח האחסון: 24 שעות
 60 דקות אפשר להגדיר עד 60 דקות (ברירת מחדל: 5 דקות)

פריסה
מהמקור כן כן
קובץ אימג' של קונטיינר לא כן (סביבות זמן ריצה בהתאמה אישית) כן
מאגרי Sidecar לא כן. קונטיינרים מסוג Sidecar פועלים לצד הקונטיינר הראשי ומשרתים בקשות אינטרנט.
בדיקות תקינות אוטומטי. ‫App Engine מבצע בדיקות מוכנות ופעילות במופעים. ניתן להגדרה. אתם מגדירים בדיקות מוכנות ובדיקות מצב פעילות (liveness) באופן מפורש בהגדרות של משאב Cloud Run, ומציינים פרטים כמו סוג הבדיקה (TCP,‏ HTTP ו-gRPC), נתיב, יציאה, עיכוב ראשוני, תקופה, זמן קצוב לתפוגה, סף הצלחה וסף שגיאה.

משאבי מחשוב
vCPU
סוג המכונה vCPU* זיכרון
F/B1 ‫0.25 ‫384MB
F/B2 ‫.5 ‫768MB
F/B4 1 ‫1.5GB
F/B4_1G 1 3GB
B8 2 3GB
* שווי ערך של vCPU הוא משוער 		עד 80 vCPU עד 8 ליבות vCPU
זיכרון עד 6.5GB לכל vCPU עד 32GB
יחידות GPU לא כן. אפשר להגדיר GPU אחד לכל מופע של Cloud Run.
חיבורים של נפחי אחסון לא כן. אתם יכולים לטעון קטגוריה של Cloud Storage ישירות למערכת הקבצים של הקונטיינר.

מודל התמחור
עמלה לכל בקשה לא לא, כשמשתמשים בחיוב לפי מופע.
כן, כשמשתמשים בחיוב מבוסס-בקשות.
מינימום מכונות וירטואליות במצב לא פעיל אותה עלות כמו מופעים פעילים עלות נמוכה יותר למכונות מינימליות במצב סרק (ראו זמן שימוש במכונת קונטיינר לחיוב)
הנחות תמורת התחייבות לשימוש (CUD) לא כן
חיוב לפי מופע (עלות למופע לשעה) מופע F4/B4: ‏ ‎$0.2
  • vCPU: $0.0526
  • זיכרון: ‎$0.0071
    		•
    • vCPU: ‏0.0648 USD
    • זיכרון: ‎$0.0072

    אבטחה
    הגדרות של תעבורת נתונים נכנסת (ingress) כן כן כן
    תפקיד מפעיל לא כן
    IAP כן כן כן
    חומות אש כן כן הגדרה באמצעות Google Cloud Armor
    Secret Manager כן, באמצעות ספריות הלקוח של Cloud. כן. אפשר לטעון כל סוד כנפח או להעביר סוד באמצעות משתני סביבה.

    קישוריות
    דומיינים מותאמים אישית כן כן כן
    קישוריות ל-VPC (כולל VPC משותף) כן לא רלוונטי כן
    הגדרות של תעבורת נתונים יוצאת (egress) ב-VPC כן לא רלוונטי כן
    איזון עומסים במספר אזורים לא כן
    סטרימינג מהשרת לא כן

    גישה לשירותים Google Cloud

    Cloud SQL כן כן כן
    ספריות לקוח ב-Cloud אם אתם משתמשים ב-Cloud Client Libraries ב-App Engine, לא תצטרכו לשנות שום דבר כשאתם עוברים ל-Cloud Run. ספריות הלקוח האלה פועלות בכל מקום, ולכן האפליקציה שלכם ניידת יותר.
    שירותים מדור קודם בחבילה של App Engine כן (Java,‏ Python,‏ Go ו-PHP בלבד) לא לא

    מודל של משאבים

    תרשים של מודל המשאבים ב-App Engine וב-Cloud Run

    מודל המשאבים של Cloud Run דומה מאוד לזה של App Engine, אבל יש כמה הבדלים חשובים:

    • ל-Cloud Run אין משאב Application ברמה העליונה, או שירות default תואם.
    • אפשר לפרוס שירותי Cloud Run באזורים שונים באותו פרויקט. ב-App Engine, כל השירותים בפרויקט נמצאים באותו אזור.
    • ב-Cloud Run משתמשים במונח Revision (גרסה), במקום במונח Version (גרסה), כדי להתאים למודל המשאבים של Knative.
    • שמות הגרסאות של Cloud Run הם בפורמט: SERVICE_NAME-REVISION_SUFFIX, כאשר REVISION_SUFFIX נוצר באופן אוטומטי או מוגדר באמצעות דגל הפריסה --revision-suffix=REVISION_SUFFIX.
    • אי אפשר לשנות את הגרסאות ב-Cloud Run, כלומר אי אפשר לעשות שימוש חוזר בשמות כמו בגרסאות של App Engine (באמצעות --version=VERSION_ID דגל הפריסה).
    • כתובות ה-URL של שירות Cloud Run מבוססות על מזהה שירות שנוצר אוטומטית בפריסה הראשונה של השירות. מזהי השירות הם בפורמט: SERVICE_NAME-<auto-generated identifier>. מזהה השירות הוא ייחודי ולא משתנה במהלך משך החיים של השירות.
    • ב-Cloud Run, רק כתובות ה-URL של השירות (SERVICE_IDENTIFIER.run.app ו-https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) חשופות כברירת מחדל. כדי להתייחס לשינוי ספציפי, צריך להגדיר תג תנועה. ב-App Engine, כתובות ה-URL של השירות ושל הגרסה נחשפות באופן אוטומטי.

    פריסה והגדרה

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

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

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

    כדי להגדיר את ההגדרה כשפורסים קוד חדש ב-Cloud Run, משתמשים בדגלים gcloud run deploy:

    gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

    לא צריך להשתמש בדגלי ההגדרה בכל פריסה (ראו ניהול הגדרות), אבל אפשר לעשות את זה כדי לפשט את ניהול ההגדרות.

    ב-Cloud Run, אפשר גם לעדכן את ההגדרה בלי לפרוס מחדש את קוד המקור באמצעות gcloud run services update:

    gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

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

    ניהול הגדרות

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

    App Engine service-a version1 App Engine service-a version2
    app.yaml 
    runtime: python39
service: service-a
instance_class: F4

    runtime: python39
service: service-a
    ההגדרה שהופעלה 
    runtime: python39
service: service-a
instance_class: F4
default values:
    ..
    ..    

    runtime: python39
service: service-a
default values:
    instance_class: F1
    ..
    ..

    ‫version1 מוגדר עם instance_class: F4, ואילו version2, שלא צוין לו ערך עבור instance_class, מוגדר עם ברירת המחדל instance_class: F1.

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

    שירות Cloud Run – גרסה 1 שירות Cloud Run – גרסה 2
    פקודת פריסה 
    gcloud run deploy service-a \
--cpu=4

    gcloud run deploy service-a
    ההגדרה שהופעלה 
    service: service-a
vCPUs: 4
default values:
    ..
    ..    

    service: service-a
vCPUs: 4
default values:
    ..
    ..

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

    הגדרות ברירת המחדל

    הגדרת תצורה סביבה רגילה של App Engine סביבה גמישה של App Engine Cloud Run
    משאבי מחשוב F1 ‫‎1 vCPU, .6GB ‫1 vCPU, ‏ 512MB
    Maximum concurrency (requests)‎ (מספר מקסימלי של בקשות בו-זמנית) 10 ללא 80
    משך הבקשה הסתיים
    • התאמה אוטומטית לעומס: 10 דקות
    • הגדלה ידנית/בסיסית של נפח האחסון: 24 שעות
    		 60 דקות ‫5 דקות
    יעד ניצול המעבד 60% 50% 60%
    מספר מכונות מקסימלי ללא 20 100
    מינימום מכונות 0 2 0

    נקודת כניסה

    כשפורסים מקובץ מקור, ‏ App Engine קורא את פקודת נקודת הכניסה מהמאפיין entrypoint בקובץ app.yaml. אם לא מציינים נקודת כניסה, המערכת משתמשת בברירת מחדל ספציפית לסביבת זמן הריצה. כשפורסים מתוך קוד מקור ב-Cloud Run, המערכת משתמשת ב-buildpacks של Google Cloud. לחלק מהשפות אין נקודת כניסה שמוגדרת כברירת מחדל, ולכן צריך לספק נקודת כניסה, אחרת הפריסה תיכשל. לדוגמה, חבילות buildpack של Python דורשות קובץ Procfile או ציון של משתנה הסביבה GOOGLE_ENTRYPOINT של ה-build.

    כדאי לעיין בתיעוד של חבילות ה-buildpack כדי לראות אם יש דרישות הגדרה ספציפיות לשפה.

    בדיקות תקינות

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

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

    ב-Cloud Run, אפשר להגדיר את הבדיקות הבאות:

    • בקשה לבדיקת תקינות (probe) להפעלה כדי להגדיר מתי מאגר התחיל לפעול ומוכן לשרת תנועה. כשמגדירים בדיקת מוכנות להפעלה, היא משביתה את בדיקות מצב הפעילות עד שההפעלה מצליחה, כדי לוודא שבדיקות מצב הפעילות לא יפריעו להפעלת האפליקציה.

    • בקשה לבדיקת תקינות (probe) של מצב פעילות (liveness) כדי לקבוע מתי להפעיל מחדש קונטיינר. לדוגמה, בדיקות מצב פעילות (liveness probes) יכולות לזהות מצב של קיפאון (deadlock) כשאפליקציה פועלת, אבל לא מצליחה להתקדם. הפעלה מחדש של קונטיינר במצב כזה מבטיחה שהאפליקציה תהיה זמינה למרות באגים.

    מידע נוסף זמין במאמר הגדרת בדיקות תקינות של קונטיינרים לשירותים.

    התאמה להיקף

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

    במקרים של מופעי Cloud Run, אי אפשר להגדיר את יעד ניצול ה-CPU. הוא קבוע על 60%. למידע נוסף, אפשר לעיין במאמר מידע על שינוי גודל אוטומטי של מופעים בשירותי Cloud Run.

    הסביבה הגמישה של App Engine משתמשת במידרוג אוטומטי של Compute Engine, ולכן יש לה מאפייני שינוי גודל שונים מאוד מאלה של הסביבה הרגילה של App Engine ושל Cloud Run.

    העברה של אמצעי בקרה לשינוי קנה מידה מ-App Engine ל-Cloud Run

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

    מינימום מכונות (חימום מראש)

    כדאי לשמור על מספר מינימלי של מופעים במצב פעיל כדי לטפל בתנועת הבסיס ולמנוע הפעלות במצב התחלתי (cold start).

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine min_instances: N
    סביבה גמישה של App Engine automatic_scaling:
      min_num_instances: N
    Cloud Run ברמת השירות: scaling.min_instance_count: N
    ברמת הגרסה: template.scaling.min_instance_count: N

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

    מספר מכונות מקסימלי

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

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine max_instances: N
    סביבה גמישה של App Engine automatic_scaling:
      max_num_instances: N
    Cloud Run ברמת השירות: scaling.max_instance_count: N
    ברמת הגרסה: template.scaling.max_instance_count: N

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

    בו-זמניות

    הגדרת קיבולת הבקשות של מופע יחיד.

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine max_concurrent_requests: N
    סביבה גמישה של App Engine automatic_scaling:
      target_concurrent_requests: N
    Cloud Run template.maxInstanceRequestConcurrency: N

    אסטרטגיית העברה: אפשר לפעול לפי אחת משתי אסטרטגיות העברה:

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

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

    ניצול יחידת העיבוד המרכזית (CPU)

    התאמת קנה מידה כשעומס המעבד חורג מסף מסוים.

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine target_cpu_utilization: 0.X
    סביבה גמישה של App Engine automatic_scaling:
      cpu_utilization:
      target_utilization: N
    Cloud Run אין מקבילה ישירה (הערך קבוע ועומד על כ-60%)

    אסטרטגיית העברה: אי אפשר להגדיר את הערך הזה. התאמה אוטומטית לעומס ב-Cloud Run שומרת על ניצול של כ-60% מהמעבד במכונות פעילות. בניגוד ל-App Engine,‏ Cloud Run מקצה CPU רק במהלך עיבוד הבקשות, ומגביל את השימוש ל-0 בכל שאר הזמן. בסביבה הרגילה של App Engine, לא משנה איזה סוג של התאמה לעומס (scaling) תגדירו, App Engine ידאג שיחידת העיבוד המרכזית (CPU) תהיה זמינה באופן רציף למופע שלכם.

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

    ניצול בו-זמני

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

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine target_throughput_utilization: 0.X
    סביבה גמישה של App Engine לא זמין
    Cloud Run כדאי לשנות את ההגדרה template.maxInstanceRequestConcurrency

    אסטרטגיית העברה: המידרוג האוטומטי של Cloud Run מנסה לשמור על מספר הבקשות המקבילות לכל מופע ב-60% מהערך של maxInstanceRequestConcurrency. כשמגדירים את הערך הזה, מגדירים באופן מרומז את נפח התפוקה של היעד שמפעיל אירוע של הגדלת הקיבולת.

    זמן אחזור

    הגדרת חלון זמן להמתנה של משתמש שמפעיל שינוי קנה מידה. ‫App Engine מגיב באופן חלקי לתורים של בקשות.

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine min_pending_latency וגם max_pending_latency
    סביבה גמישה של App Engine לא זמין
    Cloud Run אין מקבילה ישירה

    שיטת העברה: התאמה לעומס (autoscaling) ב-Cloud Run לפני שהבקשות מתחילות להצטבר בתור ולגרום לעלייה בזמן האחזור. אם יש קפיצות חדות בזמן האחזור, כדאי לשנות את הערך של template.maxInstanceRequestConcurrency כדי להבטיח הרחבה מהירה יותר.

    מכונות וירטואליות בלי פעילות

    הכוונה: ב-App Engine, הגדרות של מכונות במצב המתנה שולטות במאגר של מכונות במצב המתנה שהופעלו מראש, כדי לספוג עליות פתאומיות בתנועה ולשלוט בעלויות.

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine ‫min_idle_instances: N
    או
    max_idle_instances: N
    סביבה גמישה של App Engine לא זמין
    Cloud Run אין מקבילה ישירה

    אסטרטגיית העברה: אי אפשר להגדיר ב-Cloud Run מספר מינימלי או מקסימלי נפרד של מופעים לא פעילים. כדי לשמור על המופעים במצב ביניים (warm) ומוכנים לתנועה מיידית, וכדי לצמצם את ההשפעה של הפעלה במצב התחלתי (cold start) ב-Cloud Run, אפשר להשתמש בהגדרה scaling.min_instance_count, שמבטיחה שמספר מינימלי של קונטיינרים יפעל תמיד. מידע נוסף זמין במאמר מידע על שינוי גודל אוטומטי של מופעים בשירותי Cloud Run.

    הזמן הקצוב לתפוגה של מופע לא פעיל

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

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

    אפשרות אחרת היא להשתמש בחיוב לפי בקשה, כדי שהמעבד יוקצה רק במהלך עיבוד הבקשה. בהגדרה הזו, המופע ימשיך לפעול למשך 15 דקות לכל היותר אחרי הבקשה האחרונה, אבל השימוש במעבד (CPU) יוגבל במהלך זמן בלי פעילות הזה.

    שינוי גודל בסיסי

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine basic_scaling: max_instances: N
    סביבה גמישה של App Engine לא זמין
    Cloud Run שינוי גודל אוטומטי שמוגדר כברירת מחדל.
    scaling.min_instance_count: 0
    scaling.max_instance_count: N

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

    שינוי גודל ידני

    הפעלת מספר קבוע של מכונות והשבתת התאמה אוטומטית לעומס.

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine manual_scaling: instances: N
    סביבה גמישה של App Engine manual_scaling: instances: N
    Cloud Run scalingMode: MANUAL
      manualInstanceCount: N

    אסטרטגיית העברה: יש מיפוי ישיר ב-Cloud Run עבור שינוי גודל ידני. מגדירים את מצב שינוי הגודל ל-MANUAL ברמת השירות ב-Cloud Run, ומציינים את המספר המדויק של המופעים להפעלה באמצעות manualInstanceCount. ההשפעה של הפעולה הזו זהה להשפעה של השבתה מלאה של התאמה אוטומטית לעומס. מידע נוסף זמין במאמר בנושא שינוי גודל ידני ב-Cloud Run.

    תקופת צינון

    הגדרת תקופת צינון אחרי אירוע של הגדלת הקיבולת לפני שמתרחש אירוע אחר.

    סביבת ההגדרה הגדרות
    סביבה רגילה של App Engine לא זמין
    סביבה גמישה של App Engine automatic_scaling:
      cool_down_period_sec: N
    Cloud Run אין מקבילה ישירה

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

    בקשות warmup

    מערכת Cloud Run מחממת אוטומטית את המופעים באמצעות פקודת נקודת הכניסה של הקונטיינר, כך שלא צריך להפעיל ידנית בקשות חימום או להגדיר handler של /_ah/warmup. אם יש לכם קוד שאתם רוצים להריץ בהפעלת המופע לפני עיבוד הבקשות, אתם יכולים:

    תוכן סטטי

    בסביבה הרגילה של App Engine, אפשר להציג תוכן סטטי בלי להשתמש במשאבי מחשוב על ידי הצגה מ-Cloud Storage או על ידי הגדרת handlers.ב-Cloud Run אין אפשרות להשתמש ב-handlers כדי להציג תוכן סטטי, לכן אפשר להציג את התוכן משירות Cloud Run (בדומה לתוכן דינמי) או מ-Cloud Storage.

    התפקיד Cloud Run Invoker

    בנוסף, Cloud Run מאפשר לשלוט בגישה לשירות באמצעות ניהול זהויות והרשאות גישה (IAM). אפשר להגדיר את קישורי מדיניות IAM לשירות באמצעות ה-CLI של gcloud, מסוף Google Cloud או Terraform.

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

    פריסה

    משתמשים בדגל הפריסה --allow-unauthenticated:

    gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

    שירות קיים

    משתמשים בפקודה gcloud run services add-iam-policy-binding:

    gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

    כאשר SERVICE_NAME הוא שם השירות של Cloud Run.

    לחלופין, אתם יכולים לקבוע למי תהיה גישה לשירות על ידי הענקת תפקיד IAM‏ Cloud Run Invoker, שאפשר להגדיר אותו לכל שירות בנפרד.

    פריסה

    gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

    כאשר SERVICE_NAME הוא שם השירות ו-MEMBER_TYPE הוא סוג חשבון המשתמש. לדוגמה, user:email@domain.com.

    רשימת הערכים הקבילים של MEMBER_TYPE מופיעה במאמר מזהים של חשבונות משתמשים.

    שירות קיים

    gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

    כאשר SERVICE_NAME הוא שם השירות ו-MEMBER_TYPE הוא סוג חשבון המשתמש. לדוגמה, user:email@domain.com.

    רשימת הערכים הקבילים של MEMBER_TYPE מופיעה במאמר מזהים של חשבונות משתמשים.

    משתני סביבה ומטא-נתונים

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

    משתני סביבה שמוגדרים כברירת מחדל

    שם App Engine שם Cloud Run תיאור
    GAE_SERVICE K_SERVICE השם של השירות הנוכחי. ב-App Engine, אם לא מציינים ערך, ברירת המחדל היא default.
    GAE_VERSION K_REVISION תווית הגרסה הנוכחית של השירות.
    PORT PORT היציאה שמקבלת בקשות HTTP.
    לא רלוונטי K_CONFIGURATION השם של ההגדרה ב-Cloud Run שיצרה את הגרסה.
    GOOGLE_CLOUD_PROJECT לא רלוונטי מזהה הפרויקט ב- Google Cloud שמשויך לאפליקציה.
    GAE_APPLICATION המזהה של אפליקציית App Engine. המזהה הזה מתחיל בקידומת 'קוד אזור~', למשל 'e~' לאפליקציות שנפרסות באירופה.
    GAE_DEPLOYMENT_ID המזהה של הפריסה הנוכחית.
    GAE_ENV סביבת App Engine. מגדירים את הערך `standard` אם נמצאים בסביבה רגילה.
    GAE_INSTANCE המזהה של המופע שבו השירות פועל.
    GAE_MEMORY_MB נפח הזיכרון שזמין לתהליך האפליקציה, ב-MB.
    ‫NODE_ENV (זמין רק בסביבת זמן ריצה של Node.js) אחרי פריסת השירות, מגדירים אותו כסביבת ייצור.
    GAE_RUNTIME סביבת זמן הריצה שצוינה בקובץ app.yaml.

    נתיבים נפוצים של שרת מטא-נתונים

    נתיב תיאור דוגמה
    /computeMetadata/v1/project/project-id מזהה הפרויקט שאליו שייך השירות test_project
    /computeMetadata/v1/project/numeric-project-id מספר הפרויקט שאליו שייך השירות 12345678912
    /computeMetadata/v1/instance/id מזהה ייחודי של מופע מאגר התגים (זמין גם ביומנים). 16a61494692b7432806a16
    (מחרוזת של תווים אלפאנומריים)
    /computeMetadata/v1/instance/region
    ** לא זמין בסביבה הגמישה של App Engine     		האזור שבו השירות הזה פועל, מחזיר projects/PROJECT_NUMBER/regions/REGION projects/12345678912/regions/us-central1
    /computeMetadata/v1/instance/service-accounts/default/email כתובת האימייל של חשבון השירות של זמן הריצה של השירות הזה. service_account@test_project.iam.gserviceaccount.com
    /computeMetadata/v1/instance/service-accounts/default/token יוצר אסימון גישה מסוג OAuth2 לחשבון השירות של השירות הזה. נקודת הקצה הזו תחזיר תגובת JSON עם מאפיין access_token. {
    "access_token":"<TOKEN>",
    "expires_in":1799,
    "token_type":"Bearer"
    }

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