חוזה זמן ריצה של קונטיינר

בדף הזה מפורטות הדרישות העיקריות וההתנהגויות של קונטיינרים ב-Cloud Run. בנוסף, בדף הזה מוסברים ההבדלים בין שירותי Cloud Run, משימות Cloud Run ומאגרי Worker ב-Cloud Run, במקומות הרלוונטיים.

שפות ותמונות נתמכות

קובץ האימג' של הקונטיינר יכול להריץ קוד שנכתב בשפת התכנות שבחרתם, ולהשתמש בכל קובץ אימג' בסיסי, בתנאי שהוא עומד במגבלות שמפורטות בדף הזה.

קבצי ההפעלה בקובץ האימג' של הקונטיינר צריכים להיות מקומפלים ל-Linux בגרסת 64 ביט. ‫Cloud Run תומך באופן ספציפי בפורמט Linux x86_64 ABI.

ב-Cloud Run אפשר להשתמש בקובצי אימג' של קונטיינרים בפורמטים של קובצי אימג' של Docker Image Manifest V2,‏ Schema 1,‏ Schema 2 ו-OCI. ב-Cloud Run אפשר להשתמש גם בקובצי אימג' של קונטיינרים שדחוסים ב-Zstd.

אם פורסים תמונה עם כמה ארכיטקטורות, רשימת המניפסט חייבת לכלול את linux/amd64.

דרישות לגבי כלי הקיבול

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

הקונטיינר שנפרס לשירותים צריך להאזין לבקשות ביציאה הנכונה

שירות Cloud Run מפעיל מכונות של Cloud Run כדי לטפל בבקשות נכנסות. למכונה של Cloud Run תמיד יש קונטיינר Ingress אחד שמאזין לבקשות, ואופציונלית קונטיינר משני (sidecar) אחד או יותר. פרטי הגדרת היציאה הבאים רלוונטיים רק למאגר ה-ingress, ולא ל-sidecars.

קונטיינר ה-ingress במכונה צריך להאזין לבקשות ב-0.0.0.0 ביציאה שאליה נשלחות הבקשות. חשוב לציין שמאגר ה-ingress לא צריך להאזין ל-127.0.0.1. כברירת מחדל, הבקשות נשלחות אל 8080, אבל אפשר להגדיר את Cloud Run כך שישלח בקשות ליציאה לבחירתכם. ‫Cloud Run מוסיף את משתנה הסביבה PORT לקונטיינר של תעבורת הנתונים הנכנסת.

קישוריות לרשת VPC

ב-Cloud Run אפשר להתחבר לרשת VPC באמצעות Direct VPC.

• כדי לשלוח תעבורת נתונים למשאבים פרטיים ברשת ה-VPC שהגדרתם, כמו מסדי נתונים או שירותים פנימיים, אתם יכולים להשתמש בDirect VPC egress.
• כדי לקבל תנועה ממשאבים פרטיים או מכתובות IP ברשת ה-VPC או ברשת המשנה שהוגדרו, משתמשים ב-Direct VPC ingress.

כל משאב של Cloud Run תומך בהגדרות הבאות של Direct VPC:

• שירותים: תעבורת נתונים יוצאת (egress) בלבד
• משימות: תעבורת נתונים יוצאת בלבד

כשמשתמשים ב-Direct VPC, כתובות ה-IP האלה לא סטטיות.

קונטיינר שפועל בהרצת משימה חייב להיסגר בסיום

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

מכיוון שמשימות לא אמורות לשרת בקשות, הקונטיינר לא אמור להאזין ליציאה או להפעיל שרת אינטרנט.

הצפנה של שכבת התעבורה (TLS)

הקונטיינר לא אמור להטמיע אבטחת שכבת תעבורה (TLS) באופן ישיר. ‫Cloud Run מסיים את ה-TLS ל-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 נוסף רק למאגר התגים של Ingress:

משתני סביבה למשימות

במשימות של Cloud Run, מוגדרים משתני הסביבה הבאים:

דרישות לגבי כותרות של בקשות ותגובות (שירותים)

בשירותים, Cloud Run מגביל את שמות הכותרות לתווי ASCII שניתנים להדפסה, ללא רווחים לבנים וללא נקודתיים. ב-Cloud Run, ערכי הכותרות מוגבלים לתווי ASCII גלויים, כולל רווח וטאב אופקי, בהתאם ל-IETF RFC 7230.

גישה למערכת הקבצים

אפשר לכתוב במערכת הקבצים של כל קונטיינר, והיא כפופה להתנהגות הבאה:

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

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

מחזור החיים של המכונה

מאפייני מחזור החיים של משימות ושירותים ב-Cloud Run שונים, ולכן הם מתוארים בנפרד בסעיפי המשנה הבאים.

לשירותים

המאפיינים הבאים רלוונטיים רק לשירותים.

שינוי קנה המידה של השירות

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

בכל מכונה פועל מספר קבוע של קונטיינרים – קונטיינר Ingress אחד, ואופציונלית קונטיינר משני (sidecar) אחד או יותר.

כשגרסה לא מקבלת תנועה, היא מוקטנת למספר המופעים המינימלי שהוגדר (אפס כברירת מחדל).

הפעלה

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

הבקשות יישלחו לקונטיינר ה-ingress ברגע שהוא יאזין ליציאה שהוגדרה.

בקשה שממתינה למכונה תישאר בהמתנה בתור באופן הבא:

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

אפשר להגדיר בדיקת הפעלה כדי לקבוע אם הקונטיינר הופעל ומוכן לטפל בבקשות.

בשירות Cloud Run שמורכב ממכונות עם כמה קונטיינרים, אתם יכולים להגדיר את סדר ההפעלה של הקונטיינרים כדי לקבוע את הרצף שבו הקונטיינרים יופעלו בתוך המכונה.

עיבוד בקשה

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

לא פעיל/ה כבר כמה זמן

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

המעבד (CPU) שמוקצה לכל הקונטיינרים במכונה במצב חוסר פעילות תלוי בהגדרות החיוב שנקבעו.

אלא אם צריך להשאיר מכונה במצב של חוסר פעילות בגלל הגדרת התצורה של מספר המכונות המינימלי, היא לא תישאר במצב של חוסר פעילות למשך יותר מ-15 דקות.

כיבוי

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

לפני השבתת מכונה, Cloud Run שולח אות SIGTERM לכל הקונטיינרים במכונה, שמציין את תחילתה של תקופה של 10 שניות לפני שההשבתה בפועל מתרחשת, ובשלב הזה Cloud Run שולח אות SIGKILL. במהלך התקופה הזו, המכונה מקבלת הקצאה של מעבד (CPU) ומחויבת. בשירותים שמשתמשים בסביבת זמן הריצה מהדור הראשון, אם המכונה לא לוכדת את האות SIGTERM, היא מושבתת באופן מיידי. בשירותים שמשתמשים בסביבת זמן הריצה מהדור השני, מומלץ להתקין handler של SIGTERM בקונטיינר כדי לקבל אזהרה כש-Cloud Run עומד להשבית מכונה.

סגירה מאולצת

אם מארז אחד או יותר של Cloud Run חורג ממגבלת הזיכרון הכוללת של המארז, המכונה מסתיימת. כל הבקשות שעדיין מעובדות במכונה מסתיימות בשגיאה HTTP 500.

למשימות

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

קודי יציאה

אפשר להשתמש בקודי היציאה של המשימה כדי לבדוק אם המשימה הושלמה בהצלחה או אם היו שגיאות. קודי היציאה הם ערכים מספריים שממופים להשלמה מוצלחת או לסוגים ספציפיים של שגיאות.

בטבלה הבאה מפורטים קודי יציאה נפוצים וההגדרות שלהם:

סגירה מאולצת

מופע קונטיינר של Cloud Run שחורג ממגבלת הזיכרון המותרת מסתיים. כל הבקשות שעדיין מעובדות במכונה של מאגר הנתונים מסתיימות בשגיאה HTTP 500.

אם משימה חורגת מזמן הקצוב לתפוגה, Cloud Run שולח אות SIGTERM שמציין את תחילת התקופה של 10 שניות לפני שהכיבוי בפועל מתרחש. בשלב הזה Cloud Run שולח אות SIGKILL, שמכבה את המכונה של מאגר הנתונים. בקטע השבתה מפורטים פרטים והמלצות לטיפול במצב כזה.

במהלך התקופה הזו, מוקצה למכונות של מאגר הנתונים מעבד (CPU) לכל מחזור החיים שלהן, והן מחויבות.

משאבים של מכונות קונטיינרים

הקונטיינר פועל תחת בקר cgroup שמגביל את המעבד (CPU), ה-RAM ומשאבים אחרים לאלה שהוגדרו לקונטיינר.

בקטעים הבאים מתוארים המשאבים של מכונת הקונטיינר:

• מעבד (CPU)
• זיכרון
• בו-זמניות (concurrency)

CPU

כברירת מחדל, לכל קונטיינר של Cloud Run במכונה מוקצה vCPU שהוגדר (1 כברירת מחדל). אפשר להגדיר מגבלות מעבד (CPU) לכל קונטיינר בנפרד.

‫vCPU מיושם כהפשטה של החומרה הבסיסית, כדי לספק זמן CPU שווה ערך בקירוב ל-hyper-thread של חומרה אחת בפלטפורמות CPU משתנות. כל פלטפורמות המעבדים שמשמשות את Cloud Run תומכות בסט הפקודות AVX2. שימו לב שהחוזה של הקונטיינר לא מכיל פרטים נוספים על פלטפורמת המעבד (CPU).

יכול להיות שהקונטיינר יופעל בכמה ליבות בו-זמנית.

בשירותי Cloud Run, הקצאת המעבד (CPU) תלויה בחיוב שנבחר.

אם בוחרים בחיוב לפי מכונה, המעבד מוקצה במהלך חיי המכונה. אם בוחרים בחיוב לפי בקשה (ברירת המחדל), המערכת מקצה מעבד (CPU) כשהמכונות מעבדות בקשות. פרטים נוספים זמינים במאמר הגדרות החיוב.

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

כדי להפחית את זמן האחזור בזמן האתחול, אתם יכולים להפעיל את האצת המעבד בזמן אתחול כדי להגדיל באופן זמני את הקצאת המעבד בזמן אתחול המכונה.

זיכרון

כברירת מחדל, לכל קונטיינר של Cloud Run מוקצה הזיכרון שהוגדר (כברירת מחדל, ‎512MiB). אפשר להגדיר מגבלות זיכרון לכל קונטיינר בנפרד.

השימושים הנפוצים בזיכרון כוללים:

• קוד שנטען לזיכרון כדי להפעיל את השירות
• כתיבה במערכת הקבצים
• תהליכים נוספים שפועלים בקונטיינר, כמו שרת nginx
• מערכות לשמירה במטמון בזיכרון, כמו OpCache של PHP
• שימוש בזיכרון לכל בקשה
• אמצעי אחסון משותפים בזיכרון

בו-זמניות (שירותים)

בשירותי Cloud Run, כל מכונה של Cloud Run מוגדרת כברירת מחדל לבו-זמניות מרובה, שבה קונטיינר ה-ingress יכול לקבל יותר מבקשה אחת בו-זמנית. אפשר לשנות את זה באמצעות הגדרת בו-זמניות.

הגבלות אבטחה על קונטיינרים

ההגבלות הבאות חלות על קונטיינרים שפועלים ב-Cloud Run. הן חלות בלי קשר למשתמש Linux שצוין להפעלה בקובץ האימג' של הקונטיינר.

הרשאות מצומצמות

ב-Cloud Run, הקונטיינרים לא מקבלים את יכולות הבסיס (root) של גבול האבטחה של המכונה. קונטיינרים לא יכולים לבצע פעולות ששמורות למארח, כמו:

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

הגבלות על תהליכים וקריאות מערכת

פרופילי אבטחה בסיסיים, בדומה לפרופילי אבטחה של seccomp ל-Docker, מוחלים על כל אחד מהקונטיינרים.

השימוש ב-eBPF ובאמצעי אבטחה אחרים ברמת הליבה (kernel) שלא מוגנים או מוגבלים על ידי מרחבי שמות של Linux מושבת, ואין תמיכה בשימוש בהם בתוך קונטיינרים.

מסיבה זו, יכול להיות שגם השימוש בקריאות מערכת אחרות או בגישה לקובצי מערכת שדורשים הרשאות ברמת הבסיס (root) במכונה של Cloud Run יהיה מוגבל.

ארגז חול של מאגרים

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

אם אתם משתמשים בסביבת ההפעלה מהדור השני, יש לכם תאימות מלאה ל-Linux. משימות ב-Cloud Run תמיד משתמשות בסביבת ההפעלה מהדור השני. בסביבת ההפעלה מהדור השני, הערך של /sys/class/dmi/id/product_name מוגדר ל-Google Compute Engine.

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

מגבלות על תיאורי קבצים

בסביבות של Cloud Run מהדור הראשון והשני, מספר מתארי הקבצים שתהליך יכול לפתוח מוגבל ל-25,000. ההגדרה הזו חלה על הקונטיינר ועל כל תהליך צאצא שהוא יוצר (forks). זו מגבלה קשיחה. אם חורגים מהמגבלה, יכול להיות שייגמרו למכונה תיאורי הקבצים או השקעים.

מגבלות בסביבת הדור השני

חוץ מהמגבלות על תיאורי הקבצים שתיארנו קודם, המגבלות בסביבה מהדור השני הן מגבלות Linux רגילות.

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

לדוגמה, בקובץ Docker, מסירים את ההוראה 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. לא נדרשות ספריות לקוח. מידע נוסף זמין במאמר קבלת מטא-נתונים.

בטבלה הבאה מפורטים חלק מהפרטים שזמינים בשרת המטא-נתונים:

ב-Cloud Run לא מופיעים פרטים על Cloud de Confiance האזור שבו המכונות פועלות. לכן, מאפיין המטא-נתונים /computeMetadata/v1/instance/zone תמיד מחזיר את הערך projects/PROJECT-NUMBER/zones/REGION-1.

שמות הקבצים

שמות הקבצים שבהם אתם משתמשים בקונטיינרים חייבים להיות תואמים ל-UTF-8, כלומר להיות בקידוד UTF-8 או בקידוד שאפשר להמיר באופן אוטומטי ובטוח ל-UTF-8. אם שמות הקבצים שלכם משתמשים בקידודים שונים, הפעילו את ה-build של Docker במכונה עם שמות קבצים שתואמים ל-UTF-8, והימנעו מהעתקת קבצים למאגר שמכיל שמות שלא תואמים ל-UTF-8.

פריסת הקונטיינר תיכשל אם שמות הקבצים לא תואמים ל-UTF-8. שימו לב שאין הגבלה על קידוד התווים שבו אתם משתמשים בקובץ.

זמנים קצובים לתפוגה של בקשות יוצאות

בשירותים ובמשימות של Cloud Run, יש זמן קצוב לתפוגה אחרי 10 דקות של חוסר פעילות לבקשות מהקונטיינר ל-VPC. בבקשות מהקונטיינר לאינטרנט, הזמן הקצוב לתפוגה הוא אחרי 20 דקות של חוסר פעילות.

איפוסים של חיבורים יוצאים

מדי פעם, כשמפעילים מחדש או מעדכנים את התשתית הבסיסית, יכול להיות שחיבורים מהקונטיינר ל-VPC ולאינטרנט ינותקו ויוחלפו. אם האפליקציה שלכם עושה שימוש חוזר בחיבורים לטווח ארוך, מומלץ להגדיר אותה כך שתחדש את החיבורים כדי להימנע משימוש חוזר בחיבור לא פעיל.