מה זה 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.

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

שירותי Cloud Run

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

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

שירות 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) מחוץ לבקשות.

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

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

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

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

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

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

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

מערכת קבצים של קונטיינר חד-פעמי

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

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

כדי לשמור קבצים באופן קבוע, צריך לשלב עם 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.

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

Google Cloud integrations

‫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 כדי לספק ביצוע אסינכרוני שניתן להרחבה ומהימן.

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

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

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

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

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

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

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

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

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