במדריך הזה מוסבר איך Cloud Run מטפל בפריסות, והוא מחולק לשלושה תחומים:
- סוגי פריסה: מה אתם מביאים ל-Cloud Run, כמו קוד מקור או קובצי אימג' של קונטיינרים.
- משאבי Cloud Run: מה הפריסה שלכם מפעילה ב-Cloud Run (שירות, משימה, מאגר עובדים או מכונה).
- שיטות פריסה: איך מבצעים את הפריסה, למשל באמצעות מסוף Google Cloud , ה-CLI של gcloud, YAML או Terraform.
סוגי פריסה
ב-Cloud Run יש כמה אפשרויות פריסה. אחרי הפריסה, כל הפריסות, ההרצות או היצירות מופעלות כקונטיינרים בסביבת ארגז חול בתשתית מנוהלת לחלוטין וניתנת להרחבה של Cloud Run. בטבלה הבאה מוצגות אפשרויות הפריסה הנתמכות לכל סוג משאב:
| אפשרות פריסה | שירותים | תעסוקה | מאגרי עובדים | מכונות |
|---|---|---|---|---|
| פריסת קובצי אימג' של קונטיינרים | נתמך | נתמך | נתמך | נתמך |
| פריסה מקוד המקור | נתמך | נתמך | נתמך | — |
| פריסת פונקציות1 | נתמך | — | — | — |
| פריסה רציפה מ-Git | נתמך | — | — | — |
1 פונקציות הן גרסה מיוחדת של פריסת קוד מקור לקוד שמיועד למטרה אחת ומופעל על ידי אירועים.
פריסת קובצי אימג' של קונטיינרים
אפשר לפרוס כל קובץ אימג' של קונטיינר שעומד בדרישות של הסכם זמן הריצה של הקונטיינר ב-Cloud Run לשירות, למשימה, למאגר עובדים או למופע.
פריסה מקוד המקור
כדי לפשט את התהליך, Cloud Run מאפשר לכם ליצור ולפרוס קוד מקור באמצעות פקודה אחת. לפרטים נוספים, אפשר לעיין במאמרים בנושא פריסת שירותים מקוד מקור, הפעלת משימות מקוד מקור ופריסת מאגרי עובדים מקוד מקור.
כשפורסים מקוד מקור, Cloud Build הופך את הקוד לקובץ אימג' של קונטיינר שמאוחסן ב-Artifact Registry. אפשר לפרוס קוד מקור שכולל Dockerfile או שמשתמש באחד מזמני הריצה של השפות הנתמכות.
פונקציות
אתם יכולים לפרוס פונקציות למטרה יחידה שמגיבות לאירועים שמופקים בתשתית ובשירותי הענן. מערכת Cloud Run מפעילה את הפונקציה כשמופעל אירוע שעוקבים אחריו.
פריסת פונקציות היא סוג מיוחד של פריסת קוד מקור, שבה צריך לספק רק את קוד הפונקציה. אפשר לכתוב פונקציות Cloud Run באמצעות מספר שפות תכנות נתמכות.
פריסת פונקציה יוצרת שירות ב-Cloud Run.
פריסה רציפה של קוד מקור מ-Git
בעזרת Cloud Run אפשר להגדיר פריסה רציפה מ-Git. בדומה לפריסות של מקורות, אתם יכולים לפרוס קוד מקור שכולל Dockerfile או שנכתב באחת מסביבות זמן הריצה של השפות הנתמכות.
אפשר לבצע פריסה רציפה מ-Git עבור שירותים של Cloud Run. אפשר להגדיר אותם באופן ידני ב-Cloud Build עבור משימות של Cloud Run.
משאבי Cloud Run
בקטעים הבאים מפורטים משאבי Cloud Run.
השוואה בין משאבי Cloud Run
| תכונה | שירותים | תעסוקה | מאגרי עובדים | מכונות |
|---|---|---|---|---|
| תרחיש ראשי לדוגמה | מבוסס על בקשות (אתרים, ממשקי API, מיקרו-שירותים) | מבוסס-משימות (סקריפטים, עיבוד נתונים, העברות) | מבוסס-אירועים או מבוסס-משיכה (צרכני Kafka/PubSub) | Managed singleton (עומסי עבודה של סוכנים, צרכים ספציפיים של מחשוב) |
| Trigger | בקשות HTTP/gRPC, Eventarc | מצבי הפעלה – רגיל (מיידי), מושהה. טריגרים – הפעלה ידנית, באמצעות Scheduler, באמצעות Workflows |
תמיד פועל או משנה את הגודל באופן אוטומטי באמצעות עבודה ברקע שמבוססת על משיכת נתונים | ללא |
| שינוי גודל | אוטומטי/ידני: שינוי הגודל ל-0 או על סמך בקשות | אוטומטי: מתרחב ל-N משימות עצמאיות שמופעלות ברצף או במקביל. | אוטומטי/ידני: מספר קבוע של מופעים באמצעות התאמה ידנית לעומס או התאמה אוטומטית מובנית לעומס על סמך ניצול מעבד (CPU) או הצטברות הודעות ב-Pub/Sub (התאמה אוטומטית לעומס מבוססת-KEDA באמצעות מידרוג אוטומטי חיצוני) | ללא: ללא שינוי גודל אוטומטי; אפשר לנהל כל אחד בנפרד |
| מחזור חיים | זמני, מצטמצם כשלא פעיל | פועל עד להשלמה למשך עד 7 ימים (קצר טווח) | אפשר לבחור בין תהליכי רקע שפועלים תמיד לבין מופעים זמניים שניתנים להרחבה אוטומטית. | לזמן ארוך (יכולות לפעול במשך ימים או שבועות) ומופעלות מחדש אוטומטית ללא הגבלה |
| כתובת | כתובת URL יציבה של שירות (עם איזון עומסים) | אין נקודת קצה ציבורית. כתובת URL פנימית לטריגרים (למשל, מתזמן) |
אין נקודת קצה ציבורית. גישה פרטית ישירה מ-VPC על בסיס כתובת IP |
כתובת URL נפרדת לכל מופע |
| תנועה נכנסת | HTTP/gRPC ציבורי/פנימי | ללא | תעבורת נתונים נכנסת (ingress) ברמה 4 שמבוססת על IP עם Direct VPC | כתובת URL ציבורית או פנימית לכל מופע |
| חיוב | מבוסס-בקשה או מבוסס-מופע | משך הביצוע | משך הזמן לכל מופע | משך הזמן לכל מופע |
שירותי Cloud Run
שירות הוא סוג המשאב העיקרי ב-Cloud Run, שמייצג עומס עבודה מבוסס-בקשות שמתאים באופן אוטומטי את מספר המקרים של קונטיינרים כדי לטפל בתעבורת אינטרנט נכנסת, בבקשות HTTP או באירועים. כל שירות ממוקם בGoogle Cloud אזור ספציפי. כדי לספק יתירות ומעבר לגיבוי, Cloud Run משכפל באופן אוטומטי שירותים בכמה אזורים בתוך אזור.Google Cloud בפרויקט נתון יכולים לפעול שירותים רבים באזורים שונים.
כל שירות חושף נקודת קצה ייחודית. כברירת מחדל, Cloud Run מתאים את עצמו לעומס באופן אוטומטי כדי לטפל בבקשות נכנסות. אם צריך, אפשר לשנות את התנהגות ההתאמה להתאמה ידנית. אפשר לפרוס שירות ממכולה, ממאגר או מקוד מקור.
בתרשים הבא מוצג מודל המשאבים של Cloud Run לשירותים:
בתרשים מוצג Google Cloud פרויקט שמכיל שלושה שירותי Cloud Run: שירות א', שירות ב' ושירות ג'. לכל אחד מהשירותים יש כמה עדכונים:
- שירות א' מקבל כמה בקשות, ולכן Cloud Run הפעיל כמה מופעים כדי לטפל בעומס. כל אחד מהמופעים האלה מפעיל רק מאגר נתונים אחד (מאגר הנתונים של האפליקציה).
- לשירות ב' אין בקשות, לכן הוא במצב המתנה ו-Cloud Run לא מפעיל אף מכונה.
- לשירות C יש בקשות, והוא עבר שינוי גודל כדי לטפל בעומס על ידי יצירת כמה מופעים. במקרה הזה, כל אחד מהמופעים האלה מריץ קבוצה של כמה קונטיינרים. בכל קבוצה, רק קונטיינר הכניסה מקבל את הבקשה, אבל הקונטיינרים האחרים עוזרים למלא את הבקשה.
גרסאות של שירות Cloud Run
כל פריסה לשירות יוצרת גרסה. גרסת עדכון מורכבת מתמונה אחת או יותר של מאגר תגים, יחד עם הגדרות תצורה כמו משתני סביבה, מגבלות זיכרון או ערך של בקשות מקבילות.
אי אפשר לשנות את הגרסה אחרי שיוצרים אותה. לדוגמה, כשפורסים קובץ אימג' של קונטיינר לשירות חדש, Cloud Run יוצר את הגרסה הראשונה. אם לאחר מכן תפרסו קובץ אימג' של קונטיינר אחר לאותו שירות, Cloud Run ייצור גרסה שנייה. אם לאחר מכן מגדירים משתנה סביבה, Cloud Run יוצר גרסה שלישית. עם הזמן, Cloud Run מסיר גרסאות שלא נעשה בהן שימוש.
Cloud Run מנתב בקשות באופן אוטומטי בהקדם האפשרי לגרסה האחרונה של השירות שפועלת בצורה תקינה.
מופעים של שירות Cloud Run
Cloud Run מבצע התאמה אוטומטית לעומס (autoscaling) של כל גרסה של שירות שמקבל בקשות, כך שמספר המכונות יתאים לטיפול בכל הבקשות האלה. הערה מופעים יכולים לקבל הרבה בקשות בו-זמנית. ההגדרה request concurrency מאפשרת להגדיר את המספר המקסימלי של בקשות שאפשר לשלוח במקביל לכל מופע של עדכון.
משימות ב-Cloud Run
כל משימה ממוקמת באזור ספציפי Google Cloudומורכבת ממשימה אחת או יותר שמוציאות לפועל קונטיינר אחד או יותר עד להשלמה. משימות של עבודות הן עצמאיות ויכולות לפעול במקביל בהרצת עבודה נתונה.
הפעלות של משימות ב-Cloud Run
כשמריצים משימה, Cloud Run יוצר הפעלה של המשימה ומתחיל את כל המשימות של המשימה. כדי שביצוע המשימה יצליח, כל המשימות בביצוע המשימה צריכות להסתיים בהצלחה. אפשר להגדיר פסק זמן למשימה ולציין את מספר הניסיונות החוזרים במקרה של כשל במשימה.
אם מספר הניסיונות החוזרים של משימה מסוימת חורג מהמספר המקסימלי, Cloud Run מסמן את המשימה כנכשלה ואת הג'וב כנכשל. כברירת מחדל, המשימות מבוצעות במקביל עד למקסימום של 100, אבל אתם יכולים לציין מקסימום נמוך יותר אם אחד מהמשאבים התומכים, כמו מסד נתונים, דורש זאת.
משימות של משימות ב-Cloud Run
בכל הרצה של עבודה מבוצעות כמה משימות במקביל, וכל משימה מריצה מופע אחד. Cloud Run מנסה להריץ מחדש באופן אוטומטי את כל המשימות שנכשלו, בהתאם להגדרות המשימה של maxRetries.
מאגרי עובדים ב-Cloud Run
מאגרי עובדים הם משאב ב-Cloud Run שנועד במיוחד לעומסי עבודה שלא קשורים לבקשות, כמו תורים של משימות pull. שימו לב שאין למאגרי עובדים את התכונות הבאות:
- אין נקודת קצה או כתובת URL
- אין דרישה שהקונטיינר שנפרס יאזין לבקשות ביציאה
- אין התאמה אוטומטית לעומס
בדומה לשירות Cloud Run, כשפורסים או מעדכנים מאגר עובדים נוצרת גרסה חדשה.
אפשר להגדיל את מספר המופעים במאגר העובדים באופן ידני לפי הצורך כדי לטפל בעומסי העבודה. אפשר גם להגדיר שינוי גודל אוטומטי של מאגרי עובדים באמצעות מדדים חיצוניים, כדי לטפל בשינוי הגודל של עומסי עבודה שמבוססים על מקורות כמו מינויים ל-Pub/Sub, שאילתות Prometheus או תורים של Kafka.
כשמאגר העובדים מחובר לרשת של ענן וירטואלי פרטי (VPC), כל מופע של מאגר העובדים מקבל כתובת IP ברשת ה-VPC ויכול לשלוח ולקבל תעבורה אל ה-VPC וממנו.
מכונות של Cloud Run
מכונה של Cloud Run מייצגת סביבת זמן ריצה עצמאית וייחודית. בניגוד לשירות – שבו מתבצעת הגדלה אוטומטית או ידנית של מספר המקרים של קונטיינרים כדי לטפל בטראפיק – מופע של Cloud Run הוא משאב ברמה העליונה עם כתובת URL ישירה משלו ופעולות משלו במחזור החיים.
כל מכונת Cloud Run כוללת את התכונות הבאות:
- נקודת קצה ייעודית של כתובת URL: כברירת מחדל, מוקצית כתובת URL יציבה לכניסה. אפשר להשבית את כתובת ה-URL שמוגדרת כברירת מחדל כדי לאפשר תנועה רק מנתיבי הכניסה האחרים של המופע.
- מדיניות הפעלה מחדש: תומכת בתנאי הפעלה מחדש (
always,on-failure,never) כדי לשחזר באופן אוטומטי את תהליך המכולה במקרה של קריסות. - הקצאת מעבד משותף: פועל במודל של מעבד משותף שבו המעבד מוקצה במלואו על בסיס תקציב של שימוש חורג, והשימוש בו מוגבל ל-6.25% ממגבלת המשאבים הבסיסית מחוץ לתקציב הזה.