קונטיינרים. מצד אחד, בשנתיים האחרונות אי אפשר לבקר בכנס מחשוב או להיכנס לאתר של חברות טכנולוגיות בלי לשמוע על קונטיינרים. מצד שני, הרושם שמתקבל משיחות עם אנשים רבים בתעשייה היא שרבים עדיין לא יודעים במה בדיוק מדובר וגם בין אלו שכבר קצת מכירים יש לא מעט שלא בטוחים איך זה עובד ולמה זה טוב.
בפוסט זה אתאר באופן כללי מה עושים קונטיינרים, על איזה צריכים הטכנולוגיה הזו נועדה לתת מענה ואציין אתגרים עכשוויים בתחום המחשוב ששימוש בטכנולוגיה של קונטיינרים מסייע בפתרונן . פוסט זה הוא מעין מבוא לקראת סדרה של פוסטים שאפרסם בעתיד הקרוב בערוץ שיכללו סקירה טכנית ומעמיקה יותר על קונטיינרים. בהמשך יעסקו הפוסטים בערוץ ב-Kubernetes, בעולם ה-Cloud Native ובטכנולוגיות משיקות.
למה צריך את זה?
במקום לענות על למה צריך קונטיינרים, אפשר להתחיל עם שאלה מקדימה – למה צריך וירטואליזציה? כנראה שהתשובה על זה די מובנת מאליה - בשביל לחסוך במשאבים. במקום מספר שרתים פיזיים שלא מנצלים את החומרה שעליהם הם מותקנים, מתקינים שרת פיזי אחד שמריץ הרבה שרתים וירטואליים.
אבל רגע, אם המשאבים של שרתי פיזי אחד מספיק להריץ X יישומים בתור מכונות וירטואליות למה בעצם היו לנו X שרתים פיזיים? למה לא התקנו מראש את כל היישומים בשרת אחד?
טוב, זו גם לא שאלה שצריך להתאמץ לענות עליה, כל אחד יודע שיש כל כך הרבה כיוונים שבהם הרצה של שני שירותים בשרת אחד יכולה להסתיים באסון, שאף אחד לא יכול לדעת מאיזה כיוון יגיע הפיצוץ הראשון – התנגשויות פורטים, גרסאות Libraries שונות, Process ששותה את כל הזיכרון או המעבד וכן הלאה. עם שלל הבעיות האפשריות, במוקדם או במאוחר משהו ישתבש, וכנראה שדי במוקדם.
אז בהתחלה הפרדנו את השירותים לשרתים נפרדים כדי שהם יוכלו לעבוד. אחר כך הפכנו את השרתים למכונות וירטואליות כדי לשפר את נצילות החומרה ובדרך גם גילינו שמעבר לנצילות לווירטואליזציה יש לא מעט יתרונות אחרים. אבל משהו בכל הסיפור הזה בכל זאת קצת מוזר. מה שעושה ה-Hypervisor זה להקצות משאבים נפרדים לכל מכונה וירטואלית שהוא מריץ. אם נסתכל כדוגמה על הווירטואליזציה שמספק KVM, ה-Hypervisor המובנה בקרנל (Kernel) של לינוקס, KVM מקצה משאבים למכונה וירטואלית שהיא בעצם Process שרץ במערכת ההפעלה המארחת. אבל אם הקרנל של מערכת ההפעלה שלנו מסוגל לייצר את ההפרדה הזו בין המשאבים שהוא מקצה לכל מכונה וירטואלית, למה בעצם אנחנו צריכים להריץ מערכת הפעלה עבור כל אחד מהיישומים שאנחנו רוצים להריץ במסגרת משאבים נפרדת, למה שלא פשוט נשתמש במערכת ההפעלה שלנו להריץ את התהליך שאנחנו רוצים על גבי הקצאת המשאבים הנפרדת הזו? Why won’t we cut the middle man out?
בגדול, לשאלה הזו יש שתי תשובות. התשובה הראשונה היא שאם היישום שאנחנו מריצים במכונה הווירטואלית מיועד למערכת הפעלה שונה מזו שרצה במערכת המארחת –Windows או לינוקס עם קרנל בגרסה אחרת, אז אנחנו צריכים את מערכת ההפעלה כדי לספק ליישום את הסביבה שהוא צריך. והתשובה השנייה היא שאם אין סיבה עקרונית שלא לעשות את זה אז באמת למה שלא נעשה את זה, בשביל זה יש לנו קונטיינרים.
למה רק עכשיו באים?
אם מה שכתבתי קודם נכון ובעצם אפשר להשתמש בקונטיינרים כפתרון הגיוני, חסכוני ופשוט יותר מווירטואליזציה, אז למה בעצם כבר פלוס מינוס עשר שנים כולם עובדים עם שרתים וירטואליים ועל קונטיינרים כפלטפורמה לשרתי Production שומעים רק בשנתיים שלוש האחרונות, אם בכלל, ורוב התעשייה עדיין נמצאת בשלבים ראשוניים ביותר של אימוץ הטכנולוגיה?
אז קודם כל, לעיתים קרובות לעשות משהו פשוט מאוד בצורה טובה מאוד זה מאוד מורכב. באחד הפוסטים הבאים אציג באופן מפורט יותר איזה הפרדות נדרשות על מנת לבודד תהליך בקונטיינר ואיך הן מיושמות על ידי מערכת ההפעלה, ושכשנכנסים לפרטים קל להבין שיישום ההפרדות הנדרשות מורכב למדי.
מעבר לכך, למרות שטכנולוגיות הפרדת המשאבים הנדרשות למימוש קונטיינרים פורסמו כקוד חופשי ואומצו לקרנל של לינוקס לפני למעלה מעשור, שימוש ביכולות בפועל להרצת קונטיינרים נעשה בעיקר בחדרי השרתים של גוגל במסגרת מערכת שהיותה ייחודית לגוגל נחשבה ליתרון עסקי משמעותי והפרטים עליה נשמרו במשך שנים בסודיות כמעט מוחלטת. אני אחזור לדבר על המערכת הזו, Borg, בעתיד, בפוסטים שיעסקו במערכת החופשית שנולדה בעקבותיה, קוברנטיס.
כמו שאפשר כבר להבין ממה שכתבתי עד כה, מבחינת הקרנל של לינוקס, במערכת ההפעלה עצמה, לא קיים אובייקט מסוג קונטיינר. לקרנל יש יכולות ותכונות שמאפשרות לממש הפרדת משאבים שונים בין תהליכים, אבל בשביל להריץ בפועל תהליך באופן מבודד צריך לבצע לא מעט פעולות ועוד לפני כן להחליט כל מיני החלטות. צריך לבחור באילו הפרדות מתוך האפשרויות שהקרנל מספק כדאי להשתמש, איזה פרמטרים להגדיר לכל הפרדה וכן הלאה. בלי מעטפת ידידותית ופשוטה ליכולות של הקרנל או לחילופין ליווי צמוד של צוות מהנדסים עם יכולות דומות לצוות ה-SRE של גוגל, המאמץ הנדרש להרצת תהליך מבודד גדול מכדי שזה יהיה פרקטי.
על מנת שהטכנולוגיה של קונטיינרים תתפוס תאוצה ופופולריות שני דברים היו צריכים להתפתח. הראשון זה ממשק משתמש ידידותי והשני זה יתרון מובהק או פונקציונליות ייחודית של הטכנולוגיה, ובשאיפה כאלו שיוצאים מחדר השרתים וקורצים לא רק לאנשי Ops אלא גם לקהל הרחב של מפתחי תוכנה.
הראשונים שעלו על פורמולה מנצחת לקונטיינרים היו דוקר (Docker), וזכות הראשונים הזו גרמה לכך שעבור רבים כיום דוקר משמש כשם גנרי ונרדף לקונטיינרים. על הגורמים להצלחת הטכנולוגיה ועל התקדמות של עולם הקונטיינרים מהצעדים הראשונים של דוקר אז לתעשייה מבוססת עם סטנדרטים פתוחים כיום אכתוב בפוסט הבא – אז והיום.
מייסד-שותף בחברת Wizards
קונטיינרים. מצד אחד, בשנתיים האחרונות אי אפשר לבקר בכנס מחשוב או להיכנס לאתר של חברות טכנולוגיות בלי לשמוע על קונטיינרים. מצד שני, הרושם שמתקבל משיחות עם אנשים רבים בתעשייה היא שרבים עדיין לא יודעים במה בדיוק מדובר וגם בין אלו שכבר קצת מכירים יש לא מעט שלא בטוחים איך זה עובד ולמה זה טוב.
בפוסט זה אתאר באופן כללי מה עושים קונטיינרים, על איזה צריכים הטכנולוגיה הזו נועדה לתת מענה ואציין אתגרים עכשוויים בתחום המחשוב ששימוש בטכנולוגיה של קונטיינרים מסייע בפתרונן . פוסט זה הוא מעין מבוא לקראת סדרה של פוסטים שאפרסם בעתיד הקרוב בערוץ שיכללו סקירה טכנית ומעמיקה יותר על קונטיינרים. בהמשך יעסקו הפוסטים בערוץ ב-Kubernetes, בעולם ה-Cloud Native ובטכנולוגיות משיקות.
למה צריך את זה?
במקום לענות על למה צריך קונטיינרים, אפשר להתחיל עם שאלה מקדימה – למה צריך וירטואליזציה? כנראה שהתשובה על זה די מובנת מאליה - בשביל לחסוך במשאבים. במקום מספר שרתים פיזיים שלא מנצלים את החומרה שעליהם הם מותקנים, מתקינים שרת פיזי אחד שמריץ הרבה שרתים וירטואליים.
אבל רגע, אם המשאבים של שרתי פיזי אחד מספיק להריץ X יישומים בתור מכונות וירטואליות למה בעצם היו לנו X שרתים פיזיים? למה לא התקנו מראש את כל היישומים בשרת אחד?
טוב, זו גם לא שאלה שצריך להתאמץ לענות עליה, כל אחד יודע שיש כל כך הרבה כיוונים שבהם הרצה של שני שירותים בשרת אחד יכולה להסתיים באסון, שאף אחד לא יכול לדעת מאיזה כיוון יגיע הפיצוץ הראשון – התנגשויות פורטים, גרסאות Libraries שונות, Process ששותה את כל הזיכרון או המעבד וכן הלאה. עם שלל הבעיות האפשריות, במוקדם או במאוחר משהו ישתבש, וכנראה שדי במוקדם.
אז בהתחלה הפרדנו את השירותים לשרתים נפרדים כדי שהם יוכלו לעבוד. אחר כך הפכנו את השרתים למכונות וירטואליות כדי לשפר את נצילות החומרה ובדרך גם גילינו שמעבר לנצילות לווירטואליזציה יש לא מעט יתרונות אחרים. אבל משהו בכל הסיפור הזה בכל זאת קצת מוזר. מה שעושה ה-Hypervisor זה להקצות משאבים נפרדים לכל מכונה וירטואלית שהוא מריץ. אם נסתכל כדוגמה על הווירטואליזציה שמספק KVM, ה-Hypervisor המובנה בקרנל (Kernel) של לינוקס, KVM מקצה משאבים למכונה וירטואלית שהיא בעצם Process שרץ במערכת ההפעלה המארחת. אבל אם הקרנל של מערכת ההפעלה שלנו מסוגל לייצר את ההפרדה הזו בין המשאבים שהוא מקצה לכל מכונה וירטואלית, למה בעצם אנחנו צריכים להריץ מערכת הפעלה עבור כל אחד מהיישומים שאנחנו רוצים להריץ במסגרת משאבים נפרדת, למה שלא פשוט נשתמש במערכת ההפעלה שלנו להריץ את התהליך שאנחנו רוצים על גבי הקצאת המשאבים הנפרדת הזו? Why won’t we cut the middle man out?
בגדול, לשאלה הזו יש שתי תשובות. התשובה הראשונה היא שאם היישום שאנחנו מריצים במכונה הווירטואלית מיועד למערכת הפעלה שונה מזו שרצה במערכת המארחת –Windows או לינוקס עם קרנל בגרסה אחרת, אז אנחנו צריכים את מערכת ההפעלה כדי לספק ליישום את הסביבה שהוא צריך. והתשובה השנייה היא שאם אין סיבה עקרונית שלא לעשות את זה אז באמת למה שלא נעשה את זה, בשביל זה יש לנו קונטיינרים.
למה רק עכשיו באים?
אם מה שכתבתי קודם נכון ובעצם אפשר להשתמש בקונטיינרים כפתרון הגיוני, חסכוני ופשוט יותר מווירטואליזציה, אז למה בעצם כבר פלוס מינוס עשר שנים כולם עובדים עם שרתים וירטואליים ועל קונטיינרים כפלטפורמה לשרתי Production שומעים רק בשנתיים שלוש האחרונות, אם בכלל, ורוב התעשייה עדיין נמצאת בשלבים ראשוניים ביותר של אימוץ הטכנולוגיה?
אז קודם כל, לעיתים קרובות לעשות משהו פשוט מאוד בצורה טובה מאוד זה מאוד מורכב. באחד הפוסטים הבאים אציג באופן מפורט יותר איזה הפרדות נדרשות על מנת לבודד תהליך בקונטיינר ואיך הן מיושמות על ידי מערכת ההפעלה, ושכשנכנסים לפרטים קל להבין שיישום ההפרדות הנדרשות מורכב למדי.
מעבר לכך, למרות שטכנולוגיות הפרדת המשאבים הנדרשות למימוש קונטיינרים פורסמו כקוד חופשי ואומצו לקרנל של לינוקס לפני למעלה מעשור, שימוש ביכולות בפועל להרצת קונטיינרים נעשה בעיקר בחדרי השרתים של גוגל במסגרת מערכת שהיותה ייחודית לגוגל נחשבה ליתרון עסקי משמעותי והפרטים עליה נשמרו במשך שנים בסודיות כמעט מוחלטת. אני אחזור לדבר על המערכת הזו, Borg, בעתיד, בפוסטים שיעסקו במערכת החופשית שנולדה בעקבותיה, קוברנטיס.
כמו שאפשר כבר להבין ממה שכתבתי עד כה, מבחינת הקרנל של לינוקס, במערכת ההפעלה עצמה, לא קיים אובייקט מסוג קונטיינר. לקרנל יש יכולות ותכונות שמאפשרות לממש הפרדת משאבים שונים בין תהליכים, אבל בשביל להריץ בפועל תהליך באופן מבודד צריך לבצע לא מעט פעולות ועוד לפני כן להחליט כל מיני החלטות. צריך לבחור באילו הפרדות מתוך האפשרויות שהקרנל מספק כדאי להשתמש, איזה פרמטרים להגדיר לכל הפרדה וכן הלאה. בלי מעטפת ידידותית ופשוטה ליכולות של הקרנל או לחילופין ליווי צמוד של צוות מהנדסים עם יכולות דומות לצוות ה-SRE של גוגל, המאמץ הנדרש להרצת תהליך מבודד גדול מכדי שזה יהיה פרקטי.
על מנת שהטכנולוגיה של קונטיינרים תתפוס תאוצה ופופולריות שני דברים היו צריכים להתפתח. הראשון זה ממשק משתמש ידידותי והשני זה יתרון מובהק או פונקציונליות ייחודית של הטכנולוגיה, ובשאיפה כאלו שיוצאים מחדר השרתים וקורצים לא רק לאנשי Ops אלא גם לקהל הרחב של מפתחי תוכנה.
הראשונים שעלו על פורמולה מנצחת לקונטיינרים היו דוקר (Docker), וזכות הראשונים הזו גרמה לכך שעבור רבים כיום דוקר משמש כשם גנרי ונרדף לקונטיינרים. על הגורמים להצלחת הטכנולוגיה ועל התקדמות של עולם הקונטיינרים מהצעדים הראשונים של דוקר אז לתעשייה מבוססת עם סטנדרטים פתוחים כיום אכתוב בפוסט הבא – אז והיום.
מייסד-שותף בחברת Wizards
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר