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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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