אם אתה מגיע מ- תכנות או מחשוב קלאסי ועכשיו אתם מתקשים עם Homelabs, Docker, Icecast או Azuracast - אין פלא שהראש שלכם מסתובב. בין פורטים, כתובות IP, SSL, Windows, Linux וקונטיינרים, נראה שאתם צריכים תואר חדש לגמרי רק כדי להקים שרת רדיו פשוט.
החדשות הטובות הן שברגע שתבין מהן בדיוק קונטיינרים ב-Windows?במה הם שונים ממכונות וירטואליות ובאיזה מקרים הם הגיוניים - הכל מתחיל להתחבר. ניתן להפעיל מספר אפליקציות שמאזינות על אותו פורט (מבחוץ זה נראה אותו דבר), כל אחת במכולה משלה, עם אישורי SSL תקינים, ובלי צורך למלא את הבית ברספברי פיס.
מהו קונטיינר (באמת) ולמה הוא לא מכונה וירטואלית?
מיכל תוכנה הוא, למעשה, חבילה מבודדת וקלת משקל שבו אורזים אפליקציה יחד עם כל מה שהיא צריכה כדי לפעול: ספריות, זמן ריצה, תצורה וחלק ממערכת ההפעלה במצב משתמש. חבילה זו פועלת על גבי ליבת מערכת ההפעלה המארחת, במקום לשאת בתוכה מערכת הפעלה שלמה.
במכונה וירטואלית, לעומת זאת, יש לך מערכת הפעלה אורחת מלאה עם ליבה, דרייברים ושירותים משלה, הפועל על גבי היפר-ויזור כמו Hyper-V, VMware או VirtualBox. כל מכונה וירטואלית מאמינה שיש לה חומרה משלה: מעבדים וירטואליים, זיכרון RAM, דיסקים, כרטיסי רשת וכו'. זה מספק בידוד חזק מאוד, אך גם צורך יותר משאבים ולוקח יותר זמן לאתחול.
עם קונטיינרים, מערכת ההפעלה המארחת (לדוגמה) Windows Server 2019 או 2022הפצת לינוקס (או הפצת לינוקס) חולקת את הליבה שלה עם כל הקונטיינרים. כל קונטיינר רואה מערכת קבצים וירטואלית, מרחב תהליכים משלו, תצורת רשת לוגית משלו, ובכל זאת, מתחת, הכל פועל דרך אותה ליבה.
הטריק הזה של שיתוף הליבה הופך את הקונטיינר להרבה יותר קל יותר ממכונה וירטואליתזה תופס פחות מקום בדיסק, דורש פחות זיכרון, ומאתחל תוך שניות (או פחות). זו הסיבה שאתה יכול לנהל עשרות או מאות מכולות, בעוד שבעבר יכולת לנהל רק כמה מכונות וירטואליות.
לסיכום, בעוד שהמכונות הווירטואליות וירטואליזציה של חומרה והם בונים מערכת הפעלה שלמה על גבי זה, הקונטיינרים. וירטואליזציה של מערכת ההפעלה והם מבודדים רק את האפליקציה ואת סביבת המשתמש שלה.
מערכת האקולוגיה של המכולות ב-Windows: מה מיקרוסופט מציעה
מיקרוסופט משקיעה רבות במכולות במשך שנים, הן עבור חלונות ולינוקסזה לא נעצר ב"Docker עובד על Windows וזהו", אלא בנה סביבו מערכת אקולוגית שלמה: תמונות רשמיות, אינטגרציה עם Visual Studio, תמיכה ב-Azure וכלי תזמור.
בצד הפיתוח המקומי, ניתן להשתמש שולחן העבודה של Docker ב-Windows 10/11 להריץ מכולות של Windows ו-Linux במחשב האישי שלך. Docker Desktop ממנף את פונקציונליות המכולות המובנית ב-Windows, ובמידת הצורך, גם מכונה וירטואלית קטנה עבור מכולות של Linux או ב- WSL2אבל כל זה שקוף בפניך.
אם אתם עובדים בסביבת שרתים, שרת Windows 2016, 2019, 2022 ו-2025 הם מאפשרים לך להריץ קונטיינרים באופן טבעי. בעזרתם, תוכל לבנות פתרונות רציניים: יישומי .NET קלאסיים, שירותי backend, ממשקי API, מיקרו-שירותים וכו', ארוזים בתמונות ונפרסים כקונטיינרים.
עבור מחזור הפיתוח המלא, Visual Studio ו-Visual Studio Code משתלבים תמיכה מקורית עבור DockerDocker Compose, Kubernetes ו-Helm. זה מאפשר לך לקמפל, לאתר באגים, ליצור תמונות ולפרסם אותן לרישום בכמה לחיצות או ישירות מהעורך, מבלי לעבור כל הזמן בין כלים. אם ברצונך להשוות סביבות וכלים, עיין במדריך זה בנושא. IDE וכלי פיתוח.
ניתן להעלות את התמונות שיצרת ל רכזת דוקר (אם לא אכפת לך אם הם ציבוריים) או רישום מכולות Azure (ACR) אם אתם רוצים רישום פרטי בתוך הארגון או סביבת הענן שלכם, סביבות הפיתוח, הבדיקה והייצור שלכם יכולות למשוך את התמונות משם ולפרוס אותן לפי הצורך.
איך באמת עובד מיכל של Windows
מכולה של Windows מבוססת על ליבת המארחאבל הוא לא מתחבר אליו באופן אקראי. המערכת נותנת לו "תצוגה" מבודדת של המשאבים: מערכת קבצים וירטואלית, ערכי הרישום שלה, תהליכים, רשת, ואם תרצו, אחסון מתמשך המותקן חיצונית.
הקבצים והספריות שהאפליקציה זקוקה להם במצב משתמש ארוזים לתוך תמונה בסיסיתמעל תמונת הבסיס, נערמות שכבות נוספות: תלויות ספציפיות, תצורות, קוד האפליקציה שלך... התוצאה של ערימת השכבות היא תמונת המכולה הסופית, שתהיה התבנית שממנה תתחיל מכולה אחת או יותר.
נקודה מרכזית אחת: תמונות הן בלתי ניתנות לשינויכשיוצרים קונטיינר מתמונה, השינויים שהאפליקציה מבצעת (קבצים זמניים, יומני רישום וכו') נשמרים בשכבה הניתנת לכתיבה מעל. אם מבטלים את הקונטיינר, שכבה זו תאבד אלא אם כן טענתם אמצעי אחסון או אחסון קבועים, כגון דיסק Azure או שיתוף Azure Files.
מערכת שכבתית זו מאפשרת לך שימוש חוזר בתמונות בין יישומים. לדוגמה, צוות .NET מפרסם תמונות .NET Core מוכנות מראש (מבוססות על Nano Server), ואתם רק מוסיפים את הקוד והתצורה שלכם. זה חוסך לכם התקנת זמני ריצה בכל פעם, והשכבות המשותפות מורדות פעם אחת בלבד.
עבור תהליכי בידוד ב-Windows ישנם שני מצבים: בידוד תהליכיכאשר המכולות חולקות ישירות את ליבת המארח, ו- בידוד באמצעות Hyper-Vכאשר כל קונטיינר פועל בתוך מיקרו-וירטואלי (micro-VM) עם ליבה משלו. הראשון קל יותר, השני מציע אבטחה ותאימות נוספות.
תמונות בסיס של Windows וסוגי מכולות
מיקרוסופט מציעה מספר תמונות בסיס רשמיות תמונות Windows עליהן ניתן לבנות את התמונות המותאמות אישית שלך. כל אחת מהן מיועדת לתרחישים, גדלים ותאימות שונים.
תמונת "Windows" כוללת כמעט כל ממשקי ה-API והשירותים של המערכת (למעט תפקידי שרת מסוימים). זהו השרת השלם ביותר, מתאים אם אתם זקוקים לתאימות מרבית עם יישומים המשתמשים בפונקציות רבות של מערכת הפעלה.
תמונת "שרת Windows" מכוונת ל תרחישי שרת זה כולל גם את כל חבילת ה-API והשירותים של Windows Server. אידיאלי עבור יישומים ארגוניים שכבר תוכננו עבור סביבה זו.
"Windows Server Core" היא גרסה נוספת אוֹרהוא משתמש בתת-קבוצה של ממשקי ה-API של Windows Server ובגרסה המלאה של .NET Framework. הוא כולל את רוב תפקידי השרת, אך לא את כולם. זהו בסיס טוב ליישומי שרת אופייניים שאינם דורשים ממשק גרפי מלא.
"שרת ננו" הוא הכי טוב מינימלי ואופטימליהוא מיועד ל-.NET Core ולתפקידי שרת ספציפיים. גודלו הקטן הופך אותו לאטרקטיבי מאוד עבור קונטיינרים שבהם רוצים להתחיל במהירות רבה ולצרוך מעט משאבים.
בזכות האופי הרב-שכבתי של הטבע, לא תמיד צריך להתחיל עם אחת מהתמונות ה"טהורות" הללו. אפשר להשתמש, למשל, בתמונה רשמית של ליבת .NET או ליבת ASP.NET שכבר כולל את זמן הריצה, ואז אתה פשוט מוסיף את האפליקציה שלך. זה מפחית את עבודת התצורה וגם משפר את אחסון המטמון של Docker מכיוון שאתה משתף שכבות עם תמונות אחרות.
קונטיינרים למפתחים ומנהלי מערכת
עבור צוות הפיתוח, קונטיינרים הם זהב טהור: הם מאפשרים אתחול סביבות זהות לייצור תוך שניות ספורות, מבלי לפגוע במערכת ההפעלה של המחשב הנייד ובלי לריב על גרסאות ספרייה או תלויות.
במקום המשפט האופייני "זה עובד על המחשב שלי", המפתח מפעיל קונטיינר עם אותה תמונה כמו בשרת הייצור. תמונה זו כוללת את גרסאות מדויקות של זמני ריצה, מסגרות ותצורה שהיישום צריך, כל כך הרבה בעיות של "קובץ DLL זה שונה כאן" או "גרסת Java אינה תואמת" נעלמות.
המכולות גם מקלות על עבודת צוותשיתוף סביבה הוא פשוט כמו העברת Dockerfile או שם תמונת הרישום. כל חבר צוות יכול להפעיל את אותו שירות תוך שניות, מבלי שיהיה צורך לעקוב אחר מדריכי התקנה ארוכים.
עבור אנשי IT ומנהלי מערכות, קונטיינרים מאפשרים לכם לבנות תשתיות סטנדרטיות לפיתוח, אבטחת איכות וייצור. כל סביבה מוגדרת על ידי אותם תמונות וקבצי תזמור, מה שמפחית הפתעות ושגיאות תצורה ידניות.
בנוסף, ניתן להשתמש במצב האינטראקטיבי של מכולות כדי להריץ, לדוגמה, גרסאות מרובות של אותו כלי שורת פקודה באותו שרת ללא התנגשויות. זה שימושי מאוד לבדיקות, הגירות או תאימות עם תוכנות מדור קודם, ולמשימות כגון יצירת סקריפטים של Bash ב-Windows.
הבדלים עיקריים בין קונטיינרים של Windows ו- Linux
למרות שהם דומים מבחינה רעיונית, ישנם הבדלים חשובים בין קונטיינרים של Windows ו- Linux. שניהם חולקים את ליבת המארח, אך ברור שזה לא אותו ליבה וגם לא חושף את אותם ממשקי API, כך שכל מארח יכול להריץ רק קונטיינרים מסוג מערכת ההפעלה שלו.
על מחשב אחסון לינוקס, ניתן להריץ רק קונטיינרים של לינוקס באופן טבעי. במארח Windows, ניתן להריץ מכולות Windows באופן טבעי, ובאמצעות טכניקות כמו Hyper-V או WSL2, גם מכולות Linux, אם כי במקרה כזה יש למעשה שכבה נוספת הפועלת כמתווכת.
ל-Windows יש שני מצבי בידוד: תהליכים ו-Hyper-V. בידוד תהליכים דומה מאוד לזה של לינוקס: המכולה משתפת ישירות את הליבה והתהליך העיקרי שלו נתפס גם על ידי המארח כתהליך נוסף. אם תסתכלו על רשימת התהליכים עם PowerShell, תראו שה-PID של המכולה תואם לתהליך על המארח.
במצב Hyper-V, כל מכולה פועלת בתוך מיקרו-VM עם גרעין מבודד משלומהמארח, כבר לא רואים את תהליך האפליקציה ישירות, אלא את תהליך ה-VM (לדוגמה, vmwp ב-Windows). זה מאובטח יותר ומציע תאימות רבה יותר עם חלק מהיישומים, אך צורך מעט יותר משאבים.
יש גם מגבלות ספציפיות במכולות של Windows: לא כל דבר ניתן לאחסון במכולות. לדוגמה, שירותים כמו Microsoft DTC (Distributed Transactions), יישומי לקוח עם ממשקים גרפיים מסורתיים כמו Office, ותפקידי תשתית מסוימים כגון DHCP, DNS, בקר תחום, NTP או שרתי הדפסה וקבצים אינם נתמכים בתוך מכולות סטנדרטיות.
יתרונות השימוש במכולות (גם ב-Windows)
רשימת היתרונות של קונטיינרים ארוכה, והיא חלה גם על לינוקס וגם על חלונות. הראשון הוא ה- בידודכל קונטיינר הוא יחידה עצמאית, מה שמפחית קונפליקטים בין יישומים ומשפר את האבטחה אם משהו נשבר או נפגע.
השני הוא ה ניידותקונטיינר עוטף את האפליקציה עם התלויות והתצורה שלה, כך שניתן להעביר אותה בין מכונות שונות, מרכזי נתונים או עננים ציבוריים מבלי שתצטרכו להגדיר מחדש הכל מאפס. המנטרה של "בנה פעם אחת, הפעל בכל מקום" הגיונית לחלוטין כאן.
יתרון גדול נוסף הוא יעילות משאביםמכיוון שמספר קונטיינרים חולקים את אותו ליבה, צריכת ה-RAM והדיסק לכל מופע נמוכה בהרבה מזו של מכונה וירטואלית. ניתן להריץ יישומים רבים יותר על אותו שרת פיזי, וכתוצאה מכך לחיסכון בעלויות.
בפיתוח, קונטיינרים הם מאיץ אכזרי: הם יוצרים סביבות ניתן לשחזור ואוטומטיקהפרקטיקות אלו תואמות מאוד את DevOps ואת CI/CD. הגדרת התמונה ב-Dockerfile וניהול גרסאות שלה ב-Git מאפשרות לך לשלוט בדיוק במה שנמצא בפרודוקציה וכיצד הוא נבנה.
יתר על כן, יכולת התחזוקה משתפרת: עדכון אפליקציה כרוך בבניית תמונה חדשה ולפרוס אותו. אם משהו משתבש, ניתן לחזור לגרסה הקודמת ללא בעיות, פשוט על ידי שינוי התווית או הפריסה לתמונה אחרת.
בטיחות וסיכונים במכולות
אבטחת מכולות היא עניין רציני: זה לא רק עניין של "לבודד אותן קצת" ולסיים את היום. צריך להגן עליהן. כל השרשרתמתמונת הבסיס שבה אתם משתמשים ועד לזמן הריצה שבו המכולה פועלת. כדי לחזק את הגנת המארח, סקרו כלים ו... אפליקציות לשיפור האבטחה.
אחד הסיכונים הנפוצים ביותר הוא שימוש תמונות עם נקודות תורפה או אפילו עם תוכנות זדוניות. לכן חשוב לסרוק תמונות (שלך ושל צד שלישי) באמצעות כלי ניתוח פגיעויות לפני העלאה או פריסה שלהן.
סכנה נוספת היא חשיפה ל מידע רגישסיסמאות, מפתחות API או אישורים המוטמעים בתמונה או במשתני סביבה בלתי מבוקרים עלולים לדלוף מידע קריטי אם התמונה מתפרסמת במאגר רישום ציבורי או אם מישהו מקבל גישה למערכת.
אנחנו צריכים גם לדאוג ל- תצורת זמן ריצההרשאות מוגזמות, טעינת אמצעי אחסון בלתי מוגבלים של מארח, יכולות רשת פתוחות מדי וכו'. מכולה שתצורתה שגויה יכולה לשמש כנקודת כניסה לפריצה למארח או לשאר התשתית.
כדי למתן את כל זה, כלי סריקה, ניתוח קוד סטטי ודינמי, מדיניות אבטחה של שרשרת האספקה ובקרות פלטפורמת תזמור (כגון Kubernetes) משמשים להגדרת מגבלות משאבים, מדיניות רשת וכללי גישה.
מכולות או מכונות וירטואליות: מתי כל אחת מהן מתאימה?
בחירה בין קונטיינרים למכונות וירטואליות אינה עניין של שחור ולבן. שתי הטכנולוגיות הן מַשׁלִים ולמעשה, בסביבות רבות הם משולבים: מכונות וירטואליות כבסיס ומכולות מעל עבור יישומים.
מכונות וירטואליות הן הבחירה ההגיונית כשאתם צריכים בידוד מוחלט, הפעלת מערכות הפעלה שונות (לדוגמה, לינוקס על מחשב מארח של Windows ללא שכבת תוכנה ספציפית) או כאשר היישום דורש גישה ברמה נמוכה מאוד לחומרה או מנהלי התקנים ספציפיים.
המכולות, לעומת זאת, זורחות כאשר העדיפות היא ה... יעילות, מהירות וגמישותהם מופעלים תוך שניות, ניתנים להרחבה בקלות וצורכים פחות משאבים, וזה מושלם עבור מיקרו-שירותים, ממשקי API, שרתי אינטרנט ויישומים מודרניים באופן כללי.
בענן, ספקים בדרך כלל מפעילים מכולות על מכונות וירטואליות ברקע. לדוגמה, Azure Kubernetes Service (AKS) פורס צמתים על מכונות וירטואליות של Azure, ומכולות פועלות על מכונות וירטואליות אלו. זה נותן לך את הגמישות של שני העולמות: בידוד חזק ברמת הצומת וביצועים קלים ברמת האפליקציה.
במקרים רבים, ההחלטה המעשית היא לערבב: להשתמש במכונות וירטואליות עבור שירותי תשתית קריטיים או מחוברים באופן הדוק למערכת ההפעלה, ומכולות עבור שכבות יישומים שנהנות ממדרגיות וניידות.
תזמור: מדוע Kubernetes וחברתו חיוניים
למרות שיש לכם רק שניים או שלושה קונטיינרים, ניהול ידני שלהם באמצעות `docker run`, `docker stop` או `docker logs` אינו בעיה. הבעיה מתעוררת כאשר האפליקציה שלכם מורכבת מ... עשרות או מאות מכולותעם עותקים משוכפלים, איזון עומסים, עדכונים וניטור.
שם ה תזמורי מכולות כמו Kubernetes, שהפכה למרכיב מפתח בכל תשתית מודרנית מבוססת מכולות. משימתה היא לנהל מכולות בקנה מידה גדול ובתהליך הייצור.
תפקידים אופייניים של תזמור כוללים את יישום המוני של מכולות, הקצאת עומס לצמתי אשכול, ניטור תקינות (אם מכולה אחת נכשלת, אחרת משתלטת), מעבר לגיבוי בין צמתים ושינוי קנה מידה אוטומטי של עומס.
הם גם אחראים על ה- פונקציות רשתהם חושפים שירותים כלפי חוץ, מספקים שירותי גילוי פנימיים, מיישמים כללי חומת אש בין פודים וכו'. הם גם מתאמים עדכוני יישומים (למשל, פריסות מתגלגלות) כדי למנוע הפסקות שירות.
בעולם מיקרוסופט, הרכיב המרכזי הוא Azure Kubernetes Service (AKS), המציע Kubernetes מנוהל הן ב-Azure והן בסביבה מקומית דרך Azure Arc או Azure Stack. פלטפורמות אחרות כמו רד האט הם גם מספקים תמיכה הולכת וגוברת עבור קונטיינרים של Windows, ומרחיבים את האפשרויות עבור סביבות היברידיות.
קונטיינרים בענן וכשירות
ספקי הענן הגדולים הרכיבו קטלוג שלם של שירותי מכולות כך שלא תצטרכו לנהל הכל מאפס. ברמות התשתית (IaaS) והפלטפורמה (PaaS), תוכלו למצוא הכל, החל מרשמי תמונות ועד אשכולות Kubernetes מנוהלים במלואם.
Amazon Web Services מציעה את Amazon ECS (שירות מכולות אלסטי) ואת Amazon EKS (שירות Kubernetes אלסטי). ECS הוא אחד השירותים. קנייני של AWSEKS, לעומת זאת, מספקת לך Kubernetes מנוהל, וזה מאוד שימושי אם אתה רוצה להשתמש בתקן התעשייה דה פקטו.
ב-Microsoft Azure, בנוסף ל-AKS, יש לך Azure Container Registry לאחסן ולגרס את תמונות המכולה שלך באופן פרטי. זה מתאים באופן מושלם לצינורות CI/CD המבוססים על Azure DevOps או GitHub Actions.
פלטפורמת הענן של גוגל מציעה את מנוע Kubernetes של גוגל (GKE) כפתרון Kubernetes המנוהל העיקרי שלה. היא כוללת גם את מנוע האפליקציות להפעלת אפליקציות אינטרנט ונייד ללא ניהול ישיר של קונטיינרים, אם כי מנגנונים דומים פועלים גם כן.
מלבד ענקיות אלו, ספקי IaaS ו-PaaS רבים אחרים מציעים וריאציות של "מכולות כשירות". המפתח הוא שתתמקדו ב... תמונה של האפליקציה שלך ובתצורה שלו, והספק דואג לצמתים, לתיקוני מערכת, להרחבת קנה מידה ואפילו לחלק מאבטחת התשתית.
כלים ליצירה וניהול של מכולות
הכלי הפופולרי ביותר לעבודה עם מכולות הוא, ללא ספק, סַוָרDocker הציגה פורמט תמונה סטנדרטי, זמן ריצה ומערכת אקולוגית סביבו שפישטו מאוד את אימוץ הקונטיינרים, אפילו על ידי אנשים שלא היו מומחי מערכות.
בלב ליבה של Docker נמצא Docker Engine, הרכיב שאחראי על יצירה, הפעלה וניהול של מכולות על המארח. בנוסף לכך, ה-Dockerfile הוא קובץ הטקסט שבו אתה מתאר כיצד לבנות את התמונה שלך: איזה בסיס להשתמש, אילו חבילות להתקין, אילו פורטים לחשוף, איזו פקודה להריץ בעת ההפעלה.
תמונת המכולה המתקבלת היא קובץ לוגי המכיל את כל הרכיבים הדרושים ליישום: קוד, זמן ריצה, תלויות וחלק ממערכת ההפעלה. מתמונה זו ניתן להפעיל מכולה אחת או יותר, שהן המופעים החיים הפועלים על המארח.
כדי לשתף ולהפיץ תמונות, Docker Hub משמש כ... רישום ציבורי עצום, עם אלפי תמונות רשמיות וקהילתיות. ארגונים משלבים אותו לעתים קרובות עם רישומים פרטיים, כגון ACRs או רישומים המאוחסנים בעצמם, כדי לשלוט טוב יותר על מה שנפרס בייצור.
מלבד Docker ו-Kubernetes, צצו כלים נוספים: Podman (ללא daemon ותואם ל-Docker CLI), containerd (זמן הריצה ש-Docker משתמש בו מתחת), OpenShift כפלטפורמה ארגונית המבוססת על Kubernetes, Nomad של HashiCorp לתזמור עומסי עבודה, Docker Swarm כמתזמור פשוט יותר, ופתרונות כמו LXD או Vagrant המכסים תרחישים קשורים.
יישומים מעשיים: מנטפליקס ועד למעבדה הביתית שלך
מכולות משלוח אינן מיועדות רק לחברות גדולות. ברחבי העולם, חברות כמו נטפליקס הם משתמשים בהם כדי להרחיב את פלטפורמת הסטרימינג שלהם, בנקים כמו ג'יי.פי מורגן צ'ייס ממנפים אותם לשירותי בנקאות מקוונת, ובתי חולים כמו מאיו קליניק מיישמים אותם במערכות ניהול מטופלים.
במגזר החינוך, אוניברסיטאות כמו הרווארד משתמשות במכולות משלוח כדי פלטפורמות למידה מקוונותהבטחת סביבות עקביות לסטודנטים הפרוסות ברחבי העולם. ובמנהל הציבורי, אפילו סוכנויות כמו משרד ההגנה האמריקאי משתמשות בקונטיינרים ביישומי ביטחון לאומי.
אבל אם ניגשים לקרקע, במעבדה ביתית או בפרויקט אישי, קונטיינרים מאפשרים לך להקים שירותים כמו Icecast, Azuracast, שרתי אינטרנט, מסדי נתונים או לוחות ניטור על מכונה אחת, ללא חפיפה של פורטים או תלויות.
במקום להקדיש Raspberry Pi לכל שירות, ניתן להגדיר מספר קונטיינרים באותו מארח ולהשתמש ב-Reverse Proxy (למשל, Nginx או Traefik עם קונטיינרים) שמקבל תעבורת HTTPS בפורט 443 ומפיץ אותה באופן פנימי לשירותים השונים שלכם בהתבסס על הדומיין או הנתיב.
בנוגע ל-SSL, הנקודה המרכזית היא להבין ש- ההצפנה מסתיימת בשלב מסוים בשרשרת: זה יכול להיות במכולה שמפעילה את השירות או בפרוקסי הפוך שלפניה. בשני המקרים, המכולה רואה תעבורת HTTP "רגילה" לפורט הפנימי שלה, למרות שהכל מבחוץ מוצפן.
ברשת, לכל קונטיינר יש את שלו כתובת IP פנימית בתוך רשת Docker ופורט פנימי. מבחוץ, המארח מפרסם פורט אחד או יותר וממפה אותם לפורט הפנימי של הקונטיינר. זה מסביר מדוע יכולים להיות מספר קונטיינרים שמאזינים לאותו פורט פנימי 80, בעוד שבמארח פותחים רק, לדוגמה, 8080, 8081 ו-8082 עבור כל אחד מהם.
בהקשר זה, מכולות ב-Windows הגיוניות מאוד כשרוצים נצל את מכונת ה-Windows הנוכחית שלך (מחשב נייד, מחשב שולחני, שרת) לאירוח שירותים מרובים מבלי להקים גן חיות של מכשירים פיזיים, שמירה על סדר, בידוד וניהול פשוט יחסית.
בסופו של דבר, הבנת האופן שבו מכולות פועלות ב-Windows, תפקידן של תמונות בסיס, כיצד הן משתלבות עם הרשת והיתרונות שלהן על פני מכונות וירטואליות מאפשרת לך לקבל החלטות חכמות יותר: החל מבחירה האם אפליקציית .NET הבאה שלך תהיה מבוססת על מכולות או תפעל במכונה וירטואלית, ועד לדעת כיצד להגדיר Icecast עם SSL ב-ThinkPad שלך מבלי לצרוב פורטים או משאבים.
