בדף הזה מפורטות הדרישות העיקריות של קונטיינרים ב-Cloud Run וההתנהגויות שלהם. בנוסף, בדף מוסבר על ההבדלים בין שירותי Cloud Run, משימות Cloud Run ומאגרי עובדים של Cloud Run, במקומות שבהם זה רלוונטי.
שפות ותמונות נתמכות
קובץ האימג' של הקונטיינר יכול להריץ קוד שנכתב בשפת התכנות שתבחרו, ולהשתמש בכל קובץ אימג' בסיסי, בתנאי שהוא עומד במגבלות שמפורטות בדף הזה.
קובצי ההפעלה בקובץ אימג' של קונטיינר חייבים להיות מהודרים ל-Linux 64-bit. ב-Cloud Run יש תמיכה ספציפית בפורמט Linux x86_64 ABI.
Cloud Run מקבל קובצי אימג' של קונטיינרים בפורמטים של קובצי אימג' של Docker Manifest V2, Schema 1, Schema 2 ו-OCI. Cloud Run מקבל גם קובצי אימג' של קונטיינרים שדחוסים בפורמט Zstd.
אם פורסים תמונה מרובת ארכיטקטורות, רשימת המניפסט חייבת לכלול את linux/amd64.
כדי לקבל עדכוני אבטחה ותחזוקה אוטומטיים לפונקציות שנפרסו באמצעות Cloud Run, אפשר להשתמש באחת מתמונות הבסיס של זמן הריצה של Cloud Run שפורסמו על ידי buildpacks של Google Cloud. כאן אפשר לראות את לוח הזמנים של התמיכה בזמן ריצה.
דרישות לגבי מאגרי תגים
כשפורסים קונטיינרים ב-Cloud Run, צריך לעמוד בדרישות הבאות:
קונטיינר שנפרס בשירותים חייב להאזין לבקשות ביציאה הנכונה
שירות Cloud Run מפעיל מכונות של Cloud Run כדי לטפל בבקשות נכנסות. במופע של Cloud Run יש תמיד קונטיינר כניסה יחיד שמקשיב לבקשות, ואפשרות לקונטיינר sidecar אחד או יותר. פרטי ההגדרה הבאים של הניוד רלוונטיים רק למאגר ingress, ולא למאגרי sidecar.
קונטיינר הכניסה בתוך מופע צריך להאזין לבקשות בכתובת 0.0.0.0 ביציאה שאליה נשלחות הבקשות.
חשוב לציין שהקונטיינר של ה-ingress לא צריך להאזין ב-127.0.0.1.
כברירת מחדל, הבקשות נשלחות אל 8080, אבל אפשר להגדיר את Cloud Run כך שהבקשות יישלחו אל היציאה שתבחרו. Cloud Run מוסיף את משתנה הסביבה PORT לקונטיינר של תעבורת הנתונים הנכנסת.
קישוריות לרשת VPC
שירותים ומשימות ב-Cloud Run תומכים בתעבורת נתונים יוצאת (egress) ישירה של VPC. כלומר, הם יכולים לשלוח תעבורה למשאבים פרטיים ברשת ה-VPC שהגדרתם, כמו מסדי נתונים או שירותים פנימיים. שירותים ומשימות ב-Cloud Run לא תומכים בתעבורת נתונים נכנסת (ingress) ישירה של VPC.
מאגרי עובדים ב-Cloud Run תומכים גם בתעבורת נתונים יוצאת (egress) ישירה של VPC וגם בתעבורת נתונים נכנסת (ingress) ישירה של VPC. כשמגדירים Direct VPC לפריסת מאגר העובדים של Cloud Run, כל מופע של עובד מקבל כתובת IP פרטית ברשת ובתת-הרשת שהוגדרו. רק משאבים מרשת ה-VPC יכולים להתחבר לנקודת הקצה של כתובת ה-IP הפרטית של מאגר העובדים. למידע נוסף על קבלת כתובות ה-IP הפרטיות של מופע מאגר העובדים, אפשר לעיין במאמר אחזור כתובות ה-IP הפרטיות באמצעות שרת המטא-נתונים (MDS).
במאגרי עובדים של Cloud Run עם Direct VPC, כמו חיבורי מסד נתונים או כל פרוטוקול מותאם אישית אחר שמבוסס על TCP, הקונטיינר צריך להאזין לחיבורי TCP ביציאה שנחשפת בקובץ האימג' של הקונטיינר דרך קובץ Docker או שצוינה על ידי משתנה הסביבה PORT.
קונטיינר שפועל בהרצת משימה חייב לצאת בסיום
במשימות של Cloud Run, הקונטיינר חייב לצאת עם קוד יציאה 0 כשהמשימה הושלמה בהצלחה, ולצאת עם קוד יציאה שאינו אפס כשהמשימה נכשלה.
מכיוון שעבודות לא אמורות לטפל בבקשות, מאגר התגים לא אמור להאזין ליציאה או להפעיל שרת אינטרנט.
הצפנה בשכבת התעבורה (TLS)
מאגר התגים לא צריך להטמיע אבטחת שכבת התעבורה באופן ישיר. ה-TLS מסתיים ב-Cloud Run עבור HTTPS ו-gRPC, ואז הבקשות מועברות כ-HTTP/1 או gRPC אל הקונטיינר ללא TLS.
אם מגדירים שירות Cloud Run לשימוש ב-HTTP/2 מקצה לקצה, הקונטיינר צריך לטפל בבקשות בפורמט טקסט לא מוצפן של HTTP/2 (h2c), כי Cloud Run עדיין מסיים את ה-TLS באופן אוטומטי.
תשובות (שירותים)
בשירותי Cloud Run, הקונטיינר צריך לשלוח תגובה תוך הזמן שצוין בהגדרת פסק הזמן של הבקשה אחרי שהוא מקבל בקשה, כולל זמן ההפעלה של הקונטיינר. אחרת, הבקשה מסתיימת ומוחזרת שגיאת 504.
שמירת קובצי Cookie במטמון של תגובות
אם התגובה של שירות Cloud Run מכילה כותרת Set-Cookie, Cloud Run מגדיר את הכותרת Cache-Control לערך private כדי שהתגובה לא תישמר במטמון. כך לא יתאפשר למשתמשים אחרים לאחזר את קובץ ה-Cookie.
משתני סביבה
יש קבוצות שונות של משתני סביבה לשירותים ולמשימות ב-Cloud Run.
משתני סביבה לשירותים
משתני הסביבה הבאים מתווספים אוטומטית לכל הקונטיינרים הפעילים, למעט PORT. המשתנה PORT מתווסף רק למאגר התגים של התנועה הנכנסת:
| שם | תיאור | דוגמה |
|---|---|---|
PORT |
היציאה שבה שרת ה-HTTP צריך להאזין. | 8080 |
K_SERVICE |
השם של שירות Cloud Run שמופעל. | hello-world |
K_REVISION |
השם של גרסת Cloud Run שמופעלת. | hello-world.1 |
K_CONFIGURATION |
השם של הגדרת Cloud Run שיצרה את הגרסה. | hello-world |
משתני סביבה למשרות
למשימות Cloud Run מוגדרים משתני הסביבה הבאים:
| שם | תיאור | דוגמה |
|---|---|---|
CLOUD_RUN_JOB |
השם של משימת Cloud Run שמופעלת. | hello-world |
CLOUD_RUN_EXECUTION |
השם של ההפעלה של Cloud Run שמופעלת. | hello-world-abc |
CLOUD_RUN_TASK_INDEX |
האינדקס של המשימה. הערך מתחיל ב-0 למשימה הראשונה ועולה ב-1 לכל משימה עוקבת, עד למספר המקסימלי של המשימות פחות 1. אם מגדירים את --parallelism למספר גדול מ-1, יכול להיות שהמשימות לא יסודרו לפי סדר האינדקס. לדוגמה, יכול להיות שמשימה 2 תתחיל לפני משימה 1. |
0 |
CLOUD_RUN_TASK_ATTEMPT |
מספר הפעמים שהייתה ניסיון חוזר להפעלת המשימה. הערך מתחיל ב-0 בניסיון הראשון וגדל ב-1 בכל ניסיון חוזר, עד שמגיעים לערך המקסימלי של הניסיונות החוזרים. | 0 |
CLOUD_RUN_TASK_COUNT |
מספר המשימות שמוגדרות בפרמטר --tasks. |
1 |
משתני סביבה למאגרי עובדים
Cloud Run מגדיר את משתני הסביבה הבאים למאגרי עובדים:
| שם | תיאור | דוגמה |
|---|---|---|
CLOUD_RUN_WORKER_POOL |
השם של מאגר העובדים הפעיל ב-Cloud Run. | hello-world |
CLOUD_RUN_REVISION |
השם של הגרסה של מאגר העובדים ב-Cloud Run שפועלת. | hello-world.1 |
דרישות לגבי כותרות של בקשות ותגובות (שירותים)
בשירותים, Cloud Run מגביל את שמות הכותרות ל-ASCII שאינו רווח לבן וניתן להדפסה, והם לא יכולים להכיל נקודתיים. ב-Cloud Run, ערכי הכותרת מוגבלים לתווי ASCII גלויים, בתוספת רווח וטאב אופקי, בהתאם ל-IETF RFC 7230.
גישה למערכת קבצים
מערכת הקבצים של כל מאגר ניתנת לכתיבה וכפופה להתנהגות הבאה:
- זו מערכת קבצים בזיכרון, ולכן כתיבה אליה משתמשת בזיכרון של המופע.
- הנתונים שנכתבים למערכת הקבצים לא נשמרים כשהמופע מפסיק לפעול.
אי אפשר לציין מגבלת גודל למערכת הקבצים הזו, ולכן יכול להיות שתשתמשו בכל הזיכרון שהוקצה למופע על ידי כתיבה למערכת הקבצים בזיכרון, מה שיגרום לקריסת המופע. כדי להימנע מהבעיה הזו, אפשר להשתמש בנפח אחסון ייעודי בזיכרון עם הגבלת גודל.
מחזור החיים של מופע
מאפייני מחזור החיים שונים עבור משימות ושירותים של Cloud Run, ולכן הם מתוארים בנפרד בקטעי המשנה הבאים.
לשירותים
המאפיינים הבאים חלים רק על שירותים.
הרחבת השירות
כברירת מחדל, שירות Cloud Run עובר התאמה אוטומטית לעומס למספר המכונות שנדרש כדי לטפל בכל הבקשות הנכנסות, האירועים או ניצול המעבד. אם אתם צריכים יותר שליטה על התנהגות ההתאמה לגודל, אתם יכולים להשתמש בהתאמה ידנית לגודל.
כל מופע מפעיל מספר קבוע של קונטיינרים – קונטיינר אחד של Ingress, ואופציונלית קונטיינר אחד או יותר של Sidecar.
אם אין תנועה לגרסה, המערכת מצמצמת את מספר המופעים שלה למספר המופעים המינימלי שהוגדר (אפס כברירת מחדל).
הפעלה
בשירותי Cloud Run, המופעים צריכים להאזין לבקשות תוך 4 דקות אחרי ההפעלה, וכל הקונטיינרים במופע צריכים להיות תקינים. במהלך זמן ההפעלה הזה, מוקצה למקרים שימוש CPU. אפשר להפעיל את האפשרות להגברת מהירות המעבד בזמן ההפעלה כדי להגדיל באופן זמני את הקצאת המעבד במהלך הפעלת המופע, וכך להקטין את זמן האחזור של ההפעלה.
הבקשות יישלחו למאגר הכניסה מיד אחרי שהוא יתחיל להאזין ליציאה שהוגדרה.
בקשה שממתינה למופע תישאר בהמתנה בתור באופן הבא:
הבקשות ימתינו עד פי 3.5 מזמן ההפעלה הממוצע של מופעי קונטיינר של השירות הזה, או עד 10 שניות, לפי הגבוה מביניהם.
אתם יכולים להגדיר בדיקת מוכנות להפעלה כדי לקבוע אם הקונטיינר הופעל ומוכן לטפל בבקשות.
בשירות Cloud Run שמורכב ממופעים של כמה קונטיינרים, אפשר להגדיר את סדר ההפעלה של הקונטיינרים כדי לציין את הרצף שבו הקונטיינרים מופעלים בתוך המופע.
עיבוד בקשה
בשירותי Cloud Run, מעבד (CPU) תמיד מוקצה לכל הקונטיינרים, כולל קונטיינרים מסוג sidecar בתוך מופע, כל עוד מתבצע עיבוד של בקשה אחת לפחות בגרסת Cloud Run.
לא פעיל/ה כבר כמה זמן
בשירותי Cloud Run, מופע במצב המתנה הוא מופע שלא מעבד בקשות.
השימוש במעבד שמוקצה לכל המאגדים במופע לא פעיל תלוי בהגדרות החיוב שהוגדרו.
אלא אם צריך להשאיר מופע במצב סרק בגלל הגדרת התצורה של מספר המופעים המינימלי, הוא לא יישאר במצב סרק יותר מ-15 דקות.
כיבוי
במקרה של שירותי Cloud Run, אפשר לסגור מכונה במצב המתנה בכל שלב, כולל מכונות שנשארות פעילות בגלל מספר מינימלי של מכונות שהוגדר. אם צריך להשבית מופע שמטפל בבקשות, הבקשות שכבר נמצאות בעיבוד מקבלות זמן להשלמה, ובקשות חדשות שמגיעות מנותבות למופעים אחרים. במקרים חריגים, יכול להיות ש-Cloud Run יתחיל כיבוי וישלח אות SIGTERM לקונטיינר שעדיין מעבד בקשות.
לפני כיבוי מופע, Cloud Run שולח אות SIGTERM לכל המאגרי מכולות במופע, שמציין את תחילת תקופה של 10 שניות לפני הכיבוי בפועל. בשלב הזה, Cloud Run שולח אות SIGKILL.
במהלך התקופה הזו, המעבד מוקצה למופע ומחויב.
בשירותים שמשתמשים בסביבת ההפעלה מהדור הראשון, אם המופע לא לוכד את האות SIGTERM, הוא מושבת באופן מיידי. בשירותים שמשתמשים בסביבת ההפעלה מהדור השני, מומלץ להתקין handler של SIGTERM בקונטיינר כדי לקבל אזהרה כש-Cloud Run עומד להשבית מופע.
סיום בכפייה
אם אחד או יותר מהקונטיינרים של Cloud Run חורגים ממגבלת הזיכרון הכוללת של הקונטיינר, המופע מסתיים. כל הבקשות שעדיין נמצאות בתהליך עיבוד במופע מסתיימות בשגיאה HTTP 500.
למשרות
במשימות של Cloud Run, מופעלים מופעי קונטיינר עד שהם יוצאים, עד שמגיעים לזמן הקצוב לתפוגה של המשימה או עד שהקונטיינר קורס.
קודי יציאה
אפשר להשתמש בקודי יציאה של משימות כדי לראות אם המשימה הושלמה בהצלחה או אם נתקלה בשגיאות כלשהן. קודי היציאה הם ערכים מספריים שממפים לסיום מוצלח או לסוגים ספציפיים של שגיאות.
בטבלה הבאה מפורטים קודי יציאה נפוצים וההגדרות שלהם:
| קוד יציאה | אות | תיאור |
|---|---|---|
| 0 | המשימה הושלמה בהצלחה. | |
| 4 | SIGILL |
הפעולה ניסתה לגשת לזיכרון בכתובת שגויה. |
| 7 | SIGBUS |
המשימה ניסתה לגשת לזיכרון מחוץ לגבולות שהוקצו לה. |
| 9 | SIGKILL |
המשימה מסתיימת בכוח, כתוצאה מפעולת משתמש או מהתערבות ידנית. |
| 11 | SIGSEGV |
המשימה ניסתה לגשת לזיכרון לא מורשה. |
| 15 | SIGTERM |
כשמשימה חורגת מהזמן הקצוב לתפוגה שהוגדר לה או אם המשימה מבוטלת, היא מקבלת אות SIGTERM. שרת האפליקציות שולח את האות SIGTERM למופע של מאגר התגים כדי להשבית אותו. אם המופע לא נסגר בעצמו תוך כמה שניות אחרי קבלת SIGTERM, Cloud Run שולח אות SIGKILL לסיום בכפייה. אם המופע יוצא בצורה תקינה עם SIGTERM, יכול להיות שיוחזר קוד שגיאה אחר. אחרת, יוחזר SIGTERM. |
סיום בכפייה
מופעלת הפסקה של מופע קונטיינר ב-Cloud Run שחורג ממגבלת הזיכרון המותרת. כל הבקשות שעדיין נמצאות בתהליך עיבוד במופע של מאגר התגים מסתיימות בשגיאה HTTP 500.
אם משימה חורגת מזמן קצוב לתפוגה של משימה, Cloud Run שולח אות SIGTERM שמציין את תחילת התקופה של 10 שניות לפני הכיבוי בפועל, ובשלב הזה Cloud Run שולח אות SIGKILL ומכבה את מופע הקונטיינר. פרטים והמלצות לטיפול בבעיה מפורטים במאמר בנושא כיבוי.
במהלך התקופה הזו, מוקצה למופעי מאגר CPU למשך כל מחזור החיים שלהם, והם מחויבים.
למאגרי עובדים
המאפיינים הבאים חלים רק על מאגרי עובדים.
התאמה להיקף
מאגרי עובדים לא משנים את הגודל שלהם באופן אוטומטי. מגדילים באופן ידני את מספר המופעים שנדרשים למאגר העובדים של Cloud Run כדי לטפל בעומס העבודה. כברירת מחדל, ב-Cloud Run מספר המכונות מוגדר ל-1. אפשר לשנות את המספר הזה למספר גבוה יותר או נמוך יותר, או להשבית את ההתאמה על ידי הגדרת המספר ל-0. כדי שהעומס יתחיל לפעול ויישאר פעיל, צריך להיות לו לפחות מופע אחד. אם מגדירים את מספר המופעים המינימלי ל-0, מופע העובד לא יופעל, גם אם הפריסה תצליח.
הפעלה
מופעים של מאגרי עובדים ב-Cloud Run מפעילים את הקונטיינר עם נקודת הכניסה שצוינה בקובץ האימג' של הקונטיינר או בתצורת מאגר העובדים. כל מאגרי התגים במופע צריכים להיות תקינים.
כברירת מחדל, מופעי קונטיינרים ב-Cloud Run משתמשים במעבד אחד. אתם יכולים להגדיל או להקטין את הערך הזה בהתאם לדרישות שלכם.
אתם יכולים להגדיר בקשה לבדיקת תקינות (probe) של הפעלה כדי לקבוע אם הקונטיינר הופעל. בדיקת ההפעלה מאפשרת ל-Cloud Run לבדוק את התקינות של קונטיינר תלוי, ולוודא שהוא עובר בהצלחה לפני הפעלת הקונטיינר הבא. אם לא משתמשים בבדיקות תקינות, Cloud Run מפעיל את הקונטיינרים בסדר שצוין, גם אם קונטיינרים שהם תלויים בהם לא מופעלים.
הקצאת משאבים
מאגרי עובדים לא נשארים במצב המתנה. בכל מקרה, Cloud Run תמיד מקצה CPU לכל הקונטיינרים, כולל קונטיינרים מסוג sidecar בתוך מופע של מאגר עובדים. כל עוד מופעלת דוגמה, היא נחשבת פעילה ומתבצע חיוב בהתאם.
כיבוי
Cloud Run לא מצמצם את מספר ה-instances במאגר העובדים על סמך instances לא פעילים. אם צריך להשבית מופע של עיבוד עומס עבודה, מערכת Cloud Run נותנת למשימות בתהליך זמן להשלמה ומנתבת עומסי עבודה חדשים למופעים אחרים. יכול להיות ש-Cloud Run יפעיל כיבוי וישלח אות SIGTERM לקונטיינר שעדיין מעבד עומס עבודה.
לפני השבתת מופע, Cloud Run שולח אות SIGTERM לכל הקונטיינרים במופע. האות הזה מציין את תחילת התקופה של 10 שניות לפני הכיבוי בפועל, ובמהלכה Cloud Run שולח אות SIGKILL.
במהלך תקופת ההשבתה הזו, המעבד המרכזי מוקצה למופע והחיוב מתבצע.
מומלץ להתקין SIGTERM handler בקונטיינר כדי לקבל אזהרה כש-Cloud Run עומד להשבית מופע.
סיום בכפייה
אם קונטיינר אחד או יותר ב-Cloud Run חורגים ממגבלת הזיכרון הכוללת של הקונטיינר, Cloud Run מפסיק את המופע. כל הבקשות שעדיין נמצאות בתהליך עיבוד במופע מסתיימות בשגיאה HTTP 500.
משאבים של מופע מכולה
הקונטיינר פועל תחת בקר cgroup שמגביל את השימוש במעבד, ב-RAM ובמשאבים אחרים לאלה שהוגדרו עבור הקונטיינר.
בקטעים הבאים מתוארים משאבים של מופע מארח:
CPU
כברירת מחדל, לכל קונטיינר של Cloud Run במופע מוקצה vCPU שהוגדר (1 כברירת מחדל). אפשר להגדיר מגבלות על השימוש במעבד לכל קונטיינר בנפרד.
vCPU מיושם כהפשטה של חומרה בסיסית כדי לספק את זמן המעבד המקביל המשוער של היפר-ת'רד יחיד בחומרה בפלטפורמות מעבד משתנות. כל פלטפורמות המעבד שמשמשות את Cloud Run תומכות בסט פקודות AVX2. שימו לב: החוזה של הקונטיינר לא כולל פרטים נוספים על פלטפורמת המעבד.
יכול להיות שהקונטיינר יופעל בכמה ליבות בו-זמנית.
במקרה של שירותי Cloud Run, הקצאת ה-CPU תלויה בחיוב שנבחר.
אם בוחרים בחיוב לפי מופע, המעבד מוקצה במהלך חיי המופע. אם בוחרים בחיוב על בסיס בקשות (ברירת מחדל), המעבד מוקצה כשמופעים מעבדים בקשות. פרטים נוספים זמינים במאמר בנושא הגדרות חיוב.
אם הגדרתם מספר של מופעים מינימליים, אתם צריכים להשתמש בחיוב לפי מופע כדי שהמעבד יוקצה מחוץ לבקשות.
אתם יכולים להפעיל את האפשרות להגברת מהירות המעבד בזמן ההפעלה כדי להגדיל באופן זמני את הקצאת המעבד במהלך הפעלת המופע, וכך להקטין את זמן האחזור של ההפעלה.
זיכרון
כברירת מחדל, לכל קונטיינר של Cloud Run מוקצה הזיכרון שהוגדר (512 MiB כברירת מחדל). אפשר להגדיר מגבלות זיכרון לכל מאגר בנפרד.
שימושים אופייניים בזיכרון כוללים:
- קוד שנטען לזיכרון כדי להריץ את השירות
- כתיבה למערכת הקבצים
- תהליכים נוספים שפועלים בקונטיינר, כמו שרת nginx
- מערכות העברה למטמון בזיכרון, כמו OpCache של PHP
- שימוש בזיכרון לכל בקשה
- נפחים משותפים בזיכרון
GPU
אפשר להגדיר קונטיינר במופע של Cloud Run כדי לגשת ל-GPU. אם שירות Cloud Run נפרס עם קונטיינרים מסוג sidecar, רק קונטיינר אחד בפריסה יכול לגשת ל-GPU. מידע נוסף על הדרישות מופיע במאמר בנושא הגדרת GPU.
ספריות NVIDIA
כברירת מחדל, כל ספריות הדרייברים של NVIDIA RTX PRO 6000 Blackwell GPU ו-NVIDIA L4 GPU מותקנות בתיקייה /usr/local/nvidia/lib64. Cloud Run מוסיף את הנתיב הזה באופן אוטומטי למשתנה הסביבה LD_LIBRARY_PATH (כלומר ${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64) של הקונטיינר עם ה-GPU. כך המקשר הדינמי יכול למצוא את ספריות מנהלי ההתקנים של NVIDIA. ה-linker מחפש ומזהה נתיבים לפי הסדר שמופיע במשתנה הסביבה LD_LIBRARY_PATH. לכל ערך שמציינים במשתנה הזה יש עדיפות על פני נתיב ברירת המחדל של ספריות מנהלי התקנים של Cloud Run /usr/local/nvidia/lib64.
אם רוצים להשתמש בגרסת CUDA שגבוהה מ-12.2, הדרך הכי קלה היא להסתמך על תמונת בסיס חדשה יותר של NVIDIA עם חבילות תאימות קדימה שכבר מותקנות. אפשרות נוספת היא להתקין ידנית את חבילות התאימות קדימה של NVIDIA ולהוסיף אותן ל-LD_LIBRARY_PATH. כדאי לעיין בטבלת התאימות של NVIDIA כדי לדעת אילו גרסאות של CUDA תואמות לגרסת מנהל ההתקן של NVIDIA שצוינה.
בו-זמניות (שירותים)
בשירותי Cloud Run, כל מופע של Cloud Run מוגדר כברירת מחדל למקביליות מרובה, שבה קונטיינר הכניסה יכול לקבל יותר מבקשה אחת בו-זמנית. אפשר לשנות את זה באמצעות הגדרת מקביליות.
הגבלות על אבטחת קונטיינרים
ההגבלות הבאות חלות על קונטיינרים שפועלים ב-Cloud Run. הן חלות ללא קשר למשתמש Linux שקובץ האימג' של הקונטיינר מציין להרצה.
הרשאות מופחתות
ב-Cloud Run, לקונטיינרים שלכם לא מוענקות יכולות הבסיס של גבול האבטחה של המופע. קונטיינרים לא יכולים לבצע פעולות ששמורות למארח, כמו הפעולות הבאות:
- הוספה או הסרה של יכולות של ליבת Linux
- שימוש ביכולות ספציפיות של ליבת המערכת
- שינוי מכשירים
- גישה למשאבי חומרה מסוימים
גם הסלמת הרשאות מושבתת במאגרי התגים. אין תמיכה בשימוש בקובצי הפעלה בינאריים של sudo ושל setuid ב-Cloud Run.
למאגרי התגים לא תהיה גישת כתיבה לרוב הקבצים והספריות ב-/dev, ב-/proc וב-/sys.
אין ב-Cloud Run מקבילה למצב --privileged של Docker.
בידוד קונטיינרים
Cloud Run מפעיל את הקונטיינרים שלכם במרחבי שמות של Linux כמו משתמש, רשת, PID ועוד, ומבודד אותם אחד מהשני ומהמכונה עצמה. ההגדרה הזו מגבילה חלק מהיכולות של הרשת ומונעת מהקונטיינרים שלכם לפעול כ-"true root".
הגבלות על טעינת מערכות קבצים מתוך קונטיינרים
הנתיב הנתמך לטעינת מערכות קבצים ב-Cloud Run הוא באמצעות התכונה לטעינת אמצעי אחסון מנוהלים באופן מלא בתצורת הקונטיינר של Cloud Run.
אין תמיכה במנגנונים אחרים להרכבה מתוך מאגרי משתמשים, והם לא יפעלו. מנגנונים לא נתמכים כוללים, בין היתר, את הדוגמאות הבאות:
- הפעלת תהליך הרכבה בתוך הקונטיינר כדי להרכיב כל אחת מהאפשרויות הבאות: NFS, Filestore, SMB/CIFS או כל מערכת קבצים אחרת ברשת.
- קריאה לקריאות מערכת שיבצעו פעולות שוות ערך.
בנוסף, Cloud Run לא תומך בהצמדות של נפחים מקוננים, כלומר הצמדה של נפח אחד בתוך נפח אחר.
לא יבוצעו שינויים בשעת המערכת
שינוי השעה במערכת באמצעות קריאות למערכת adjtimex ו-adjtime לא נתמך, וגם לא כלים שעשויים לאפשר לקונטיינר שלכם לעשות זאת.
הגבלות על תהליכים ועל קריאות למערכת
פרופילי אבטחה בסיסיים, בדומה לפרופילי אבטחה של seccomp ל-Docker, מוחלים על כל אחד מהקונטיינרים.
השימוש ב-eBPF ובתכונות אבטחה אחרות ברמת הליבה שלא מוגנות או מוגבלות על ידי מרחבי שמות של Linux מושבת ולא אפשרי לשימוש בתוך קונטיינרים.
יכול להיות שגם השימוש בקריאות אחרות למערכת או הגישה לקבצי מערכת שדורשים הרשאות root במופע Cloud Run יהיו מוגבלים בגלל הסיבה הזו.
ארגז חול של מכל
אם אתם משתמשים בסביבת ההפעלה מהדור הראשון, הקונטיינרים של Cloud Run מופעלים בארגז חול באמצעות gVisor, שהוא ארגז חול של זמן ריצה של קונטיינרים. כפי שמתואר בהפניה לתאימות של קריאות מערכת ב-gVisor, יכול להיות שארגז החול של הקונטיינר לא יתמוך בחלק מקריאות המערכת.
אם אתם משתמשים בסביבת הביצוע מהדור השני, יש לכם תאימות מלאה ל-Linux.
במשימות של Cloud Run תמיד משתמשים בסביבת ההפעלה מהדור השני.
בסביבת ההפעלה מהדור השני, הערך של /sys/class/dmi/id/product_name מוגדר ל-Google Compute Engine.
סביבת ההפעלה מהדור השני מריצה את קוד השירות במרחב שמות נפרד של תהליך, ולכן היא מתחילה כתהליך האתחול של הקונטיינר עם סמנטיקה מיוחדת של תהליך. בסביבת ההפעלה של הדור הראשון, קוד השירות לא מופעל כתהליך האתחול של הקונטיינר.
מגבלות על תיאורי קבצים
בסביבות של דור ראשון ודור שני ב-Cloud Run, יש מגבלה על מספר מתארי הקבצים שתהליך יכול לפתוח – עד 25,000. ההגדרה הזו חלה על מאגר התגים ועל כל תהליך צאצא שהוא יוצר (פיצולים). זוהי מגבלה קשיחה. אם תחרגו מהמגבלה, יכול להיות שייגמרו למופע שלכם מתארי קבצים או שקעים.
מגבלות בסביבה של הדור השני
מלבד מגבלות מתאר הקבצים שמתוארות בהמשך, המגבלות בסביבת הדור השני הן מגבלות לינוקס רגילות.
לדוגמה, המגבלות על מספר תיאורי הקבצים שאפשר לפתוח (כפי שמופיע ב: /proc/sys/fs/file-max) משתמשות בערך ברירת המחדל של כ-10% מהזיכרון. פרטים נוספים זמינים בfile-max ובfile-nr במסמכי התיעוד של ליבת המערכת.
באופן דומה, הערך של max_map_count (כפי שמופיע ב-/proc/sys/vm/max_map_count), שמגדיר את מספר אזורי הזיכרון שיכולים להיות לתהליך, הוא ברירת המחדל 65535. פרטים נוספים זמינים בmax-map-count במסמכי התיעוד של ליבת המערכת.
מאגרי תגים עם הרשאות מיוחדות וקבצים בינאריים מסוג setuid
Cloud Run לא תומך בקונטיינרים עם הרשאות. לכן, Cloud Run לא תומך בקבצים בינאריים שמשתמשים בדגלים setuid עבור משתמשים שאינם משתמשי root, כמו gcsfuse או sudo, ויכול להיות שהפעולה תיכשל בגלל הרשאות לא מספיקות.
אפשרות חלופית היא להריץ את הקבצים הבינאריים האלה כמשתמש root ואז להשתמש בפקודה su כדי לעבור למשתמש אחר בזמן הריצה.
לדוגמה, בקובץ Dockerfile, מסירים את ההוראה USER, ובסקריפט של נקודת הכניסה משתמשים ברצף הבא:
gcsfuse ... # Run gcsfuse as root
su myuser -c "/yourapp.sh" # Switch to 'myuser' and run 'yourapp.sh'
המשתמש שמבצע את הפעולה
אם שם המשתמש לא קיים, Cloud Run מריץ את הקונטיינר כמשתמש Root (uid=0).
תקשורת בין מאגרים של אותו מופע
Cloud Run מוסיף רשומה לקובץ /etc/hosts בכל קונטיינר. הערך הזה ממפה את שמות השירותים לכתובת ה-IP של המארח המקומי (127.0.0.1). כך הקונטיינרים יכולים לתקשר ביניהם באמצעות שם הקונטיינר שלהם.
שרת מטא-נתונים של מופע
במופעים של Cloud Run יש שרת מטא-נתונים שאפשר להשתמש בו כדי לאחזר פרטים על הקונטיינרים, כמו מזהה הפרויקט, האזור, מזהה המופע או חשבונות השירות. אפשר גם להשתמש בשרת המטא-נתונים כדי ליצור אסימונים לזהות בשירות.
כדי לגשת לנתונים של שרת המטא-נתונים, משתמשים בבקשות HTTP לנקודת הקצה http://metadata.google.internal/ עם הכותרת Metadata-Flavor: Google. לא נדרשות ספריות לקוח. מידע נוסף זמין במאמר קבלת מטא-נתונים.
בטבלה הבאה מפורטים חלק מהפרטים של שרת המטא-נתונים שזמינים:
| נתיב | תיאור |
|---|---|
/computeMetadata/v1/project/project-id |
מזהה הפרויקט שאליו משתייך משאב Cloud Run. |
/computeMetadata/v1/project/numeric-project-id |
מספר הפרויקט שאליו משויך משאב Cloud Run. |
/computeMetadata/v1/instance/region |
האזור של משאב Cloud Run הזה, מחזיר projects/PROJECT-NUMBER/regions/REGION |
/computeMetadata/v1/instance/id |
מזהה ייחודי של המופע (זמין גם ביומנים). |
/computeMetadata/v1/instance/service-accounts/default/email |
כתובת האימייל של זהות השירות של משאב Cloud Run הזה. |
/computeMetadata/v1/instance/service-accounts/default/token |
יוצר אסימון גישה מסוג OAuth2 בשביל חשבון השירות של משאב Cloud Run הזה. סוכן השירות של Cloud Run משמש לאחזור אסימון. נקודת הקצה הזו תחזיר תגובת JSON עם מאפיין access_token. מידע נוסף על חילוץ טוקן הגישה ושימוש בו |
/computeMetadata/v1/instance/network-interfaces/0/ip |
כתובת IPv4 של מכונה במאגר עובדים ברשת VPC. |
/computeMetadata/v1/instance/network-interfaces/0/ipv6 |
כתובת ה-IPv6 של מופע של מאגר עובדים. חשוב לוודא שיוצרים את המופע בתת-רשת עם כתובות IPv4 ו-IPv6. |
/computeMetadata/v1/instance/network-interfaces/ /computeMetadata/v1/instance/network-interfaces/0/ |
נתיב ספריית ממשק הרשת למאגרי עובדים. |
ב-Cloud Run לא מוצגים פרטים על Google Cloud האזור שבו המופעים פועלים. כתוצאה מכך, מאפיין המטא-נתונים /computeMetadata/v1/instance/zone
תמיד מחזיר projects/PROJECT-NUMBER/zones/REGION-1.
שמות הקבצים
שמות הקבצים שבהם אתם משתמשים במאגרי מידע צריכים להיות תואמים ל-UTF-8, כלומר בקידוד UTF-8 או בקידוד שאפשר להמיר באופן אוטומטי ל-UTF-8 בלי בעיות. אם שמות הקבצים משתמשים בקידודים שונים, צריך להריץ את Docker build במחשב עם שמות קבצים שתואמים ל-UTF-8, ולהימנע מהעתקת קבצים למאגר שמכיל שמות לא תואמים ל-UTF-8.
פריסת הקונטיינר נכשלת אם שמות הקבצים לא תואמים ל-UTF-8. שימו לב שאין הגבלה על קידוד התווים שבו אתם משתמשים בקובץ.
הזמן הקצוב לתפוגה של בקשות יוצאות
בשירותים ובעבודות של Cloud Run, יש פסק זמן אחרי 10 דקות של חוסר פעילות בבקשות מהקונטיינר אל VPC. בבקשות מהקונטיינר לאינטרנט, יש פסק זמן אחרי 20 דקות של חוסר פעילות.
איפוסים של חיבורים יוצאים
הזרמת החיבורים מהקונטיינר אל VPC והאינטרנט עשויה להיפסק מדי פעם ולהתחלף כשהתשתית הבסיסית מופעלת מחדש או מתעדכנת. אם האפליקציה שלכם משתמשת מחדש בחיבורים לטווח ארוך, מומלץ להגדיר אותה כך שתבצע חיבורים מחדש כדי למנוע שימוש חוזר בחיבור לא פעיל.