מה זה Cloud Run

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

אפשר לפרוס ב-Cloud Run קוד שנכתב בכל שפת תכנות, אם אפשר ליצור ממנו קובץ אימג' של קונטיינר. למעשה, פיתוח קובצי אימג' של קונטיינרים הוא אופציונלי. אם אתם משתמשים ב-Go, ‏ Node.js, ‏ Python,‏ Java,‏ ‎.NET, ‏ Ruby או ב-framework נתמך, אתם יכולים להשתמש באפשרות פריסה מבוססת-מקור שיוצרת את הקונטיינר בשבילכם, בהתאם לשיטות המומלצות לשפה שבה אתם משתמשים.

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

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

שירותים, משימות, מאגרי עובדים ומופעים: ארבע דרכים להרצת הקוד

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

מחליטים איזה Cloud Run מתאים לעומס העבודה.
בוחרים את משאב Cloud Run שמתאים לעומס העבודה.

בטבלה הבאה מוצגות האפשרויות שזמינות בכל סוג של משאב Cloud Run.

משאב תיאור
שירות השירות מגיב לבקשות HTTP שנשלחות לנקודת קצה ייחודית ויציבה, באמצעות מופעי קונטיינר בלי שמירת מצב שתומכים בהתאמה אוטומטית לעומס דינמי ובהתאמה ידנית לעומס, וגם מגיב לאירועים ולפונקציות.
משימה מבצע משימות שניתנות להרצה במקביל, שמופעלות באופן ידני או לפי לוח זמנים, ופועלות עד להשלמה.
מאגר עובדים מטפל בעומסי עבודה ברקע שפועלים תמיד, כמו עומסי עבודה מתורי הודעות (Kafka,‏ Pub/Sub,‏ RabbitMQ).
Instance הוא מריץ עומסי עבודה לטווח ארוך שזקוקים לסביבת זמן ריצה יחידה.

שירותי Cloud Run

שירות Cloud Run מספק את התשתית שדרושה להפעלת נקודת קצה אמינה של HTTPS. כדי להשתמש בשירות הזה, צריך לוודא שהקוד שלכם מאזין ליציאת TCP ומטפל בבקשות HTTP נכנסות.

הדיאגרמה הבאה ממחישה כיצד שירות Cloud Run מריץ כמה מופעי קונטיינרים כדי לעבד בקשות אינטרנט ואירועים מלקוח:

שירות Cloud Run מפעיל קונטיינרים כדי לטפל בבקשות אינטרנט ובאירועים

שירות רגיל כולל את התכונות הבאות:

נקודת קצה (endpoint) ייחודית של HTTPS לכל שירות
לכל שירות ב-Cloud Run יש נקודת קצה של HTTPS בתת-דומיין ייחודי של דומיין *.run.app – ואפשר גם להגדיר דומיינים מותאמים אישית. ‫Cloud Run מנהל את TLS בשבילכם ותומך ב-WebSockets, ב-HTTP/2 (מקצה לקצה) וב-gRPC (מקצה לקצה).
התאמה מהירה לעומס (auto-scaling) על סמך בקשות
‫
Cloud Run מבצע הרחבה מהירה כדי לטפל בכל הבקשות הנכנסות או כדי לטפל בעלייה בשימוש במעבד (CPU) מחוץ לבקשות אם הגדרת החיוב מוגדרת לחיוב מבוסס-אינסטנס. שירות יכול להתרחב במהירות עד אלף מופעים, או אפילו יותר אם תבקשו להגדיל את המכסה. אם הביקוש יורד, Cloud Run מסיר קונטיינרים לא פעילים. אם אתם חוששים לגבי עלויות או עומס יתר על מערכות במורד הזרם, אתם יכולים להגביל את המספר המקסימלי של המקרים.
קביעת קנה מידה ידנית אופציונלית
כברירת מחדל, Cloud Run מתאים את מספר המכונות באופן אוטומטי כדי לטפל בתעבורת נתונים גדולה יותר, אבל אפשר לשנות את ההתנהגות הזו באמצעות התאמה ידנית לעומס כדי לשלוט בהתנהגות ההתאמה לעומס.
ניהול תנועה מובנה

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

לדוגמה, אפשר להתחיל בשליחת 1% מהבקשות לגרסה חדשה, ולהגדיל את האחוז הזה תוך כדי מעקב אחרי נתוני הטלמטריה.

שירותים ציבוריים ופרטיים

אפשר להגיע לשירות Cloud Run מהאינטרנט, או להגביל את הגישה בדרכים הבאות:

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

צמצום הפעולה לאפס ומספר מינימלי של מופעים

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

צמצום הפעולה לאפס

אם לא יתקבלו בקשות לשירות, גם המופע האחרון שנותר יוסר. התנהגות כזו נקראת בדרך כלל 'התאמה ל-0'.

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

שינוי התנהגות ההתאמה

אפשר לשנות את התנהגות ברירת המחדל הזו באחת מהדרכים הבאות:

תמחור לפי שימוש בשירותים

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

יש שתי הגדרות חיוב שאפשר להפעיל:

מבוסס על בקשה
אם מופע לא מעבד בקשות, לא תחויבו. אתם משלמים עמלה לכל בקשה.
מבוסס-מכונה
אתם מחויבים על כל משך החיים של מופע. אין עמלה לכל בקשה.

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

מערכת קבצים של מאגר חד-פעמי

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

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

כדי לשמור קבצים באופן קבוע, צריך לשלב עם Cloud Storage או לטעון מערכת קבצים ברשת (NFS).

מתי כדאי להשתמש בשירותי Cloud Run

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

אתרים ואפליקציות אינטרנט
ליצור את אפליקציית האינטרנט באמצעות הסטאק המועדף, לגשת למסד נתוני ה-SQL ולעבד דפי HTML דינמיים.
ממשקי API ומיקרו-שירותים
אפשר ליצור API בארכיטקטורת REST, API ל-GraphQL או מיקרו-שירותים פרטיים שמתקשרים באמצעות HTTP או gRPC.
עיבוד נתונים בסטרימינג
שירותי Cloud Run יכולים לקבל הודעות ממינויי שליחה (push) ב-Pub/Sub ואירועים מ-Eventarc.
עומסי עבודה אסינכרוניים
פונקציות Cloud Run יכולות להגיב לאירועים אסינכרוניים, כמו הודעה בנושא Pub/Sub, שינוי בקטגוריה של Cloud Storage או אירוע Firebase.
הסקת מסקנות מ-AI
שירותי Cloud Run, עם או בלי GPU מוגדר, יכולים לארח עומסי עבודה של AI, כמו מודלים של הסקת מסקנות ואימון מודלים.

משימות ב-Cloud Run

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

משימות מערך הן דרך מהירה יותר להריץ משימות

עבודה יכולה להפעיל מופע יחיד כדי להריץ את הקוד – זו דרך נפוצה להריץ סקריפט או כלי.

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

בתרשים הבא אפשר לראות איך עבודה עם שבע משימות אורכת יותר זמן כשהיא מורצת ברצף, לעומת אותה עבודה כשאפשר לעבד ארבע משימות עצמאיות במקביל:

משימות מערך הן דרך מהירה יותר להריץ משימות שאפשר להריץ במקביל

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

מתי כדאי להשתמש במשימות ב-Cloud Run

משימות ב-Cloud Run מתאימות להרצת קוד שמבצע עבודה (משימה) ומפסיק לפעול כשהעבודה מסתיימת. הנה כמה דוגמאות:

סקריפט או כלי
להריץ סקריפט כדי לבצע העברות של מסדי נתונים או משימות תפעוליות אחרות.
Array job
ביצוע עיבוד מקבילי מאוד של כל הקבצים בקטגוריה של Cloud Storage.
משימה מתוזמנת
ליצור ולשלוח חשבוניות במרווחי זמן קבועים, או לשמור את התוצאות של שאילתת מסד נתונים כ-XML ולהעלות את הקובץ כל כמה שעות.
עומסי עבודה של AI
משימות Cloud Run עם GPU מוגדר או בלי GPU מוגדר יכולות לארח עומסי עבודה של AI, כמו הסקת מסקנות באצווה, כוונון עדין של מודלים ואימון מודלים.

מאגרי עובדים ב-Cloud Run

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

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

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

  • מאגרי עובדים מנהלים השקות על ידי פיצול מופעים בין גרסאות, במקום לפצל תנועה. לדוגמה, במאגר עובדים עם ארבעה מופעים, אפשר להקצות 25% (מופע אחד) לגרסה חדשה ו-75% (שלושה מופעים) לגרסה יציבה.

  • מאגרי עובדים תומכים בDirect VPC egress ו-ingress, ואין להם נקודת קצה או כתובת URL עם איזון עומסים. מידע נוסף על תמיכה בשרת מטא-נתונים (MDS) ועל אחזור כתובות ה-IP הפרטיות של מופע מאגר העובדים זמין במאמר חוזה זמן הריצה של הקונטיינר.

  • ב-Cloud Run, החיוב מתבצע רק על משך הזמן שבו מופעלים מופעי worker pool.

מתי כדאי להשתמש במאגרי עובדים ב-Cloud Run

מאגרי עובדים לא מחייבים נקודות קצה (endpoint) ציבוריות של HTTP. כך הרשת שלכם בטוחה יותר וקוד האפליקציה פשוט יותר. בנוסף, לא צריך לנהל יציאות לבדיקות תקינות. מקרי השימוש הבאים רלוונטיים למאגרי עובדים:

  • עומסי עבודה מבוססי-משיכה: פריסת עומס עבודה למשיכת הודעות מתור לעיבוד. לדוגמה, Kafka Consumer,‏ Pub/Sub pull ו-RabbitMQ.

    בתרשים הבא מוצגים תרחישי שימוש לפריסת מאגרי עובדים לעומסי עבודה מבוססי-משיכה:

    עומסי עבודה מבוססי-משיכה במאגרי עובדים ב-Cloud Run

    בתרחיש לדוגמה של Pub/Sub, מנוי Cloud Run עם שינוי גודל אוטומטי מושך הודעות ממינוי Pub/Sub. בתרחיש לדוגמה של Kafka, צרכן Cloud Run עם שינוי גודל אוטומטי מושך הודעות מנושא Kafka.

  • עומסי עבודה כלליים שלא קשורים לבקשות: הפעלת עומס עבודה מבוסס-קונטיינר שלא מיועד לטיפול בבקשות נכנסות.

מכונות של Cloud Run

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

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

השוואה בין שירות Cloud Run לבין מופע Cloud Run
השוואה בין שירות Cloud Run לבין מופע Cloud Run.

מכונת Cloud Run כוללת את המאפיינים הבאים:

  • ניתן לניהול בנפרד: אתם יכולים ליצור, לעדכן ולמחוק כל מכונה בנפרד, להפעיל ולהפסיק את המכונה ולעקוב אחרי ההרצות.
  • ניתן להפנות לכל אחת מהן בנפרד: לכל מופע מוקצית כתובת URL ייחודית.
  • לזמן ארוך: המכונה יכולה לפעול ללא הפרעה במשך שעות או ימים, או אפילו יותר אם היא מוגדרת להפעלה מחדש אוטומטית אחרי עדכוני תשתית תקופתיים (כל שבוע עד שבועיים).
  • יצירה מהירה: הקצאת המופע והפעלתו מתבצעות תוך 20 שניות לערך או פחות.

מתי כדאי להשתמש במכונות של Cloud Run

מופעי Cloud Run מיועדים לעומסי עבודה (workloads) של מחשוב מתמשך וייחודי, שנועדו להפעיל עומסי עבודה של סוכנים וזרימות עבודה שאינן מבוססות על AI. תרחישים לדוגמה:

סוכני AI לטווח ארוך ומנועי תהליכי עבודה מבוססי-AI
יצירת סוכנים ארוכי טווח ברקע שמבצעים תוכניות ביצוע מרובות שלבים, מריצים עוזרים אסינכרוניים לתכנות או מנהלים תהליכי עבודה עם שמירת מצב שדורשים סביבה של מופע יחיד.
מחשוב ללא שרת (serverless computing) לטווח ארוך
פריסת שרתים קלים שפועלים תמיד, בדומה לשרת וירטואלי פרטי (VPS) שפועל באופן רציף. האפשרות הזו אידיאלית אם אתם רוצים עומסי עבודה שלא דורשים שינוי אוטומטי של קנה המידה או טיפול בתנועה בקנה מידה אינטרנטי, ואתם רוצים לתת עדיפות לעלות נמוכה ולמשך חיים ארוך של סינגלטון על פני זמינות גבוהה.
סביבות פיתוח ולולאות ניפוי באגים
פריסת סביבות ייעודיות לניפוי באגים בתהליכי קונטיינר מרחוק, סנכרון שינויים בקוד ופתרון בעיות של קריסות בלי סיום אוטומטי של הקונטיינר.

Google Cloud שילובים

‫Cloud Run משתלב עם המערכת האקולוגית הרחבה של Google Cloud, שמאפשרת לכם ליצור אפליקציות עם כל התכונות.

שילובים חיוניים כוללים:

אחסון הנתונים
‫
Cloud Run משתלב עם Cloud SQL (MySQL,‏ PostgreSQL ו-SQL Server מנוהלים), Memorystore (Redis ו-Memcached מנוהלים), Firestore,‏ Spanner,‏ Cloud Storage ועוד. רשימה מלאה מופיעה במאמר בנושא אחסון נתונים.
רישום ביומן ודיווח שגיאות
יומני קונטיינרים מוזנים אוטומטית ל-Cloud Logging. אם יש חריגים ביומנים, Error Reporting יצבור אותם ואז ישלח לכם התראה. השפות הבאות נתמכות: Go,‏ Java,‏ Node.js,‏ PHP,‏ Python,‏ Ruby ו-NET.
זהות השירות
כל גרסה של Cloud Run מקושרת לחשבון שירות, וספריות הלקוח משתמשות בחשבון השירות הזה באופן שקוף כדי לבצע אימות מול Google Cloud ממשקי API
. Google Cloud
פיתוח רציף (continuous delivery)
אם אתם מאחסנים את קוד המקור ב-GitHub, אתם יכולים להגדיר את Cloud Run כך שיפרוס אוטומטית קומיטים חדשים.
רשתות פרטיות
מכונות Cloud Run יכולות להגיע למשאבים ברשת הענן הווירטואלי הפרטי (VPC) באמצעות מחבר של חיבור לרשת (VPC) מאפליקציית serverless. כך השירות יכול להתחבר למכונות וירטואליות ב-Compute Engine, או למוצרים שמבוססים על Compute Engine כמו Google Kubernetes Engine או Memorystore.
ממשקי API שלGoogle Cloud
הקוד של השירות שלכם מבצע אימות שקוף עם ממשקי API. Google Cloud הם כוללים את ממשקי ה-API של AI ולמידת מכונה, כמו Cloud Vision API,‏ Speech-to-Text API,‏ AutoML Natural Language API,‏ Cloud Translation API ועוד רבים אחרים.
משימות ברקע
אפשר לתזמן את הפעלת הקוד למועד מאוחר יותר או מיד אחרי החזרת בקשה לאחזור מהרשת. ‫Cloud Run פועל בצורה טובה עם Cloud Tasks כדי לספק ביצוע אסינכרוני שניתן להרחבה ומהימן.

במאמר חיבור ל Google Cloud שירותים מופיעה רשימה של שירותים Google Cloud רבים שפועלים היטב עם Cloud Run.

הקוד פועל בקובץ אימג' של קונטיינר

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

אם אתם לא מכירים את המושג'מאגרי תגים', הנה הסבר קצר.

פיתוח קובצי אימג' של קונטיינרים

כמו שרואים בתרשים, משתמשים בקוד מקור, בנכסים ובתלות בספריות כדי ליצור קובץ אימג' בקונטיינר. קובץ האימג' הזה הוא חבילה שמכילה את כל מה שהשירות צריך כדי לפעול, כולל ארטיפקטים של build, נכסים, חבילות מערכת, ובאופן אופציונלי גם זמן ריצה. אפליקציות בקונטיינרים הן ניידות באופן מובנה, ואפשר להפעיל אותן בכל מקום שבו אפשר להפעיל קונטיינר. פריטי מידע שנוצרו בתהליך ה-build כוללים קבצים בינאריים שעברו קומפילציה או קובצי סקריפט, וסביבות זמן ריצה כוללות את סביבת זמן הריצה של JavaScript ב-Node.js או מכונה וירטואלית של Java.

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

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

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