בדף הזה מפורטות הדרישות העיקריות של קונטיינרים ב-Cloud Run וההתנהגויות שלהם. בנוסף, בדף מוסבר על ההבדלים בין שירותי Cloud Run, משימות Cloud Run ומאגרי עובדים של Cloud Run, במקומות שבהם זה רלוונטי.
שפות ותמונות נתמכות
קובץ האימג' של הקונטיינר יכול להריץ קוד שנכתב בשפת התכנות שתבחרו ולהשתמש בכל קובץ אימג' בסיסי, בתנאי שהוא עומד בדרישות שמפורטות בדף הזה.
קובצי ההפעלה בקובץ אימג' של קונטיינר חייבים להיות מהודרים ל-Linux 64-bit. ב-Cloud Run יש תמיכה ספציפית בפורמט Linux x86_64 ABI.
Cloud Run מקבל קובצי אימג' של קונטיינרים בפורמטים של קובץ מניפסט של Docker Image 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 ביציאה שאליה נשלחות הבקשות.
חשוב לציין שקונטיינר הכניסה לא צריך להאזין ב-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 עם תעבורת נכנסת ישירה של VPC, כמו חיבורי מסד נתונים או כל פרוטוקול מותאם אישית אחר שמבוסס על TCP, הקונטיינר צריך להאזין לחיבורי TCP ביציאה שנחשפת בקובץ האימג' של הקונטיינר דרך קובץ ה-Dockerfile או שצוינה על ידי משתנה הסביבה 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 גלויים, בתוספת רווח ותו Tab אופקי, בהתאם ל-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, הוא מושבת באופן מיידי. בשירותים שמשתמשים בסביבת ההפעלה מהדור השני, מומלץ להתקין SIGTERM handler במאגר כדי לקבל אזהרה כש-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.
אם משימה חורגת מזמן ההמתנה (timeout) של המשימה, Cloud Run שולח אות SIGTERM שמציין את תחילת תקופה של 10 שניות לפני הכיבוי בפועל. בשלב הזה, Cloud Run שולח אות SIGKILL ומכבה את מופע הקונטיינר. פרטים והמלצות לטיפול בבעיה מפורטים במאמר בנושא כיבוי.
במהלך התקופה הזו, מוקצה למופעי מאגר יחידת עיבוד מרכזית (CPU) למשך כל מחזור החיים שלהם, והם מחויבים.
למאגרי עובדים
המאפיינים הבאים חלים רק על מאגרי עובדים.
התאמה לעומס (scaling)
מאגרי עובדים לא משנים את הגודל שלהם באופן אוטומטי. מגדילים באופן ידני את מספר המופעים שנדרשים למאגר העובדים של Cloud Run כדי לטפל בעומס העבודה. כברירת מחדל, Cloud Run מגדיר את מספר המכונות ל-1. אפשר לשנות את המספר הזה למספר גבוה יותר או נמוך יותר, או להשבית את ההתאמה על ידי הגדרת המספר ל-0. כדי שהעומס יתחיל לפעול ויישאר פעיל, צריך להיות לו לפחות מופע אחד. אם מגדירים את מספר המופעים המינימלי ל-0, מופע העובד לא יופעל, גם אם הפריסה תצליח.
הפעלה
מופעים של מאגרי עובדים ב-Cloud Run מפעילים את הקונטיינר עם נקודת הכניסה שצוינה בקובץ האימג' של הקונטיינר או בתצורת מאגר העובדים. כל מאגרי התגים במופע צריכים להיות תקינים.
כברירת מחדל, מופעי קונטיינרים ב-Cloud Run משתמשים במעבד אחד. אתם יכולים להגדיל או להקטין את הערך הזה בהתאם לדרישות שלכם.
אתם יכולים להגדיר בדיקת מוכנות כדי לקבוע אם הקונטיינר הופעל. בדיקת ההפעלה מאפשרת ל-Cloud Run לבדוק את התקינות של קונטיינר תלוי, ולוודא שהוא עובר בהצלחה לפני הפעלת הקונטיינר הבא. אם לא משתמשים בבדיקות תקינות, Cloud Run מפעיל את הקונטיינרים בסדר שצוין, גם אם קונטיינרים שהם תלויים בהם לא מופעלים.
הקצאת משאבים
מאגרי עובדים לא נשארים במצב המתנה. בכל מקרה, Cloud Run תמיד מקצה CPU לכל הקונטיינרים, כולל קונטיינרים מסוג sidecar בתוך מופע של מאגר עובדים. כל עוד מופעלת אינטסנס, היא נחשבת פעילה והחיוב מתבצע בהתאם.
כיבוי
ב-Cloud Run, לא מתבצעת הקטנה של מספר ה-worker pool 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 כברירת מחדל). אפשר להגדיר מגבלות על השימוש במעבד לכל קונטיינר בנפרד.
ליבת CPU וירטואלית מיושמת כהפשטה של חומרה בסיסית כדי לספק את זמן ה-CPU המקביל המשוער של היפר-ת'רד יחיד בחומרה בפלטפורמות CPU משתנות. כל פלטפורמות המעבד שמשמשות את 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 שגבוהה מ-13.0, הדרך הכי קלה היא להסתמך על תמונת בסיס חדשה יותר של 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 ועוד, ומבודד אותם אחד מהשני ומהמכונה עצמה. ההגדרה הזו מגבילה חלק מהיכולות של הרשת ומונעת מהקונטיינרים הבסיסיים לפעול כ'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 למשתמשים שאינם משתמשי-על, כמו 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 והאינטרנט עשויה להיפסק מדי פעם ולהתחלף כשהתשתית הבסיסית מופעלת מחדש או מתעדכנת. אם האפליקציה שלכם משתמשת מחדש בחיבורים לטווח ארוך, מומלץ להגדיר אותה כך שתבצע חיבורים מחדש כדי למנוע שימוש חוזר בחיבור לא פעיל.