מזהה אזור
REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, המחרוזת REGION_ID.r כלולה בכתובות ה-URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.
המדריך הזה מיועד למשתמשים שמכירים את App Engine, והוא מספק מבוא ל-Cloud Run. הוא כולל את נקודות הדמיון וההבדלים העיקריים בין הפלטפורמות 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, אבל הם מציעים ללקוחות הרבה יותר גמישות בהטמעה של השירותים האלה. הגמישות הזו, יחד עם שילובים משופרים עם שירותי 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
|
|
|||||||||||||||||||
| כתובת URL של גרסה/תיקון |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
|
|||||||||||||||||||
שינוי גודל |
|||||||||||||||||||||
| התאמה אוטומטית לעומס | כן | כן | כן | ||||||||||||||||||
| שינוי גודל ידני | כן | כן | כן | ||||||||||||||||||
| צמצום הפעולה לאפס | כן | לא | כן | ||||||||||||||||||
| בקשות חימום | ניתן להגדרה | לא | אוטומטי | ||||||||||||||||||
| זמן קצוב לתפוגה של מופע ללא פעילות (אחרי סיום הבקשה האחרונה) | עד 15 דקות | תלוי בהגדרת החיוב. שימוש בחיוב על בסיס מופע כדי לדמות את ההתנהגות של App Engine | |||||||||||||||||||
| משך הבקשה הסתיים |
|
60 דקות | אפשר להגדיר עד 60 דקות (ברירת מחדל: 5 דקות) | ||||||||||||||||||
פריסה |
|||||||||||||||||||||
| מהמקור | כן | כן | |||||||||||||||||||
| קובץ אימג' של קונטיינר | לא | כן (סביבות ריצה בהתאמה אישית) | כן | ||||||||||||||||||
| מאגרי Sidecar | לא | כן. קונטיינרים מסוג Sidecar פועלים לצד הקונטיינר הראשי ומשרתים בקשות אינטרנט. | |||||||||||||||||||
| בדיקות תקינות | אוטומטי. App Engine מבצע בדיקות מוכנות ופעילות במופעים שלכם. | ניתן להגדרה. אתם מגדירים את בדיקות ההפעלה והפעילות באופן מפורש בהגדרות של משאב Cloud Run, ומציינים פרטים כמו סוג הבדיקה (TCP, HTTP ו-gRPC), הנתיב, היציאה, העיכוב הראשוני, התקופה, הזמן הקצוב לתפוגה, סף ההצלחה וסף השגיאה. | |||||||||||||||||||
משאבי מחשוב |
|||||||||||||||||||||
| vCPU |
|
עד 80 ליבות וירטואליות (vCPU) | עד 8 ליבות vCPU | ||||||||||||||||||
| זיכרון | עד 6.5GB לכל vCPU | עד 32GB | |||||||||||||||||||
| יחידות GPU | לא | כן. אפשר להגדיר יחידת GPU אחת לכל מופע של Cloud Run. | |||||||||||||||||||
| חיבורים של נפחי אחסון | לא | כן. אפשר לטעון קטגוריה של Cloud Storage ישירות למערכת הקבצים של הקונטיינר. | |||||||||||||||||||
מודל התמחור |
|||||||||||||||||||||
| עמלה לכל בקשה | לא |
לא, כשמשתמשים בחיוב לפי מופע. כן, כשמשתמשים בחיוב על סמך בקשות. |
|||||||||||||||||||
| מספר מינימלי של מכונות וירטואליות במצב לא פעיל | אותה עלות כמו מופעים פעילים | עלות נמוכה יותר למכונות וירטואליות מינימליות במצב לא פעיל (ראו זמן שימוש במכונת קונטיינר לחיוב) | |||||||||||||||||||
| הנחות תמורת התחייבות לשימוש (CUD) | לא | כן | |||||||||||||||||||
| חיוב לפי מופע (עלות למופע לשעה) | מופע F4/B4: $0.2 |
|
|
||||||||||||||||||
אבטחה |
|||||||||||||||||||||
| הגדרות של תעבורת נתונים נכנסת (ingress) | כן | כן | כן | ||||||||||||||||||
| תפקיד מפעיל | לא | כן | |||||||||||||||||||
| IAP | כן | כן | כן | ||||||||||||||||||
| חומות אש | כן | כן | הגדרה באמצעות Google Cloud Armor | ||||||||||||||||||
| Secret Manager | כן, באמצעות ספריות לקוח של Cloud. | כן. אפשר לטעון כל סוד כנפח או להעביר סוד באמצעות משתני סביבה. | |||||||||||||||||||
קישוריות |
|||||||||||||||||||||
| דומיינים מותאמים אישית | כן | כן | כן | ||||||||||||||||||
| קישוריות ל-VPC (כולל VPC משותף) | כן | לא רלוונטי | כן | ||||||||||||||||||
| הגדרות של תעבורת נתונים יוצאת (egress) ב-VPC | כן | לא רלוונטי | כן | ||||||||||||||||||
| איזון עומסים במספר אזורים | לא | כן | |||||||||||||||||||
| סטרימינג מהשרת | לא | כן | |||||||||||||||||||
קישוריות – תעבורת נתונים יוצאת (egress) ישירה של VPC |
|||||||||||||||||||||
| שלב ההשקה | תצוגה מקדימה | לא רלוונטי | GA | ||||||||||||||||||
| תגים של רשתות | YAML | לא רלוונטי | נתמך | ||||||||||||||||||
| VPC Flow Logs | לא נתמך | לא רלוונטי | נתמך | ||||||||||||||||||
| NAT ציבורי | נתמך | לא רלוונטי | נתמך | ||||||||||||||||||
| Private NAT | לא נתמך | לא רלוונטי | נתמך | ||||||||||||||||||
| תת-רשתות עם כתובות IPv4 ו-IPv6 | נתמך | לא רלוונטי | נתמך | ||||||||||||||||||
| שיטת ההגדרה | YAML | לא רלוונטי | Google Cloud מסוף, gcloud, YAML, Terraform | ||||||||||||||||||
| תמיכה ב-VPC משותף | נתמך | לא רלוונטי | נתמך | ||||||||||||||||||
גישה Google Cloud לשירותים |
|||||||||||||||||||||
| Cloud SQL | כן | כן | כן | ||||||||||||||||||
| ספריות לקוח ב-Cloud | אם אתם משתמשים ב-Cloud Client Libraries ב-App Engine, לא תצטרכו לשנות שום דבר כשאתם עוברים ל-Cloud Run. ספריות הלקוח האלה פועלות בכל מקום, ולכן האפליקציה שלכם ניידת יותר. | ||||||||||||||||||||
| שירותים בחבילה מדור קודם של App Engine | כן (Java, Python, Go, PHP בלבד) | לא | לא | ||||||||||||||||||
מודל של משאבים
מודל המשאבים של 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 – גרסה 1 | 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: |
version1 מוגדר עם instance_class: F4, ואילו version2, שלא צוין לו ערך עבור instance_class, מוגדר עם ברירת המחדל instance_class: F1.
ב-Cloud Run, כל הגדרות התצורה שצוינו מוחלות, אבל כל ההגדרות שלא צוינו שומרות על הערכים הקיימים שלהן. צריך לספק ערכים רק להגדרות שרוצים לשנות. לדוגמה:
| Cloud Run service-a revision1 | Cloud Run service-a revision2 |
|---|---|
| פקודת פריסה | |
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 |
| מקסימום בו-זמניות (בקשות) | 10 | ללא | 80 |
| משך הבקשה הסתיים |
|
60 דקות | 5 דקות |
| יעד ניצול המעבד | 60% | 50% | 60% |
| מספר מכונות מקסימלי | ללא | 20 | 100 |
| מינימום מכונות | 0 | 2 | 0 |
נקודת כניסה
כשפורסים מקוד המקור, App Engine קורא את פקודת נקודת הכניסה מהמאפיין entrypoint בקובץ app.yaml. אם לא מסופקת נקודת כניסה, נעשה שימוש בברירת מחדל ספציפית לזמן הריצה. כשפורסים מקוד המקור, Cloud Run משתמש ב-Google Cloud's buildpacks, ולחלק מהשפות אין נקודת כניסה שמוגדרת כברירת מחדל. כלומר, צריך לספק נקודת כניסה, אחרת ה-build ייכשל. לדוגמה, Python buildpacks מחייב לספק קובץ Procfile או לציין את משתנה סביבת ה-build GOOGLE_ENTRYPOINT.
כדאי לעיין במסמכי התיעוד של buildpacks כדי לראות אם יש דרישות הגדרה ספציפיות לשפה.
בדיקות תקינות
ב-App Engine, בדיקות תקינות הן אוטומטיות ברובן ומנוהלות על ידי הפלטפורמה. App Engine מבצע בדיקות פעילות ובדיקות מוכנות כדי לקבוע אם מופע פועל ומוכן לטפל בתנועה. אם מופע נכשל באופן עקבי בבדיקות האוטומטיות, App Engine מסיים את המופע ומחליף אותו במופע חדש כדי להבטיח את המשכיות של השירות.
ב-Cloud Run יש שליטה פרטנית יותר עם בדיקות הפעלה ובדיקות פעילות שאפשר להגדיר. הבדיקות האלה מאפשרות להגדיר מופע תקין, וזה חשוב מאוד למיקרו-שירותים מורכבים.
ב-Cloud Run, אפשר להגדיר את הבדיקות הבאות:
בדיקת מוכנות להפעלה כדי להגדיר מתי קונטיינר התחיל לפעול ומוכן לשרת תנועה. כשמגדירים בקשה לבדיקת תקינות (probe) להפעלה, היא משביתה את בדיקות מצב פעילות (liveness) עד שההפעלה מצליחה, וכך מוודאים שבדיקות מצב פעילות (liveness) לא יפריעו להפעלת האפליקציה.
בדיקת פעילות כדי לקבוע מתי להפעיל מחדש קונטיינר. לדוגמה, בדיקות פעילות יכולות לזהות מצב של חסימה הדדית (deadlock) כשמריצים אפליקציה, אבל לא ניתן להתקדם. הפעלה מחדש של קונטיינר במצב כזה מבטיחה שהאפליקציה תהיה זמינה למרות באגים.
מידע נוסף זמין במאמר הגדרת בדיקות תקינות של קונטיינרים לשירותים.
שינוי גודל
למרות ש-Cloud Run ולסביבה הרגילה של App Engine יש תשתית דומה להתאמה לעומס, ב-Cloud Run התהליך יעיל יותר וההתאמה לעומס מהירה יותר, ויש בו אפשרות לצמצום הפעולה לאפס. כתוצאה מכך, יש פחות הגדרות שאפשר לשנות. השיפור הזה מגביל את ההגדרות שניתנות לשינוי להגדרות הבאות:
- מקסימום מספר חיבורים בו-זמניים
- מספר המופעים המקסימלי והמינימלי
- אמצעי בקרה מותאמים אישית של שינוי גודל להגדרת ניצול היעד של CPU ושל פעולות בו-זמניות
כברירת מחדל, יעד ניצול המעבד (CPU) למופעי Cloud Run הוא 60%, אבל אפשר להתאים אישית את הערך הזה כדי לבצע אופטימיזציה לעלות או לביצועים. מידע נוסף זמין במאמר הגדרת אמצעי בקרה מותאמים אישית לשינוי גודל של שירותים.
הסביבה הגמישה של 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, המערכת אוכפת את ההגדרות הנמוכות יותר ברמת השירות וברמת התיקון. מידע נוסף זמין במאמר הגדרת מספר מקסימלי של מופעים לשירותים.
בו-זמניות (concurrency)
הגדרת קיבולת הבקשות של מופע יחיד.
| סביבת ההגדרה | הגדרות |
|---|---|
| סביבה רגילה של 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 | template.scaling.cpuUtilization: 0.X |
שיטת העברה: משתמשים בדגל --scaling-cpu-target כדי להגדיר סף מותאם אישית לניצול המעבד. כברירת מחדל, המערכת להתאמת קנה מידה אוטומטית של 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.scaling.concurrencyUtilization: 0.X |
שיטת העברה: משתמשים בדגל --scaling-concurrency-target
כדי להגדיר את סף ניצול היעד של השימוש בו-זמנית. כברירת מחדל, התכונה להתאמה אוטומטית לעומס ב-Cloud Run מנסה לשמור על מספר הבקשות המקבילות לכל מכונה ב-60% מהערך של מספר הבקשות המקבילות המקסימלי לכל מכונה.
כשמגדירים את הערך הזה, מגדירים את קצב העברת הנתונים שגורם לאירוע של הגדלת הקיבולת.
זמן אחזור
הגדרת חלון זמן להמתנה של משתמש שגורם לשינוי גודל. App Engine מגיב באופן חלקי לתורים של בקשות.
| סביבת ההגדרה | הגדרות |
|---|---|
| סביבה רגילה של App Engine | min_pending_latency וגם max_pending_latency |
| סביבה גמישה של App Engine | לא זמין |
| Cloud Run | אין מקבילה ישירה |
שיטת העברה: התאמה לעומס (autoscaling) ב-Cloud Run מתבצעת לפני שהבקשות מתחילות להצטבר בתור ולפני שחלים שיאים בחביון. אם יש עליות פתאומיות בזמן האחזור, כדאי לשנות את הערך של המספר המקסימלי של בקשות בו-זמניות לכל מופע כדי להבטיח הרחבה מהירה יותר.
מכונות וירטואליות בלי פעילות
הכוונה: ב-App Engine, הגדרות של מכונות במצב המתנה שולטות במאגר של מכונות במצב המתנה שהופעלו מראש, כדי לספוג עליות פתאומיות בתנועה ולשלוט בעלויות.
| סביבת ההגדרה | הגדרות |
|---|---|
| סביבה רגילה של App Engine | min_idle_instances: N או max_idle_instances: N |
| סביבה גמישה של App Engine | לא זמין |
| Cloud Run | אין מקבילה ישירה |
אסטרטגיית העברה: אי אפשר להגדיר ב-Cloud Run מספר מינימלי או מקסימלי נפרד של מופעים לא פעילים. כדי לשמור על המופעים במצב פעיל ומוכנים לתנועה מיידית, וכדי לצמצם את ההשפעה של הפעלה במצב התחלתי (cold start) ב-Cloud Run, אפשר להשתמש בהגדרה scaling.min_instance_count, שמבטיחה שמספר מינימלי של קונטיינרים יפעל תמיד. מידע נוסף זמין במאמר מידע על שינוי גודל אוטומטי של מופעים בשירותי Cloud Run.
הזמן הקצוב לתפוגה של מכונה וירטואלית לא פעילה
ב-App Engine, מופעים לא פעילים נשארים פעילים למשך כ-15 דקות אחרי הבקשה האחרונה. ב-Cloud Run, ההתנהגות הזו נשלטת באמצעות הגדרת החיוב.
כדי לקבל התנהגות חיוב דומה לזו של App Engine, שבה הקצאת המעבד מתבצעת מחוץ לעיבוד הבקשות, צריך להשתמש בחיוב מבוסס-אינסטנס ב-Cloud Run.
אפשרות אחרת היא להשתמש בחיוב לפי בקשה, כדי שהמעבד יוקצה רק במהלך עיבוד הבקשה. בהגדרה הזו, המופע ימשיך לפעול למשך 15 דקות לכל היותר אחרי הבקשה האחרונה, אבל השימוש במעבד יוגבל במהלך זמן ההמתנה הזה.
שינוי גודל בסיסי
| סביבת ההגדרה | הגדרות |
|---|---|
| סביבה רגילה של 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 באמצעות התאמה אוטומטית לעומס (automatic scaling). לשם כך, צריך להגדיר את min-instances ל-0.
שינוי גודל ידני
הפעלת מספר קבוע של מכונות והשבתת התאמה אוטומטית לעומס.
| סביבת ההגדרה | הגדרות |
|---|---|
| סביבה רגילה של App Engine | manual_scaling: instances: N |
| סביבה גמישה של App Engine | manual_scaling: instances: N |
| Cloud Run | scalingMode: MANUALmanualInstanceCount: N |
אסטרטגיית מיגרציה: יש מיפוי ישיר ב-Cloud Run להתאמה ידנית של נפח הפעילות. מגדירים את מצב ההתאמה לעומס לערך MANUAL ברמת השירות ב-Cloud Run, ומציינים את המספר המדויק של המופעים להרצה באמצעות manualInstanceCount. הפעולה הזו זהה להשבתה מלאה של ההתאמה האוטומטית לעומס. מידע נוסף זמין במאמר בנושא התאמה ידנית של נפח הפעילות ב-Cloud Run.
תקופת צינון
הגדרת תקופת צינון אחרי אירוע של הגדלת הקיבולת, לפני שמתרחש אירוע נוסף.
| סביבת ההגדרה | הגדרות |
|---|---|
| סביבה רגילה של App Engine | לא זמין |
| סביבה גמישה של App Engine | automatic_scaling:cool_down_period_sec: N |
| Cloud Run | אין מקבילה ישירה |
אסטרטגיית מיגרציה: לא נדרשת. Cloud Run מתאים את עצמו לעומס בהתאם לביקוש ולניצול, והוא מתוכנן להגיב ביעילות בלי להגדיר תקופת צינון ידנית.
בקשות חימום
Cloud Run מחמם אוטומטית את המופעים באמצעות הפקודה container entrypoint, כך שלא צריך להפעיל ידנית בקשות חימום או להגדיר handler של /_ah/warmup. אם יש לכם קוד שאתם רוצים להפעיל בהפעלת המופע לפני עיבוד הבקשות, אתם יכולים:
תוכן סטטי
בסביבה הרגילה של App Engine, אפשר להציג תוכן סטטי בלי להשתמש במשאבי מחשוב על ידי הצגה מ-Cloud Storage או על ידי הגדרה של handlers.ב-Cloud Run אין אפשרות להשתמש ב-handlers כדי להציג תוכן סטטי, לכן אפשר להציג את התוכן משירות Cloud Run (בדומה לתוכן דינמי) או מ-Cloud Storage.
התפקיד Cloud Run Invoker
בנוסף, Cloud Run מאפשר לשלוט בגישה לשירות באמצעות ניהול זהויות והרשאות גישה (IAM). אפשר להגדיר את קישורי מדיניות IAM לשירות באמצעות ה-CLI של gcloud, המסוף או Terraform.
כדי לשכפל את ההתנהגות של App Engine, אתם יכולים להגדיר את השירות כציבורי על ידי מתן אפשרות לשליחת בקשות לא מאומתות. אפשר להגדיר את זה במהלך הפריסה או על ידי עדכון של קשרי ה-IAM Policy בשירות קיים.
פריסה
משתמשים בדגל הפריסה --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
(string of alpha-numeric characters) |
/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" } |
המאמרים הבאים
- מדריך למתחילים: פריסת שירות אינטרנט באמצעות Cloud Run
- האם האפליקציה שלי מתאימה ל-Cloud Run?
- העברת דומיין בהתאמה אישית ב-App Engine ל-Cloud Load Balancing
- מקורות מידע נוספים: