בדף הזה מפורטות הדרישות העיקריות של קונטיינרים ב-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 יש תמיד קונטיינר Ingress יחיד שמקשיב לבקשות, ואפשרות לקונטיינר משני (sidecar) אחד או יותר. פרטי ההגדרה הבאים של הניוד רלוונטיים רק למאגר ingress, ולא למאגרי sidecar.
קונטיינר הכניסה בתוך מופע צריך להאזין לבקשות בכתובת 0.0.0.0 ביציאה שאליה נשלחות הבקשות.
חשוב לציין שהקונטיינר של ה-ingress לא צריך להאזין ב-127.0.0.1.
כברירת מחדל, הבקשות נשלחות אל 8080, אבל אפשר להגדיר את Cloud Run כך שהבקשות יישלחו אל היציאה שתבחרו. Cloud Run מוסיף את משתנה הסביבה PORT לקונטיינר של ה-ingress.
קישוריות לרשת VPC
שירותים ומשימות ב-Cloud Run תומכים ביציאה ישירה מ-VPC. כלומר, הם יכולים לשלוח תעבורה למשאבים פרטיים ברשת ה-VPC שהגדרתם, כמו מסדי נתונים או שירותים פנימיים. שירותים ומשימות ב-Cloud Run לא תומכים בתעבורה נכנסת ישירה של VPC.
מאגרי עובדים ב-Cloud Run תומכים גם בתעבורת נתונים יוצאת (egress) ישירה מ-VPC וגם בתעבורת נתונים נכנסת (ingress) ישירה ל-VPC. כשמגדירים Direct VPC לפריסת מאגר העובדים של Cloud Run, כל מופע של עובד מקבל כתובת IP פרטית ברשת ובתת-הרשת שהוגדרו. רק משאבים מרשת ה-VPC יכולים להתחבר לנקודת הקצה של כתובת ה-IP הפרטית של מאגר העובדים. למידע נוסף על השגת כתובות ה-IP הפרטיות של מופע מאגר העובדים, אפשר לעיין במאמר אחזור כתובות ה-IP הפרטיות באמצעות שרת המטא-נתונים (MDS).
במאגרי עובדים של Cloud Run עם תעבורת נתונים נכנסת ישירה של 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_WORKER_POOL_REVISION |
השם של הגרסה של מאגר העובדים הפעיל ב-Cloud Run. | hello-world.1 |
דרישות לגבי כותרות של בקשות ותגובות (שירותים)
בשירותים, Cloud Run מגביל את שמות הכותרות ל-ASCII שאינו רווח לבן וניתן להדפסה, והם לא יכולים להכיל נקודתיים. ב-Cloud Run, ערכי הכותרת מוגבלים לתווי ASCII גלויים, בתוספת רווח וטאב אופקי, בהתאם ל-IETF RFC 7230.
גישה למערכת קבצים
מערכת הקבצים של כל מאגר ניתנת לכתיבה וכפופה להתנהגות הבאה:
- זו מערכת קבצים בזיכרון, ולכן כתיבה אליה משתמשת בזיכרון של המופע.
- הנתונים שנכתבים למערכת הקבצים לא נשמרים כשהמופע מפסיק לפעול.
אי אפשר לציין מגבלת גודל למערכת הקבצים הזו, ולכן יכול להיות שתשתמשו בכל הזיכרון שהוקצה למופע על ידי כתיבה למערכת הקבצים בזיכרון, מה שיגרום לקריסת המופע. כדי להימנע מהבעיה הזו, אפשר להשתמש בנפח אחסון ייעודי בזיכרון עם הגבלת גודל.
מחזור החיים של מופע
מאפייני מחזור החיים שונים עבור משימות ושירותים של Cloud Run, ולכן הם מתוארים בנפרד בקטעי המשנה הבאים.
לשירותים
המאפיינים הבאים חלים רק על שירותים.
התאמת השירות
כברירת מחדל, שירות Cloud Run עובר התאמה אוטומטית לעומס למספר המכונות שנדרש כדי לטפל בכל הבקשות הנכנסות, האירועים או ניצול המעבד. אם אתם צריכים יותר שליטה על התנהגות ההתאמה לגודל, אתם יכולים להשתמש בשינוי גודל ידני.
כל מופע מפעיל מספר קבוע של קונטיינרים – קונטיינר אחד של Ingress, ואפשרות לקונטיינר Sidecar אחד או יותר.
אם אין תנועה לגרסה, המערכת מצמצמת את מספר המופעים שלה למספר המופעים המינימלי שהוגדר (אפס כברירת מחדל).
הפעלה
בשירותי Cloud Run, המופעים צריכים להאזין לבקשות תוך 4 דקות אחרי ההפעלה, וכל הקונטיינרים במופע צריכים להיות תקינים. במהלך זמן ההפעלה הזה, מוקצה למכונות הווירטואליות מעבד. אפשר להפעיל את האפשרות להגברת מהירות המעבד בזמן ההפעלה כדי להגדיל באופן זמני את הקצאת המעבד במהלך הפעלת המופע, וכך להקטין את זמן האחזור של ההפעלה.
הבקשות יישלחו למאגר ה-Ingress מיד אחרי שהוא יתחיל להאזין ליציאה שהוגדרה.
בקשה שממתינה למופע תישאר בהמתנה בתור באופן הבא:
הבקשות ימתינו עד פי 3.5 מזמן ההפעלה הממוצע של מופעי קונטיינר של השירות הזה, או עד 10 שניות, לפי הגבוה מביניהם.
אתם יכולים להגדיר בקשה לבדיקת תקינות (probe) להפעלה כדי לקבוע אם הקונטיינר הופעל ומוכן לטפל בבקשות.
בשירות 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.
אם משימה חורגת מזמן הקצוב לתפוגה של המשימה, Cloud Run שולח אות SIGTERM שמציין את תחילת התקופה של 10 שניות לפני הכיבוי בפועל. בשלב הזה, Cloud Run שולח אות SIGKILL ומכבה את מופע הקונטיינר.
במהלך התקופה הזו, מוקצה למופעי מאגר CPU למשך כל מחזור החיים שלהם, והם מחויבים.
דוגמת הקוד SIGTERM מראה איך ללכוד את האות SIGTERM.
למאגרי עובדים
המאפיינים הבאים חלים רק על מאגרי עובדים.
התאמה להיקף
ההגדלה של מאגרי העובדים לא מתבצעת באופן אוטומטי. מגדילים באופן ידני את מספר המופעים שנדרשים למאגר העובדים של Cloud Run כדי לטפל בעומס העבודה. כברירת מחדל, ב-Cloud Run מספר המכונות מוגדר ל-1. אפשר לשנות את המספר הזה למספר גבוה יותר או נמוך יותר, או להשבית את ההתאמה על ידי הגדרת המספר ל-0. כדי שהעומס יתחיל לפעול ויימשך, צריך להיות לו לפחות מופע אחד. אם מגדירים את מספר המופעים המינימלי ל-0, מופע העובד לא יופעל, גם אם הפריסה תצליח.
הפעלה
מופעים של מאגרי עובדים ב-Cloud Run מתחילים את הקונטיינר עם נקודת הכניסה שצוינה בקובץ האימג' של הקונטיינר או בתצורת מאגר העובדים. כל מאגרי התגים במופע צריכים להיות תקינים.
כברירת מחדל, מופעי קונטיינרים ב-Cloud Run משתמשים במעבד אחד. אתם יכולים להגדיל או להקטין את הערך הזה בהתאם לדרישות שלכם.
אתם יכולים להגדיר בקשה לבדיקת תקינות (probe) להפעלה כדי לקבוע אם הקונטיינר הופעל. בקשה לבדיקת תקינות (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 כברירת מחדל). אפשר להגדיר מגבלות CPU לכל קונטיינר בנפרד.
ליבת CPU וירטואלית מיושמת כהפשטה של חומרה בסיסית כדי לספק את זמן ה-CPU המקביל המשוער של הליכי משנה היפר-וירטואליים של חומרה יחידה בפלטפורמות CPU משתנות. כל פלטפורמות המעבד שמשמשות את Cloud Run תומכות בסט פקודות AVX2. שימו לב שהחוזה של הקונטיינר לא כולל פרטים נוספים על פלטפורמת ה-CPU.
יכול להיות שהקונטיינר יופעל בכמה ליבות בו-זמנית.
בשירותי Cloud Run, הקצאת ה-CPU תלויה בחיוב שנבחר.
אם בוחרים בחיוב לפי מופע, המעבד מוקצה במהלך חיי המופע. אם בוחרים בחיוב לפי בקשה (ברירת מחדל), המעבד מוקצה כשמופעלות בקשות עיבוד של מופעים. פרטים נוספים זמינים במאמר בנושא הגדרות חיוב.
אם הגדרתם מספר של מופעים מינימליים, אתם צריכים להשתמש בחיוב לפי מופע כדי שהמעבד יוקצה מחוץ לבקשות.
אתם יכולים להפעיל את האפשרות להגברת מהירות המעבד בזמן ההפעלה כדי להגדיל באופן זמני את הקצאת המעבד במהלך הפעלת המופע, וכך להקטין את זמן האחזור של ההפעלה.
זיכרון
כברירת מחדל, לכל קונטיינר של Cloud Run מוקצה הזיכרון שהוגדר (512 MiB כברירת מחדל). אפשר להגדיר מגבלות זיכרון לכל מאגר בנפרד.
שימושים אופייניים בזיכרון כוללים:
- קוד שנטען לזיכרון כדי להפעיל את השירות
- כתיבה למערכת הקבצים
- תהליכים נוספים שפועלים בקונטיינר, כמו שרת nginx
- מערכות העברה למטמון בזיכרון, כמו OpCache של PHP
- שימוש בזיכרון לכל בקשה
- כרכים משותפים בזיכרון
GPU
אפשר להגדיר קונטיינר במופע של Cloud Run כדי לגשת ל-GPU. אם שירות Cloud Run נפרס עם קונטיינרים מסוג sidecar, רק קונטיינר אחד בפריסה יכול לגשת ל-GPU. מידע נוסף על הדרישות מופיע במאמר בנושא הגדרת GPU.
ספריות NVIDIA
כברירת מחדל, כל ספריות הדרייברים של NVIDIA L4 ו-NVIDIA RTX PRO 6000 Blackwell 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 מוגדר כברירת מחדל לבו-זמניות (concurrency) מרובה, שבה קונטיינר הכניסה יכול לקבל יותר מבקשה אחת בו-זמנית. אפשר לשנות את זה באמצעות הגדרת מקביליות.
הגבלות על אבטחת קונטיינרים
ההגבלות הבאות חלות על קונטיינרים שפועלים ב-Cloud Run. הן חלות ללא קשר למשתמש Linux שקובץ האימג' של הקונטיינר מציין להרצה.
הרשאות מופחתות
ב-Cloud Run, לקונטיינרים שלכם לא מוענקות יכולות הבסיס של גבול האבטחה של המופע. מאגרי תגים לא יכולים לבצע פעולות ששמורות למארח, כמו הפעולות הבאות:
- הוספה או הסרה של יכולות של ליבת Linux
- שימוש ביכולות ספציפיות של ליבת המערכת
- שינוי מכשירים
- גישה למשאבי חומרה מסוימים
גם הסלמת הרשאות מושבתת במאגרי התגים. אין תמיכה בשימוש בקובצי הפעלה בינאריים של sudo ושל setuid ב-Cloud Run.
למאגרי התגים לא תהיה הרשאת כתיבה לרוב הקבצים והספריות ב-/dev, /proc ו-/sys.
אין ב-Cloud Run מקבילה למצב --privileged של Docker.
בידוד קונטיינרים
Cloud Run מפעיל את הקונטיינרים שלכם במרחבי שמות של משתמשים, רשתות, PID ו-Linux אחרים, ומבודד אותם זה מזה ומהמופע עצמו. ההגדרה הזו מגבילה חלק מהיכולות של הרשת ומונעת מהקונטיינרים שלכם ברמת הבסיס לפעול כ'שורש אמיתי'.
הגבלות על טעינת מערכות קבצים מתוך קונטיינרים
הנתיב הנתמך לטעינת מערכות קבצים ב-Cloud Run הוא באמצעות התכונה לטעינת אמצעי אחסון מנוהלים במלואם בתצורת הקונטיינר של Cloud Run.
אין תמיכה במנגנונים אחרים של הרכבה מתוך מאגרי משתמשים, והם לא יפעלו. מנגנונים לא נתמכים כוללים, בין היתר, את הדוגמאות הבאות:
- הפעלת תהליך הרכבה בתוך הקונטיינר כדי להרכיב את אחד מהפריטים הבאים: NFS, Filestore, SMB/CIFS או כל מערכת קבצים אחרת ברשת.
- הפעלת קריאות למערכת שיבצעו פעולות מקבילות.
בנוסף, Cloud Run לא תומך בהעלאות של נפחים מוטמעים, שבהן נפח אחד מוטמע בתוך נפח אחר.
לא בוצעו שינויים בשעת המערכת
שינוי השעה במערכת באמצעות קריאות למערכת adjtimex ו-adjtime לא נתמך, וגם לא כלים שעשויים לאפשר לכם לעשות זאת ב-container.
הגבלות על תהליכים ועל קריאות למערכת
פרופילי אבטחה בסיסיים, בדומה לפרופילי אבטחה של 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 של מופע במאגר עובדים. חשוב לוודא שיוצרים את המופע בתת-רשת עם פרוטוקול כפול. |
/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 והאינטרנט יופסקו מדי פעם ויוחלפו אם התשתית הבסיסית תופעל מחדש או תעודכן. אם האפליקציה שלכם עושה שימוש חוזר בחיבורים לטווח ארוך, מומלץ להגדיר אותה כך שתבצע חיבורים מחדש כדי למנוע שימוש חוזר בחיבור לא פעיל.