תמלול הפרק (לחצו לפתיחה)
מבוא לדוקר ומושגי יסוד
אהלן, אני אורן מהייטקיסטים בדרכים וברוכים הבאים להרצאה הראשונה על דוקר. בהרצאה הזאת נלמד על מושגי יסוד שקשורים בדוקר ונבין את היתרונות והחסרונות של שימוש בדוקר. אז מה זה דוקר? דוקר זה בסך הכל שם של חברה שלקחה טכנולוגיה של קונטיינרים ונתנה מימוש כל כך טוב שהשם של החברה הפך להיות שם נרדף לשם של הטכנולוגיה. אז דוקר זה בסך הכל שם של חברה שנתנה מימוש ממש טוב.
אז מה זה טכנולוגיה של קונטיינרים? נסביר את זה על ידי דוגמה. דוגמה שאני חושב שרוב המאזינים מכירים ונתקלו בה: בכל חברה בעבר וכנראה גם היום, יש איזה קובץ איפשהו בגוגל דוקס, איזה מסמך וורד שעובר, שמסביר איך להרים את האפליקציה שהיא המוצר של החברה. במסמך הזה משתמשים בו גם QA, גם מפתחים. כל מי שלמעשה רוצה להרים סביבה עם המוצר של החברה משתמש במסמך הזה, והוא בדרך כלל אומר משהו כמו: "קחו סביבה, נניח של אובונטו (Ubuntu), שימו בה גרסה Java 8, תתקינו עליה DB של MySQL, תכניסו לשם דאטה, תיצרו טבלאות, תכניסו לשם דאטה, אחר כך לכו לקובץ קונפיגורציה תשנו בשורה 40 את השם...".
אני מניח שזה נשמע מוכר לרוב מי שמקשיב, וככה באמת היו עובדים כדי ליצור איזה אחידות או ליצור איזה דרך שבה כל מי שמעלה סביבה של המוצר עושה את זה באותה צורה. ולמה אנחנו רוצים את האחידות הזאת? כדי שכולם יעבדו באותה צורה ואם יש באג, אם טסטר מצא עכשיו באג והוא הולך למפתח, אז המפתח יגיד לו: "כן, הנה אני רואה באמת על מה אתה מדבר", או "לא, הנה אצלי זה עובד". אנחנו רוצים שתהיה איזה אחידות שכולם יעבדו על אותה סביבה, ובעבר הדרך להשיג את זה הייתה פשוט לעבוד עם איזה מסמך כזה שרץ בין כולם וכולם עובדים איתו.
אז הטכנולוגיה של קונטיינרים זה למעשה סוג של קסם. זה היכולת לקחת את המסמך הארוך הזה עם ה"ליצור דאטה בייס" ו"לך לשורה 40 ותשנה שם" וכל הדברים האלה - למעשה לקחת את כל המסמך הזה וליצור קובץ אחד או יחידה אחת. יחידה אחת מאוד בסיסית שהיא נקראת Image. וכל מי שרוצה מעכשיו להרים סביבה פשוט מריץ פקודה אחת ויש לו סביבה מוכנה ואחידה. אז זה למעשה הטכנולוגיה של קונטיינרים, ועל הדרך דיברנו גם על Image. אז Image זה באמת הסט הזה של ההוראות, זה השם של האפליקציה שארוזה ביחד עם כל מה שהיא תלויה בו, וכולם יכולים להשתמש באימג' הזה ולהריץ אותו.
ומה קורה כשמריצים אימג' כזה? אנחנו למעשה מייצרים Container (קונטיינר), שזה המושג הבא שנדבר עליו. אז קונטיינר זה למעשה האינסטנס (Instance) או היחידת הרצה של Image. אם Image הוא מקביל למסמך הזה בגוגל דוקס שנותן לנו את כל הסט של ההוראות איך להרים סביבה, אז קונטיינר זה למעשה הסביבה הזאת אחרי שהרצנו את האימג'.
אז Image זה סט של הוראות שהוא למעשה Read-only, אנחנו לא יכולים לשנות שום דבר באימג'. אם ארבעה אנשים הורידו אליהם את האימג' - אנחנו עוד מעט נדבר על מאיפה הם הורידו את האימג' - אבל אם ארבעה מפתחים מחזיקים אצלם את האימג', הם לא יכולים לשנות שום דבר באימג', אבל הם כן יכולים להריץ אותו וליצור קונטיינר שזה הרצה של האימג' אצלם. ואז אצלם בסביבה הם יכולים כבר לשנות דברים, למשל להוסיף עוד טבלה לדאטה בייס שנוצר, סתם דוגמה.
אז למעשה דיברנו פה על דוקר שזה שם של חברה שנתנה מימוש לטכנולוגיה של קונטיינרים, דיברנו על מה זה טכנולוגיה של קונטיינרים - זה למעשה לקחת את הקסם הזה, לקחת את היכולת להימנע מרשימה ארוכה של הוראות ופשוט תק, בבת אחת להריץ פקודה ויש לנו את הסביבה מוכנה. Image זה באמת הסט של ההוראות האלה שארוזות ביחד, וקונטיינר זה ההרצה של האימג'.
המושג הבא: Docker Hub. דוקר האב זה רפוזיטורי (Repository) עולמי של אימג'ים של חברת דוקר שמאפשר לכל מי שרוצה להעלות אל הרפוזיטורי הזה או להוריד מהרפוזיטורי אליו אל המכונה שלו. אז דוקר האב זה למעשה הרפוזיטורי הכי גדול והכי מפורסם והכי בשימוש, אבל יש גם רפוזיטורים אחרים של חברות אחרות, ובנוסף אנחנו יכולים גם בחברה שלנו - אם אנחנו עובדים בחברה שעובדת עם דוקרים - יכול להיות לנו גם רפוזיטורי רק לעובדי החברה, וגם לרפוזיטורי הזה נוכל להעלות אימג'ים ולהוריד אימג'ים.
המושג הבא: Docker Engine. אז מה זה דוקר אנג'ין? דוקר אנג'ין זה רכיב לוקלי, זה למעשה תוכנה של חברת דוקר שנמצאת אצלנו על המכונה, על המחשב, שהרכיב הזה יודע לעשות שלושה דברים. יש לו בתוכו חלקים פנימיים והוא יודע לעשות הרבה דברים אחרים, אבל אפשר לקחת את כל הפעולות שלו ולחלק אותן לשלושה דברים: הדבר הראשון זה ליצור אימג'. הוא יודע לקחת סט של הוראות - אנחנו נסביר בינתיים הכל ב-High Level - אבל הוא יודע לקחת סט של הוראות וליצור מזה Image. הדבר הבא שהוא יודע לעשות זה להעביר מהרפוזיטורי אלינו או מהמכונה שלנו אל הרפוזיטורי אימג'ים. הוא יודע להוריד אימג'ים, הוא יודע להעלות אימג'ים. והדבר השלישי והכי חשוב שהדוקר אנג'ין עושה זה למעשה לקחת אימג' ולהריץ אותו כקונטיינר.
ומה זה אומר? דוקר אנג'ין עכשיו מחזיק אצלו Image שהוא למעשה הקסם הזה. עוד לא דיברנו ועוד לא נכנסנו לקרביים של איך זה באמת עובד, אבל מה שהדוקר אנג'ין בעצם עושה זה לוקח את האימג' הזה, הוא מבין מה צריך כדי באמת להריץ את האימג', הוא מקצה מקום בזיכרון על המכונה, מקצה את כל מה שצריך כדי להריץ אפליקציה שזה מקום בזיכרון, שזה CPU, פורטים שצריכים להיות פתוחים, כל מיני משאבים שנמצאים על המכונה הפיזית, על ה"ברזלים", והקונטיינר צריך כדי לרוץ. ומייצר עבור הקונטיינר, עבור ההרצה הזאת של האימג', מייצר אשליה כאילו שזו מכונה פרטית עבור הקונטיינר. הקונטיינר לא יודע שהוא רץ יחד עם קונטיינרים אחרים או שהוא בכלל קונטיינר. קונטיינר חושב ומקבל את האשליה שהוא למעשה אפליקציה שרצה על מכונה משלו. זו למעשה הגדולה של דוקר: היכולת לקחת אפליקציה ולהריץ אותה על המחשב שלנו ולתת לה את ההרגשה שהיא למעשה רצה על מחשב משלה.
אז דיברנו על המסמך הזה בגוגל דוקס שהיה בעבר בחברות כדי להרים סביבה, ואז הגיעה הטכנולוגיה של קונטיינרים ודוקר וכולם עובדים עם דוקר וכולם מאושרים ואיזה כיף. ולמעשה אי אפשר לתאר ככה את המצב בלי לספר על פתרון של Virtual Machine, על VM, מכונה וירטואלית. זה פתרון שהיה קיים בעבר ויש מקומות שעדיין משתמשים בו, והפתרון של וירטואל מאשין הוא למעשה פותר בעיה מאוד דומה. הוא באמת פותר את הבעיה של המסמך הזה, רק מה - הוא פותר את זה בצורה שונה מהדוקר. ואנחנו יכולים לראות שלמעשה הווירטואל מאשין הולכים ונעלמים מהעולם והדוקר הולך ותופס יותר מקום. אז ננסה להבין איך הדוקר נתן כזה נוקאאוט לווירטואל מאשין. מה קרה שם? לא ניכנס לכל הפרטים כי זה באמת עולם ומלואו להשוות בין וירטואל מאשין ודוקר, אבל נתייחס להבדל הבאמת מהותי ביניהם שעושה את ההבדל.
וירטואל מאשין זה למעשה מכונה וירטואלית שמותקנת על גבי המחשב. יש לנו מחשב עם מערכת הפעלה מסוימת, אנחנו יכולים על המחשב הזה להתקין כמה מחשבים וירטואליים, כמה VMs, שכל אחד יכול להיות עם מערכת הפעלה אחרת ועל גבי כל אחד מהמערכות ההפעלה האחרות האלה אפשר להתקין אפליקציות אחרות. אז זה נשמע טוב, זה נשמע שזה גם פותר את הבעיה. אז למה בעצם צריך את דוקר?
אז היתרון של דוקר על הווירטואל מאשין האלה זה שדוקר הוא מאוד מאוד רזה ומשתמש בדיוק במה שהוא צריך לעומת הווירטואל מאשין שהוא למעשה מכונה וירטואלית, הוא ממש מכונה. אנחנו מרימים על גבי המכונה שלנו מערכת הפעלה שלמה שנותנת שירות לאפליקציה. עכשיו יכול להיות שהאפליקציה היא ממש קטנה וצורכת מעט משאבים, ובדוקר זה יתבטא בקונטיינר קטנצ'יק שלא לוקח כמעט שום משאבים מהמחשב המארח. לעומת זאת בווירטואל מאשין, גם אם האפליקציה היא ממש קטנה זה לא משנה, אנחנו נצטרך להרים בשבילה מערכת הפעלה שלמה רק כדי שהיא תוכל לחיות שם בתוך ה-VM הזה. אז היתרון של דוקר שהוא ממש ממש קל ובנוסף הוא ממש מהיר. אפשר בפקודה אחת להרים קונטיינר באוויר, זה לא המצב עם VM שלוקח יותר זמן להרים וירטואל מאשין על מחשב.
אז אלו למעשה היתרונות והחסרונות של וירטואל מאשין על קונטיינר. חשוב להזכיר את היתרון של VM על דוקר - שהוא למעשה מרים מערכת הפעלה שלמה ולפעמים המצב הזה הוא נחוץ. למה אני מתכוון? הקונטיינר שדוקר מריץ הוא רץ למעשה על הקרנל (Kernel) של מערכת ההפעלה של המחשב המארח. אין לו מערכת הפעלה משלו, ומה שזה מצריך זה שהמערכת הפעלה של המחשב שמארח את הקונטיינר תדע לתמוך בקונטיינר. אם הקונטיינר מריץ שם אפליקציה של ווינדוס 7 ואנחנו מריצים את זה על לינוקס, אז אנחנו לא נוכל להריץ את האפליקציה הזאת כי היא לא תוכל לרוץ על מערכת הפעלה של לינוקס. יש פה מערכות הפעלה שונות. יש פתרונות של אפליקציות כמו Docker for Mac ו-Docker for Windows שלא ניכנס לנושא הזה, אבל בעיקרון מה שהן מנסות לעשות זה לעשות איזה קונברז'ן (Conversion) ולעשות איזה התאמה של מערכות הפעלה, אבל נשאיר את זה ברמה הזאת ש-VM הוא למעשה מכונה וירטואלית, הוא למעשה מערכת הפעלה שלמה שתומכת באפליקציה שלנו שלפעמים אין מה לעשות - זה מה שאנחנו צריכים, לעומת קונטיינר שמשתמש במערכת ההפעלה של המארח שלו, של ההוסט.
אז אלו היתרונות והחסרונות של דוקר מול VM. נדבר עכשיו על היתרונות של דוקר. קראתי הרבה מאמרים ואספתי את כל היתרונות והגעתי לרשימה של תשעה יתרונות. נעבור עליהם מהר:
היתרון הראשון - הקונטיינרים של דוקר הם מאוד מאוד קלים. למה הם קלים? דיברנו על זה, בניגוד לווירטואל מאשין שצריך להרים מערכת הפעלה שלמה כדי רק להריץ את האפליקציה, הקונטיינר הוא ממש קל, לפעמים שוקל כמה עשרות מגה-בייט והוא מכיל רק את מה שהוא צריך כי הוא יודע שהוא רץ על מערכת ההפעלה של ההוסט. בגלל זה הוא לא צריך לקחת איתו הרבה דברים. הוא מכיל בדיוק את מה שהוא צריך והוא ממש קל.
היתרון הבא - שיתוף של שכבות (Layers). פה כדי להבין את היתרון הזה אנחנו צריכים להכיר יותר מה זה Image ועוד לא הגענו לזה, אבל נגיד בינתיים שאימג' הוא בנוי מהרבה שכבות. עכשיו יכול להיות שיש אימג' מסוים שהוא מכיל נניח דאטה בייס מסוג MySQL, אז יכול להיות שיש לנו 10 אימג'ים של 10 אפליקציות שונות ולכולם יש שכבה של MySQL Database. אז הדוקר בנוי בצורה כזאת שהאימג' הוא מכיל פוינטר (Pointer) לשכבה והוא לא מכיל באמת את השכבה. ולמה זה חשוב? כי אם באמת יש לנו 10 אימג'ים שכולם מכילים MySQL Database, אז הם למעשה כולם יכילו פוינטר אל השכבה באימג' של MySQL והם לא יכילו שכפול של 10 פעמים את אותה שכבה של MySQL. וכשאנחנו מתעסקים עם הרבה הרבה אימג'ים, למעשה זה יכול להיות יתרון מאוד משמעותי - במקום 10 שכבות אנחנו משתמשים פעם אחת בשכבה הזאת ומשתמשים בפוינטרים. השיתוף של שכבות זה היתרון השני.
היתרון הבא זה ניידות. ניתן לקחת קונטיינר עם כל ה-Dependencies שלו, עם כל מה שהוא צריך לבוא איתו - דיברנו על זה, גרסת Java וכאלה - ואנחנו יכולים להעלות אותו לדוקר, לתת לו גרסה וזהו. מעכשיו כל מי שרוצה יכול להוריד מה-Docker Hub או כל רפוזיטורי אחר את הקונטיינר שלנו. אנחנו כבר לא צריכים לעשות את מה שהיו עושים בעבר, שצריך למצוא דרך לשלוח את הקובץ אולי ללקוח או למחלקה אחרת, וזה גדול מדי בשביל האימייל וב-Shared Folder. אז הדרך הזאת של פשוט להעלות אותו ל-Docker Hub וכל מי שרוצה יכול לקחת אותו, זה יתרון טוב וזו למעשה יתרון הניידות.
היתרון הבא זה יתרון של Predictability. היתרון שבו הקונטיינר הוא למעשה ההתנהגות שלו ניתנת לחיזוי. אנחנו יכולים לדעת שבכל מקום שאנחנו נריץ את הקונטיינר הזה ואנחנו נפנה אליו עם איזה קריאת Postman או כל דבר אחר, אנחנו נרצה לבדוק את ההתנהגות של הקונטיינר בכל מקום שנעשה את זה - אם זה הטסטר שעכשיו בודק אצלו בסביבה, ואם זה המפתח שמפתח את הפיצ'ר, ואם זה הלקוח שמריץ את זה (בהנחה שהוא מריץ באמת בדוקר) - אנחנו יכולים לדעת שכולם יקבלו את אותה התנהגות. אין לנו הפתעות. המשפט המפורסם: "מוזר, אצלי במחשב זה עובד, אצלי בסביבה זה עבד". המשפט הזה שהוא כל כך מוכר וכל כך כאוב, כשעובדים עם דוקר קונטיינרס אנחנו יכולים לדעת שאנחנו יכולים לחזות את התנהגות הקונטיינר.
היתרון הבא - זה עוזר למפתחים. איך העבודה עם קונטיינרים עוזרת למפתחים? אז אם בעבר מפתח עבד על אפליקציה A שהיא עבדה מול אפליקציות B ו-C. אם אנחנו מדברים על מיקרו-סרוויסים, או גם בעבר אפליקציות עבדו עם אפליקציות אחרות. אז בעבר מפתח היה יכול או להרים את כל הדברים האלה לוקלית אצלו, ואז הוא באמת היה צריך ללכת למסמך גוגל דוקס הזה ולהתחיל להרים אצלו על הלפטופ הקטנצ'יק שלו, להתחיל להרים אפליקציות. או שהוא היה צריך לבחור באופציה השנייה שזה לבקש מאיזה צוות בחברה, אינפרה (Infra) או מה-DevOps, שירימו סביבה עבורו, ואז הוא היה עובד על הסביבה הזאת וזה היה כרוך גם בגזילת הרבה זמן וגם לפעמים היינו נתקלים שוב פעם במשפט המפורסם: "מוזר, אצלי בסביבה זה עובד". אז דוקר קונטיינר עוזר למפתחים בזה שמפתח שכותב פיצ'ר על אפליקציה A יכול בקלות גם להריץ את קונטיינר B ו-C ויש לו את כל החגיגה הזאת אצלו על הלפטופ בקלות ממש בשניות.
היתרון הבא - העבודה עם קונטיינרים עוזרת לאנשי ה-DevOps. איך היא עוזרת להם? היא מפנה אותם מכל המשימות האלה של ליצור סביבות לכולם, מפנה אותם למשימות אחרות. אם בעבר אנשי דבופס היו עסוקים כל הזמן בלהרים סביבות - היית בא אליהם והיית אומר: "אני צריך סביבה כזאת וכזאת בשביל לעשות בדיקות או בשביל לפתח", אז אומרים לך: "אין שום בעיה, עד יום חמישי זה יהיה מוכן". משפט שאני מניח שהרבה מאוד מזדהים איתו, שהיה צריך לחכות כמה ימים כדי שאנשי דבופס ירימו איזה סביבה מסוימת. אז היום בגלל שהמפתחים יכולים לעשות את זה בקלות, אנשי הדבופס פנויים למשימות אחרות וזה מאוד חשוב לארגון שבוחר לעבוד עם דוקר.
יתרון נוסף, אנחנו כבר ביתרון מספר 7 - זה הזמינות. בכל רגע שאנחנו נרצה אימג', אנחנו מיידית נוכל להוריד אותו. אם אנחנו עכשיו מפתחים איזה אפליקציה ואנחנו עובדים עם MySQL ואנחנו פתאום רוצים לעבוד עם איזה גרסה אחרת. אם בעבר היינו צריכים ללכת לגוגל ולהתחיל להוריד איזה קובץ זיפ ולהתחיל התקנה עם נקסט נקסט וכל מיני דברים כאלה, עכשיו אנחנו פשוט יכולים ללכת לקובץ הגדרות שעדיין לא דיברנו עליו, אבל אפשר פשוט ללכת להגדרות של איזה אימג' אנחנו רוצים, פשוט לשנות את הגרסה מגרסה 7 ל-8, ותק - יש לנו את גרסה 8 בזמינות מיידית.
היתרון הבא, יתרון מספר 8 - זה שהטכנולוגיה של דוקר היא עובדת כטכנולוגיה של קוד פתוח (Open Source) והמון המון מפתחים מוצאים זמן כדי לתרום לקוד הזה, לשפר אותו, להוסיף לו פיצ'רים. זה תחום שהוא מאוד חם וזה יתרון מאוד משמעותי לטכנולוגיה הזאת שהיא כל הזמן מתפתחת ומשתפרת.
והיתרון האחרון ברשימה המפוארת הזאת - זה שהוא מהיר ל-Redeploy. מה הכוונה Redeploy? אם בעבר נניח שכבר אנשי הדבופס התקינו לנו סביבה או שאנחנו התקנו סביבה, עשינו את כל הפעולות שהיו כתובות בגוגל דוקס ומשהו קרה - אנחנו לא יודעים מה עשינו, אבל כנראה שמחקנו איזה טבלה שהיה אסור לנו למחוק, או שעשינו איזה משהו, שינינו איזה קובץ קונפיגורציה שלא היינו צריכים למחוק, ועכשיו הסביבה הזאתי מבחינתנו קוראפטד (Corrupted). אנחנו לא רוצים להמשיך לבדוק את האפליקציה או לפתח על הסביבה הזאת, אנחנו רוצים סביבה חדשה. אז באותו אופן, אם בעבר היינו צריכים לפתוח קריאה נוספת לאנשי הדבופס או שבעצמנו היינו צריכים עכשיו למחוק הכל ולהתחיל לבצע את כל השורה של הפקודות האלה - אנחנו יכולים תוך ממש כמה שניות, וזה באמת כמה שניות, ליצור לנו סביבה חדשה.
אלו למעשה תשעת היתרונות של הטכנולוגיה של דוקר שאני מצאתי. אני בטוח שיש עוד או שיכול להיות שחלק מהם הם משוכפלים ואני פשוט ראיתי אותם כיתרונות שונים.
ועכשיו שדיברנו על דוקר ופיארנו אותו ואנחנו מתלהבים מאוד מהטכנולוגיה הזאת, נדבר על החסרונות של דוקר. אז החסרונות של דוקר - בעצם יש תשעה חסרונות ולא שלושה. נתחיל לעבור על החסרונות:
החיסרון הראשון, והוא למעשה באמת חיסרון שהוא הכי הכי חשוב בהקשר של דוקר ודיברנו עליו - זה שהוא לא נותן תמיכה מלאה במערכות הפעלה שהן לא לינוקס. מה הכוונה? דיברנו על זה שדוקר קונטיינר רץ על מערכת ההפעלה של ההוסט, אין לו מערכת הפעלה משלו כמו לווירטואל מאשין, ולכן אם יש לנו אפליקציה שהיא לא רצה על לינוקס אז יש פה בעיה. חשוב לציין שיש אפליקציות כמו Docker for Windows ו-Docker for Mac שהן כביכול מאפשרות להריץ דוקר על ווינדוס או על מק. מהניסיון שלי על מק זה עובד טוב ועל ווינדוס זה פשוט סיוט, לא עובד, תקלות ובעיות. אבל זה אפשרי עבור ווינדוס 10 ומעלה ועבור גרסה מסוימת של מק שאני לא זוכר אותה כרגע יש תמיכה. אפשר לסכם את החיסרון הזה כתמיכה לא מלאה במערכות הפעלה שהן לא לינוקס. כדי לרדת לדקויות צריך לעשות קצת מחקר לגבי האפליקציה הספציפית שאתם רוצים להריץ ולראות אם זה אפשרי, אבל בעיקרון אם אתם לא עובדים עם לינוקס, האפליקציה שלכם לא רצה על לינוקס או לא על ג'אווה, אז כדאי לעשות מחקר על העניין הזה. אז זה החיסרון הבאמת עיקרי של דוקר.
חיסרון הבא זה החיסרון של עקומת הלמידה. וזה חיסרון יותר למנהלי פיתוח או ל-VP R&D או למנכ"לים, שבאמת כשהם מסתכלים על הטכנולוגיה הזאת של דוקר ורואים את כל היתרונות שלה, הם צריכים גם לקחת בחשבון שכדי לקחת צוות פיתוח שלא יודע מה זה דוקר ולהעביר אותו לעבוד עם דוקר זה דבר שלוקח זמן ויש פה עקומת למידה. והמעבר הוא לא פשוט, וחברה שהיא כל הזמן רודפת אחרי הפיצ'רים ורק מנסה להספיק לעמוד בזמן - לא תמיד אפשר באמת לעצור הכל ולהתחיל ללמד את המפתחים על דוקר.
חיסרון הבא זה נושא האבטחה (Security). ובאמת כשרכבתי את הרשימה של היתרונות והחסרונות, נכנסתי להרבה מאמרים שמדברים על נושא האבטחה בדוקר. הטיעון שמדבר על זה שיש פה בעיית אבטחה הוא הטיעון שאומר שב-VM, בווירטואל מאשין, האפליקציות - כל אפליקציה נמצאת על מערכת הפעלה שונה, זאת אומרת יש הפרדה ברמת מערכת הפעלה בין אפליקציות שונות. לעומת קונטיינרים של דוקר שהם כולם נמצאים על אותה מערכת הפעלה, ככה שאם האקר הצליח לפגוע באפליקציה אחת בקונטיינר אחד, הוא למעשה יכול דרך השכבה של מערכת ההפעלה להגיע לקונטיינרים אחרים. זה הטיעון, וזה נושא מאוד מורכב עם הרבה ויכוחים ומאמרים, אבל בוא נכיר את זה שיש פה איזה סוגיה של אבטחה, שאם אנחנו באמת בתחום שהאבטחה היא נושא מאוד חשוב בו, אז חשוב להכיר את זה שלדוקר יש איזה שם כזה של בעיה מבחינת אבטחה.
החיסרון הבא, אנחנו כבר בחיסרון 4 - זה התחייבות לסוג אחד של קונטיינרים. ומה הכוונה? דיברנו על זה שדוקר נותן תמיכה מלאה רק ללינוקס, ועם מק ווינדוס וגם מערכות הפעלה אחרות יש פתרונות אבל הם מאוד חלקיים. אז גם כשאנחנו עובדים לפי הפתרון החלקי הזה - כלומר אם עכשיו אנחנו עובדים על מחשב מסוג ווינדוס ואנחנו רוצים להריץ קונטיינר שהוא במקור נכתב ללינוקס ועכשיו אנחנו מריצים אותו על ווינדוס. אז אם אנחנו משתמשים בפתרון הזה של Docker for Windows ועושים איזה המרה כזאת, אנחנו צריכים לעשות את אותה המרה על כל הקונטיינרים שרצים על ווינדוס. מה שאומר שאנחנו לא יכולים להריץ חלק מהקונטיינרים על לינוקס וחלק על ווינדוס. אז אנחנו צריכים גם כשאנחנו עובדים עם הפתרון הזה של Docker for Windows או Docker for Mac, יש לנו איזה סוג של התחייבות לסוג אחד של קונטיינרים שזה מגבלה.
החיסרון הבא, אנחנו בחיסרון מספר 5 - זה חיסרון של ניהול כמות גדולה של קונטיינרים. אם אנחנו עובדים בכמות מאוד גדולה, וזה קורה לפעמים שאנחנו צריכים כבר להריץ עשרות ואולי יותר של קונטיינרים, הפתרון של דוקר הוא כבר פתרון לא כל כך נוח. קשה לנהל את כל הדוקרים האלה כשמדובר בכמות גדולה. אבל לא צריך להתרגש מהחיסרון הזה של דוקר, כי בשביל זה יש את הפתרון של קוברנטיס (Kubernetes), שקוברנטיס זה למעשה מוצר שמנהל קונטיינרים של דוקר. אנחנו כנראה שבהייטקיסטים בדרכים יהיה קורס על קוברנטיס, אז אנחנו נדבר על זה. אבל כשאנחנו מסתכלים על דוקר כפתרון בפני עצמו, צריך להזכיר שיש לו חיסרון - הוא לא יודע לנהל כמות גדולה של קונטיינרים והוא באמת צריך את הקוברנטיס כדי שיעזור לו עם זה.
אנחנו בחיסרון מספר 6 - החיסרון הזה אני הגדרתי אותו כחברות עם IT קשוח. ולמה הכוונה? כדי להריץ קונטיינר אנחנו צריכים Root Credentials. זה למעשה יוזר שיש לו הרשאות של Root, הרשאות שהן ברמה גבוהה שמאפשרות לו באמת לקבל שליטה על המחשב. ובחברות קפדניות, חברות Fortune 500, חברות גדולות עם מחלקת IT קשוחה, הם לא כל כך מתלהבים לתת לקונטיינר את ההרשאות האלה. בנוסף יש חברות שהן מוכנות רק להוריד אימג'ים של חברות מוכרות. זאת אומרת, בתוך Docker Hub יש אימג'ים שנחשבים Official ואימג'ים שהם Non-official. אז חברה שהיא עם IT שמכבד את עצמו לא תסכים להשתמש ב-Docker Hub להוריד דוקר אימג' שהוא לא של חברה רשמית שקיבלה באמת הכרה רשמית והגרסה של האימג' שלה נחשב בטוח. אז יכול להיות שדיברנו על הסעיף של אבטחה ויכול להיות שבאמת אין בעיית אבטחה בדוקר או שהיא נפטרה או שהיא לא רלוונטית אלינו, אבל גם אם אין באמת בעיה טכנית טכנולוגית לעבוד עם טכנולוגיית דוקר, עצם העובדה שיהיה לנו קשה לגרום לחברה להריץ את האימג' שלנו, את המוצר שלנו אצלה בגלל שמחלקת ה-IT תעשה לנו בעיות - זה גם נחשב חיסרון של דוקר.
נמשיך הלאה. אנחנו בחיסרון מספר 7. החיסרון הזה אני מגדיר אותו כמהירות. ולמעשה החיסרון הזה מדבר על זה שכשאנחנו מריצים קונטיינר אנחנו לא באמת מריצים אותו על ה"ברזלים". אם אנחנו ניקח ונתקין עכשיו דאטה בייס של MySQL, נלך לגוגל, נוריד קובץ זיפ, נעשה את ה-Next Next ובסוף נתקין את הדאטה בייס הזה אצלנו על המחשב, לעומת זאת נריץ קונטיינר, נריץ אימג' של MySQL ונריץ בעזרת האימג' קונטיינר של MySQL - ואם אנחנו נשווה את הביצועים של ההתקנה הזאת שבאמת יושבת לנו על הברזלים של המחשב לעומת ההתקנה של הקונטיינר, יהיו הבדלים מאוד מזעריים במהירות, אבל יהיו. כי אין מה לעשות, לקונטיינר יש איזה Overhead מסוים כשהוא רץ על שכבה מסוימת שמנהלת אותו על ה-Docker Engine לעומת אפליקציה שבאמת הורדנו והתקנו. אז יש איזה Overhead - אני לא יודע להגיד אותו באחוזים, אבל ממש אחוזים בודדים של מהירות האפליקציה. אז בוא נגיד שאת מערכת "כיפת ברזל" כנראה שאנחנו לא נריץ בקונטיינר אם אנחנו צריכים משהו שבאמת רץ מהר, אבל ברוב המקרים כשאנחנו עובדים עם אפליקציות האובר-הד הזה הוא ממש זניח. חשוב להכיר שזה חיסרון של דוקר.
אנחנו בחיסרון השמיני, וזה חיסרון שעכשיו שאני רואה ששמתי אותו במקום השמיני אני קצת מתחרט, כי יכול להיות שהוא היה צריך להיות יותר למעלה במיקום כי הוא באמת חיסרון משמעותי - וזה החיסרון של שמירה של State עבור הקונטיינר. מה הכוונה State? דיברנו על זה שאימג' הוא Read-only, אי אפשר באמת לשנות אותו. אם הרבה מפתחים או הרבה אנשים ייקחו את אותו אימג', יהיה להם את אותו אימג' ביד והם לא יוכלו לשנות אותו. אבל לעומת זאת, כשהם יריצו קונטיינר ממנו, אז באמת הם יכולים כבר להתחיל לכתוב לדאטה בייס שלו, הם יכולים לעבוד עם ה-API, ואז למעשה לקונטיינר הזה נוצר סטייט מסוים. אז הנושא של שמירה על הסטייט, שמירה על המצב של ה-File System למשל של הקונטיינר, הוא נושא בעייתי. יש פתרונות, ובאמת כשהקונטיינר יורד למטה אז יש אפשרות לשמור את המידע על משהו שנקרא Volume. אנחנו נדבר על זה בהרצאה הזאת, אנחנו ניכנס לזה בזום-אין וממש נבין מה זה Volume. אז יש אפשרות באמת לשמור סטייט של קונטיינר אבל זה נושא טריקי. לא פשוט, לא תמיד עובד, ואפשר להגיד שזה חיסרון של דוקר לעומת באמת שתהיה לנו את האפליקציה אצלנו ויהיה לה סטייט קבוע.
והגענו לחיסרון האחרון שהוא רלוונטי לקונטיינרים שמריצים אפליקציה עם UI. אפליקציה שרצה עם UI, קונטיינר של אפליקציה שמכיל UI - זה בעייתי להריץ אותו בתור קונטיינר ולעבוד עם ה-UI שלו. אפשרי, אבל עדיף שלא. אם זו אפליקציה שכוללת UI זהו.
אז אלו החסרונות שבחרתי להזכיר. דיברנו על תשעה יתרונות ותשעה חסרונות. למעשה סיימנו את ההרצאה להיום, ובהרצאה הבאה אנחנו נדבר על מה זה Image. דיברנו על זה היום אבל אנחנו באמת ניכנס בזום-אין מאוד רציני על מה זה Image ונלמד את הנושא. אז נתראה בהרצאה הבאה!