סטטוס וירטואליזציה מבוססת קוד פתוח – סוף 2018

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

מי שהולך לכנסים והרצאות של חברות שונות ושל ספקי ענן שונים, שומע בוודאי איך חברה X או חברה Y עברו לענן, הם מרוצים עד השמיים והכל ורוד ומאושר. המציאות, לפחות משיחה עם חברים פרילאנסרים שמבצעים אינטגרציות או מעברים לפלטפורמות שונות – קצת שונה. כן, ישנן חברות שמעבירות חלק מהמכונות VM שלהן לענן, חלקן מעיפות מכונות VM ומשתמשות בשרתי ענן שונים (כ-PaaS), אבל לא יצא לי להכיר שום חברה עם כמה אלפי מכונות VM בארץ שבסופו של דבר השביתה את ה-DC שלה והעבירה הכל מהכל לענן. ככלל, הויכוחים על העלויות השונות בטווח הזמן הקצר והארוך (בתוספת כמה מילות Buzz) גורמים ללא מעט חברות להאט מעבר לענן, לבצע Hybrid מדוד מאוד, והיו כמובן לא מעט מקרים שפשוט "חזרו הביתה" (אם כי זה לא סופי. מי שחושב שאין בתחום ה-IT מקרים שמקבלים החלטה X ואחר כך מבטלים ואחר כך שוב חוזרים – מוזמן להתעורר).

אני מודה שעד לאחרונה כל עניין הוירטואליזציה בקוד פתוח לא ממש תפס אחוז גדול בתחום ההטמעות ב-Enterprise. כמעט כולם הולכים ל-VMware, חברות שכמעט כל התשתית שלהם מבוססת מיקרוסופט משתמשים ב-Hyper-V ואלו שרוצים Hyper Converged הולכים על Nutanix או Simplivity. אחרי הכל – למוצרים האלו יש תמיכה, יש בארץ אינטגרטורים, לא צריך לקנות מחו"ל רשיונות, יצרני החומרה מאשרים שהמוצרים עובדים עם הברזלים. בקיצור, סבבה אגוזים.

אבל בימים אחרונים קיבלתי 2 שיחות טלפון מ-2 חברות גדולות שהמנהלים הבכירים שלהם קוראים בלוג זה. אחד מהם בתפקיד בכיר בחברה בטחונית מאוד גדולה וידועה. הבקשה שלהם היתה זהה – הם מעוניינים לצמצם את ההוצאות על הרשיונות ומוכנים לשקול גם מעבר לפתרונות קוד פתוח או פתרון מסחרי מבוסס קוד פתוח. מטבע הדברים אני לא יכול לתת לאף אחד מענה טלפוני מבלי לפגוש את הלקוח, לראות מה התשתית, מה הם רוצים לבצע, לאן הם רוצים להגיע, מה הידע המקצועי שיש בחברה ועוד ועוד, ולכן בפוסט זה אתמקד יותר בפתרונות ה"חמים"/פופולריים בשוק ולמי הם מתאימים.

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

בפוסט זה אציג, כמו בפוסטים קודמים – 3 מערכות (Proxmox, oVirt/RHV, OpenStack) ולמי הם מתאימים ומה השוני שלהם.

נתחיל במערכת שמתאימה יותר לחברה קטנה או ל-LAB מקומי: Proxmox.

תוכנת Proxmox מתאימה ליישומי וירטואליזציה הן על מערכות ישנות (כן, אותו שרת G7 של HP שיושב שם בצד) והן על מערכות חדשות. המערכת עצמה היא יחסית קלה ללימוד, ומי שעבד על ESXi עם vCenter בצורה לא מקצועית (כלומר לא עבר קורסים והכשרות של VMware) יוכל להקים תוך דקות ספורות מכונות וירטואליות על דיסקים מקומיים, לחבר NFS או iSCSI וגם להשתמש ב-HA ולבצע Live Migration (כל עוד יש אחסון משותף, זו לפחות הדרך המומלצת). בקיצור -אם אתם צריכים להקים מערכת וירטואליזציה על מספר קטן של שרתים, ללא הקמה של רשתות וירטואליות מורכבות או דברים הרבה יותר מורכבים (DVSwitch?) – אז Proxmox יכול להתאים למשימה.

המערכת הבאה יותר מתאימה לחברות שמריצות מערכות וירטואליזציה מורכבות עם רשתות וירטואליות שונות (המערכת משתמשת ב-Open Virtual Network ו-Open vSwitch, וכן רשתות SDN), סטורג'ים בפרוטוקולים שונים, חיבור ל-OpenStack, ודברים נוספים. המערכת היא oVirt. טכנית, oVirt נבנתה מגירסה 4 להריץ מערכות גדולות וכשאני מציין גדולות, אני מדבר על אלפי ועשרות אלפי מכונות וירטואליות. בשעה שפתרונות כמו ProxMox מתרכזים ב-Bridge Networking, מערכת oVirt תומכת במספר פתרונות רשתות וירטואליות, והיא בין המערכות היחידות שתומכות גם בפלטפורמות שאינן X86-64 כמו מערכות Power ו-S390 של IBM. מבחינת HA, היא בין המערכות המובילות בדיקות ברמת חומרה (דרך ILO/IMM/IDRAC) מה קורה לברזל והיא יודעת להעביר את ה-VM אם יש תקלה ולטפל בשרתים פיזיים בעייתיים – החל מהקמה של חדשים, שדרוג קיימים ועוד. מערכת oVirt מבוססת על מערכת KVM האחרונה (כן, אותה חברה שמפתחת את oVirt היא אותה חברה שמפתחת את KVM – זו רד-האט) כך שיש תמיכה בציודים וירטואליים חדשים, מערכות UEFI וירטואליות מודרניות ועוד), התממשקות ל-VCenter, המרה יעילה של מכונות וירטואליות ל-oVirt, תמיכה ב-AD/LDAP ועוד שורה ארוכה של פונקציות. בהשוואה ל-Proxmox, מערכת oVirt היא מפלצת ולכן היא פחות מתאימה לרוץ על שרתים עם מכונות וירטואליות שמאוחסנות על דיסקים מקומיים. oVirt, אגב, מגיעה מוכנה לשימוש הן כשרת שיתחבר לסטורג' והן כ-Hyper Converged.

oVirt מתאימה להטמעות גדולות הן כ-PoC והן כפרודקשן כל עוד יש בחברה ידע פנימי (או יועץ חיצוני) שיכול לתת תמיכה. מנהלים שמנוסים עם VMWare או Hyper-V ואינם מנוסים מספיק או בעלי ידע רציני בלינוקס יתקשו בניהול מערכת כזו ללא השקעה בלימוד הדברים, והסיבה לכך פשוטה: oVirt אינה מנסה להיות העתק של VMware והדגש של oVirt הוא יותר על פונקציונאליות מאשר חזותיות (אם כי חל שיפור ניכר בחלק הזה בגירסה 4.2 ובגירסה 4.3 שתצא במהלך 2019). חברות שמעוניינות במוצר ארוז ובתמיכה רשמית עם רשיונות – ניתן לרכוש את מוצר ה-RHV עם תמיכה.

ומכאן – למפלצת הגדולה: OpenStack.

אם oVirt היא מערכת גדולה, OpenStack היא גודזילה לכל דבר ועניין. ההבדל הגדול בין oVirt ל-OpenStack הוא ש-OpenStack מנסה לתת לך הכל מהכל. וירטואליזציה? יש. קונטיינרים? יש את Zun שמאפשר להריץ קונטיינרים כ-שרות. DB כ-שרות? יש. אחסון תואם S3? יש. אחסון Images ודברים אחרים? יש. צריך Load Balancer? תכיר את Octavia, ויש עוד עשרות חלקים. עם oVirt לעומת זאת – המיקוד הוא לכיוון מתן שרותי וירטואליזציה והשרותים מסביב, לא יותר מכך.

המטרה של OpenStack היא לתת לחברה להקים ענן פרטי, רק שבניגוד לדרכים ישנות יותר שבהם היינו מקימים מערכות VM מבוססות לינוקס ריקות ועליהן היינו מקימים כל מיני שרותים – כאן המערכת מוקמת על הברזלים עם השרותים שאתה צריך ואז אפשר להשתמש בשרותים כדי להקים מה שרוצים – מכונות וירטואליות, קונטיינרים, שרותים וכו'. חשוב לזכור: מערכת OpenStack היא מערכת מאוד מורכבת, ומחייבת שיהיה בחברה ידע פנימי רציני בלינוקס, SQL, פייתון, BASH וכו' (בלא מעט מקרים כדי לאבחן תקלה או כדי לטפל בתקלה,  העבודה נעשית מול Shell ולאו דווקא מול ה-GUI) ומאוד מומלץ יועץ חיצוני צמוד ל-OpenStack.

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

ומה העתיד?

פתרונות הוירטואליזציה ממשיכים להתקדם, גם הפתרונות המסחריים הסגורים אך גם הפתרונות מבוססי הקוד הפתוח. ב-VMWare הכריזו בכנס האחרון על ESXI ל-ARM, פלטפורמה שנכנסת יותר ויותר לספקי הענן הציבורי ו"זוחלת" לכיוון ה-Enterprise (תסתכלו על Ampere). פתרון הוירטואליזציה KVM ו-QEMU (שבהם כל מערכת בנייה כמו Yocto משתמשות) יש תמיכה בעשרות מעבדי ARM כבר 6 שנים ומעלה, מערכת OpenStack תומכת ב-ARM, ו-oVirt תתמוך כנראה בגירסה הבאה (אם לא תהיה גירסה כזו, אני כנראה בשנה הבאה ארכוש שרת ARM ואבצע BUILD לכך. מהנדסי רד-האט ישראל – תתכוננו להצקות ממני 🙂 ). עוד ארכיטקטורה שהולכת להיתמך היא מעבדים זולים מבוססי MIPS החדשים.

מבחינת תקשורת – רשתות 100, 200 ו-400 ג'יגה יהפכו לאט לאט לנורמה והמתגים עצמם יהיו מבוססים שבב מרכזי קנייני ושבב ARM שמריץ לינוקס, ומי שינהל את המתג – זו מערכת הוירטואליזציה (דרך הלינוקס שרץ על המתג).

מבחינת אחסון: ישנו תהליך יחסית די חדש שיכנס לאט דרך יצרני ה-SSD והוא "העפה" של מערכת הבקר מה-SSD כך שמערכת הוירטואליזציה תחליט איך לנהל את ה-SSD, איך לבצע Garbage Collection לפי העומסים במכונה, לפי המכונות הוירטואליות שירוצו ועוד. אינטל גם תוציא את ה-Optane DC Persistent Memory – מקלות אחסון שיושבים היכן שמקלות הזכרון יושבים, מכילים הרבה יותר אחסון ממקלות זכרון ECC רגילים ועם ביצועים קרובים לביצועי זכרון. תמיכה לכך ב-OpenStack תהיה קיימת בקרוב (להלן השקפים), רק שמחכים למעבדים ושרתים מבוססי Cannon Lake SP.
עוד תחום אחסון שיקבל Boost רציני בוירטואליזציה הוא NVMEoF שיתן Latency מאוד נמוך.

לסיכום: פתרונות וירטואליזציה מבוססים קוד פתוח לא הולכים להיעלם, הם מתפתחים יותר ויותר ויודעים גם לתת "Fight" לפתרונות הסגורים. יש פתרונות גם להטמעה קטנה, גם להטמעות גדולות וגם להקמת ענן עם עשרות שרותים בתוך החברה, רק שכאן אף אחד לא עומד לך עם טיימר של 30-60 יום ל-Trial ותוציא צ'ק שמן או שאין מערכת. כל הפתרונות שתיארתי הם פתרונות טובים ויציבים לא רק לטסטים אלא גם לפרודקשן.

אם יש לכם שאלות לגבי המוצרים, אתם מוזמנים ליצור קשר.

אז אתם רוצים ללמוד על קונטיינרים

אני רוצה להתחיל את הפוסט במשהו שאמרתי למפתחים בחברה גדולה (שאינה חברת תוכנה): יכול להיות שאינכם משתמשים כיום בקונטיינרים, אבל מחר, מחרתיים, אולי עוד שנה ואולי מעט יותר – אתם תעברו להשתמש בקונטיינרים וה-Push לעבור לקונטיינרים יגיע מכל מיני כיוונים, אם זה מצד יצרני מערכות הפעלה (מיקרוסופט, רד-האט, SuSE, סאן/אורקל), אם זה מהמנמ"ר או מנהל ה-IT הראשי שיבינו שעל אותה תשתית שמריצה כיום את האפליקציות אפשר להריץ יותר אפליקציות ומכל מיני כיוונים אחרים – זה יגיע בסוף. קונטיינרים זה לא משהו שקשור לטרנד (זה קיים בתצורות שונות כבר 30 שנה, תשאלו את IBM, ואת Sun לשעבר) – זה קשור לניצול תשתית בצורה טובה יותר, לחסכון בעלויות (כשאתם משתמשים בתשתיות של ספקי ענן/פלטפורמה ציבורית) ובקיצור – זה לא משהו שאולי תעברו אליו, זו שאלה של מתי תעברו לזה. קונטיינרים אינם מחליפים תשתית וירטואליזציה, הם משתמשים באותה תשתית וירטואליזציה קיימת כך שאין צורך להחליף תשתיות.

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

הבה ניקח שפה כמו Python. נניח שאתם רוצים ללמוד את השפה. אתם לוקחים ספר, אולי קורס וידאו אונליין ואתם מתחילים לאט לאט ללמוד איך לבנות מערכים, מחרוזות, איך להדפיס למסך, איך לקרוא ולכתוב קבצים ועוד דברים רבים. בשביל לנסות את הדברים ולכתוב בעצמכם, אתם תתקינו Python על מערכת ההפעלה החביבה עליכם (בלינוקס ובמק זה מובנה) ואתם תתחילו לעבוד עם כל עורך טקסטים כדי לבנות את קבצי ה-Python ולאחר מכן להריץ אותם בעזרת פקודת python פשוטה. מאוחר יותר שתרצו לבנות פרויקטים ב-Python (ובעצם כמעט בכל שפה אחרת) אתם תשתמשו ב-IDE כלשהו שיעשה לכם את החיים יותר קלים. אם אתם עובדים בצוות, אז סביר להניח שתשתמשו ב-GIT כדי לאחסן את הקוד (ובוודאי ה-IDE יתמוך ב-GIT כדי להקל על העבודה). בקיצור – אם אתה מכיר Python, את עניין העבודה בצוות ושימוש בכלים שונים או ב-API שונים תוכל ללמוד תוך זמן קצר. אף אחד לא יסרב לשכור אותך אם אינך מכיר API זה או אחר או כלי IDE זה או אחר.

עם קונטיינרים לעומת זאת .. הדברים שונים. (בפוסט זה אני אתייחס לקונטיינרים וכו' כשהם רצים על תשתית שלכם מקומית או על מכונות EC2, ולא ECS של אמזון או GKE של גוגל). עם קונטיינרים יש לנו 2 (או 3) "שכבות שונות".

הדבר הראשון שאתם צריכים להכיר, זה: מה זה קונטיינר? את העניין שקונטיינר הוא בשום פנים ואופן לא מכונה וירטואלית (VM), את העניין של מה זה DockerFile (או docker compose – כל אחד והעדפותיו… לא שופט), מהו Image, איך הוא נוצר, מהם 2 מצבי הרשת שיש לקונטיינרים, איך קונטיינרים מתקשרים בינם לבין עצמם ובינם ל-Host, מהם "שכבות" ה-File-system בקונטיינרים, שימוש ב-Container Registry, אבטחת קונטיינרים ויש עוד כמה וכמה נושאים שצריך ללמוד בכדי להכיר טוב קונטיינרים. כמו שאתם יכולים להבין, לא מדובר במשהו שיושבים אחה"צ או באיזה ערב אחד בבית ולומדים במכה אחת. תצטרכו לזה כמה ימים כדי להכיר זאת – והכרת הקונטיינרים היא חובה לכל איש Devops או לכל מי שיבנה קונטיינרים בחברה.

אחרי שלמדנו את הבסיס על קונטיינרים, אנחנו נגלה שהמערכת (כמו Docker) שמריצה את הקונטיינרים היא מערכת די "טיפשה". היא לא יודעת לצוות כמה קונטיינרים ביחד, היא לא יודעת לעשות Load Balancing, היא לא יודעת לעשות Scaling, היא לא יודעת להפעיל שרידות אם קונטיינר נפל והיא לא יודעת לעשות דברים רבים – מהסיבה הפשוטה שמערכת כמו Docker לא בנויה לזה. בשביל זה אנחנו צריכים את השלב השני.

השלב השני הוא מה שנקרא מערכת ניהול Scheduling – זו בעצם תהיה המערכת שתעשה מה שתיארתי לעיל והרבה יותר, וזו מערכת שמשתשמת ב-Docker כדי לבצע את הדברים אך היא מוסיפה דברים רבים (שוב, כפי שתיארתי לעיל וזהו תיאור מאוד מתומצת). ישנן מערכות ניהול רבות אבל בד"כ אתם תשתמעו על Kubernetes, Docker-Swarm, ו-Apache Mesos (ויש כמובן עוד אחרות).

איזו מהמערכות כדאי ללמוד? (חשוב לשים לב – כמות הלימוד בשלב זה היא גדולה בהרבה מאשר לימוד על קונטיינרים שבשלב הראשון) זה מאוד תלוי: אם אתם לומדים זאת כחלק מהעבודה, אז כמובן שמומלץ ללמוד על המערכת שאתם משתמשים/הולכים להשתמש. אם לעומת זאת אתם לומדים בבית כחלק מתגבור הידע שלכם, אז מומלץ ללמוד על Kubernetes. ה-Kubernetes היא מערכת בקוד פתוח שמפותחת ע"י גוגל ורד-האט וכיום היא הכי פופולרית בשוק (ברגע שתפסתם ולמדתם טוב את Kuberenetes, המעבר למערכות כמו Docker Swarm הוא די קל, אם כי הוא לא כזה קל כשצריכים לעבוד עם Mesos).

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

השלב הבא הרבה יותר קצר והוא מצריך שתהיה לכם גישה למערכת וירטואליזציה כלשהו (גם VirtualBox יספיק לשם כך). בשלב זה כדאי ללמוד על מערכות הפעלה רזות. בלינוקס זה מערכת כמו Atomic. ה-Atomic זו מערכת הפלה מאוד רזה שנועדה להתקנה על שרתים או מכונות VM שיריצו את הקונטיינרים, את Kubernetes ועוד. זו אינה מערכת שמבוססת על DEB או RPM אלא מערכת של קובץ אחד (כך שאין אפשרות לעדכן חלק אחד בה. עדכון שלה הוא עדכון של כל המערכת והיא אינה שומרת מאומה למעט דברים מסויימים בתיקיה מסויימת). יתרונה הגדול על פני מערכות לינוקס מסורתיות הוא שמבחינת משאבים – המערכת מנצלת מעט מאוד. אם אתם משתמשים ב-Windows, אז כדאי שתכירו את ה-Nano Server שעליו ירוצו הקונטיינרים ומערכת ה-Scheduling.

סיימנו? כמעט 🙂

אחרי שתלמדו את Kubernetes, אתם תלמדו שלמערכת יש יתרונות רבים אבל יש לה גם חסרונות כמו אבטחה, עבודה בצוותים, שילוב ב-CI/CD, יצירת חיים יותר קלים למפתחים (שלא יצטרכו שוב ושוב לכתוב Dockerfile ודברים נוספים) וגם יהיה צורך להתגבר על הרעיון ש-Kubernetes בברירת מחדל לא מאפשר גלישה/גישה לקונטיינרים מבלי לשבור את הראש ולהשקיע בכל מיני פתרונות חצי אפויים (בניגוד לעבודה בענן, שם Kubernetes יכול עם פקודה אחת לתת גישה מבחוץ לקונטיינרים ולאפליקציות לקונטיינרים).

וכאן אני ממליץ על OpenShift – גירסת הקוד הפתוח (Origin) או הגירסה המסחרית. OpenShift בעצם מרחיב את היכולות של Kubernetes בכך שהמערכת עצמה מוסיפה דברים שתיארתי לעיל כמו projects, HAProxy, אבטחה עם SELinux, עבודה באופן מסודר עם Storage (תוך הפרדה של יצירת Volume ע"י מנהל המערכת ושימוש ב-Volume ע"י משתמש רגיל. משתמש רגיל אינו יכול ליצור Volume ב-OpenShift אבל מכיוון ש-Kubernetes לא ממש מכיר אבטחה, הוא מאפשר לכל משתמש גם ליצור Volume, לחרדת מנהל הסטורג' בחברה). עם OpenShift אנחנו יכולים לבנות את השרותים, קונטיינרים וכל הדברים דרך ממשק ה-WEB או דרך קבצי YAML או JSON (שוב, כל אחד והעדפותיו…), תוך שימוש במשאבים נוספים הקיימים כמו קטלוג שרותים שהוקם לחברה פנימית (דבר שלא קיים ב-Kubernetes). יתרון נוסף שיחשף בקרוב (לגבי Kubernetes ו-OpenShift) זה שבגירסה הבאה תוכלו להריץ קונטיינרים גם על Windows וגם על לינוקס על מערכת Kubernetes/OpenShift אחת.

אני מניח שאחת השאלות שישלחו אליי לאחר פוסט זה תהיה לגבי תיעוד, וכאן ההמלצה שלי היא לקחת תיעוד נפרד לכל דבר. גם על Kuberentes וגם על Docker יש תיעוד מעולה של חברת Oreilly. אם אתם רוצים ללמוד על OpenShift – התיעוד הרשמי הוא די טוב – רק אם למדתם טוב את 2 הדברים שציינתי, אחרת התיעוד שקיים לא יעזור לכם הרבה (מנסיון! מה לעשות שכשזה מגיע לתיעוד טוב, תמצאו 2 חברות שעושות טוב את העבודה: IBM ו-מיקרוסופט).

לסיכום: אם אתה רוצה להיות איש Devops, אז אתה צריך ללמוד את הדברים הללו אתמול. אם אתה לומד שפת תכנות כלשהי, הכרת קונטיינרים רק תעלה את ההערכה אליך בעת הראיון (אם תזכיר כמובן את הידע הזה בקורות החיים או בראיון..). אם אתה איש תשתיות IT, הכרה לפחות בסיסית של קונטיינרים יכולה לעזור לך בהסברה הפנימית בחברה אם לקחת/להטמיע/לרכוש תשתית קונטיינרים זו או אחרת.

חג שבועות שמח לכולם 🙂

על תשתית קונטיינרים לחברות מסחריות

גילוי נאות
"חץ ביז" הינו עסק שמוכר שרותי אינטגרציה ויעוץ למספר מוצרים לתשתית קונטיינרים
מערכות קונטיינרים בפלטפורמות שונות (קרדיט: Wikibon)

יותר ויותר חברות שומעות כיום את המושג "קונטיינרים" ואותם עסקים וחברות גדולות, בין אם הם בנקים, תעשיה פיננסית, בטחונית, רפואית ועוד – מעוניינות לשלב את טכנולוגיות הקונטיינרים, אבל כל מי שבתחום יכול לאמר לכם שהתחרות גדולה ויש מספר חברות שמציעות פתרונות שונים כולל רד-האט, סוזה, Docker (החברה), ועוד, והאמת – גם לאנשים מקצועיים די קשה להחליט מה לקחת, ומשווקים שונים מנסים לדחוף הצעות שונות לחברות. איך אמר לי היום מישהו בכיר בחברה גדולה: "חץ, השקענו מיליונים ב-ESXI, אין מצב שניפטר מזה!"

אז אולי נתחיל בדבר הכי בסיסי: תשתית הוירטואליזציה אינה מתייתרת בגלל הכנסת קונטיינרים, אלא להיפך – תשתית הקונטיינרים משתמשת בפתרונות וירטואליזציה (ולא חשוב איזה פתרון וירטואליזציה יש לך!) כדי להריץ קונטיינרים. אפשר כמובן להתקין מערכת הפעלה על הברזל עצמו כמו Red Hat Atomic (או הגירסה החינמית מבוססת CentOS) ולהתקין עליה קונטיינרים, אבל אז בעצם .. איך תנהל את השרתים? מערכת Atomic לא מאפשרת להתקין תוכנות נוספות על הברזל עצמו אלא אך ורק להריץ קונטיינרים, לכן בד"כ הדבר המומלץ הוא להשתמש במערכת לניהול וירטואליזציה, ויצירת מכונות VM שעליהן ירוץ פתרון הקונטיינרים.

בנוסף, פתרון של קונטיינרים עוזר לנצל בצורה טובה יותר את התשתיות שלכם. עשו נסיון פשוט: הקימו VM לינוקס עם 2 או 4 ליבות וכמות זכרון מספקת והתקינו עליו אפליקציה חשובה לכם. הריצו את ה-VM והאפליקציה ומדדו את ניצול הליבות. אם אתם רואים שניצול הליבות אינו מלא, אז אפליקציה כזו יכולה להיות מועמדת מעולה להרצה בקונטיינר, שם תוכלו להריץ אותה מספר פעמים עם אותם משאבים (כאשר אתם מקבלים "על הדרך" Load Balancing, High Availability מפלטפורמת הקונטיינרים) . אפשר גם להריץ אותה עם משאבים נמוכים יותר אם אינכם רוצים שרידות.

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

עתה נחלק ל-2 את החברות בארץ: יש כאלו שקוד פתוח זה "בעורקים" שלהם – יש להם צוותים שמכירים לינוקס מאוד לעומק, נסיון עשיר ב-Python ו-Go והם יכולים לקמפל לינוקס קרנל בין פיהוק למשנהו ואם יש בעיה בתוכנת קוד פתוח – מישהו בצוות יכול לחטט ולתקן. לאותן חברות שמחפשות פתרון קונטיינרים מקיף אני פשוט ממליץ ללכת על OpenShift Origin על תשתית וירטואליזציה ולהתחיל להשתמש. כל מה שאתם צריכים בשביל להריץ קונטיינרים, להקים, לבנות, Load balancing, HA וכו' וכו' – הכל כבר שם. תורידו מה-GIT ותתקינו ואין לכם צורך לשלם על כלום.

ב-95% מהמקרים האחרים – חברות בד"כ יעדיפו מוצר מסחרי עם תמיכה מלאה של היצרן, עדכונים מהיצרן וכו' וכאן בישראל נמכרים 2 מוצרים: Docker Datacenter שנמכר ע"י מטריקס ו-OpenShift שנמכר ע"י העסק שלי (אם כי, לשם הגילוי נאות וה"פרסומת", העסק שלי אינו היחיד שמוכר אותו, רק שכאן תקבלו משהו .. טיפה יותר מקצועי. הדגמות וידאו על Open Shift, אגב, בקרוב יופיעו בערוץ יוטיוב של חץ ביז).

מכיוון שאינני מרוויח רווחים גדולים ממכירות מוצרים, אין לי בעיה להיות הגון ולהמליץ אלו מהמוצרים לסיטואציות שונות:

  • אם אתם חושבים להקים מכמות של כמה מכונות בודדות (VM או פיזי) ועד כמה עשרות כאלו (הם נקראים Nodes) – אז מבחינת תמחור, ה-Docker Datacenter זול בהרבה מהפתרון עם OpenShift. בנוסף, אם מערכת ההפעלה העיקרית שלכם היא Windows והקונטיינרים שלכם יריצו קוד שרץ על מערכות מיקרוסופט – Docker Datacenter הוא הפתרון היחידי כרגע המתאים לפלטפורמות מיקרוסופט.
  • אם לעומת זאת אתם מתכננים על מאות Nodes ומעלה – הפתרון של OpenShift שווה יותר (וזול יותר)
  • אם אתם מעוניינים להקים תשתית חדשה לגמרי שתהיה נפרדת מתשתית הוירטואליזציה הנוכחית שלכם ושאותה תשתית חדשה תריץ קונטיינרים – אז אני ממליץ לרכוש את ה-OpenStack החדש (שם קוד: Magnum) שדואגת גם לתשתית כולה (Compute, Network, Storage, Authentication, Images וכו') וגם להרצת קונטיינרים, בניה, LB, HA וכו'. גם רד-האט וגם SuSE ישראל מוכרים את OpenStack Magnum. אינני יכול לפרסם מחירים של אף מוצר אבל מה שאני כן יכול לרמוז – זה שכדאי להתעניין אצל 2 הספקים במחירים. התחרות רצחנית!

כדאי לזכור משהו חשוב: אין מעבר קל בין Docker Datacenter ל-OpenShift. שתיהן אמנם משתמשות ב-Dockerfile כדי להרים קונטיינרים מבוססי Docker, אולם כל המערכות "מסביב" הינן שונות לחלוטין. ב-Docker Datacenter משתמשים ב-Docker Swarm ואילו ב-OpenShift משתמשים ב-Kubernetes. אפשר לייצא ולייבא קונטיינרים דרך סקריפטים אבל מנסיון – זה לא כיף גדול וזה די מורכב.

לסיכום: למעט מכונות VM שמצריכות חיבור לציוד פיזי יעודי (כרטיסים מסויימים וכו'), אפשר להעביר את רוב הדברים שרצים על VM לרוץ על קונטיינרים (כשמדובר על VM שמריץ לינוקס), קל מאוד לשכפל קונטיינרים ובתוך אותן פלטפורמות השרידות, עמידה בדרישות ובחיבוריות מצד גולשים – כבר כלולה. גם מבחינת אורך חיים של הקונטיינרים החיים קלים. אין עדכונים, יש בניה מחדש של קונטיינרים והרצתם עם העדכונים שכבר מותקנים. בישראל יש 2 מוצרים גדולים וידועים שנמכרים ומקבלים תמיכה פה בארץ וכדאי לשקול את היתרונות והחסרונות של כל אחד לפני רכישה.

תכירו את Open Shift

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

אם נסתכל במצב כיום ב-Corporate, ישנם דרישות ל-VM נוספים כל הזמן. מתכנתים רוצים לנסות דברים, להריץ מספר גרסאות במקביל, לקבל פידבק ממשתמשים, או שצריכים להוסיף VM כדי לעמוד בעומסים. ב-Corporate, בניגוד לחברות קטנות וסטארט-אפים, תהליך הקמת ה-VM הוא תהליך לא קצר. המשתמש מגיש את דרישותיו לגבי ה-VM, ה-IT לא מוכן תמיד לאשר, צוות הנטוורקינג אולי לא אוהב את ההגדרות (במיוחד אם הדורש מבקש … סוויץ' וירטואלי חדש במערכת הוירטואליזציה.. מנסיון). גם למחלקת אבטחת מידע יש מה לאמר פר VM, כך שתהליך שטכנית אמור לקחת דקות ספורות – לוקח ימים, ולפעמים שבועות ומעלה.

אם נסתכל בתשתית ה-Corporate במחלקות הפיתוח לדוגמא, נמצא במקרים שרת SCM כמו GIT (או SVN, מרקיוריאל ואפילו רחמנא ליצלן .. CVS וכו'), אלו שהחלו להיכנס לעולם ה-CI/CD הקימו בוודאי שרת Jenkins ואולי כמה Slaves, אם החברה מפתחת ב-JAVA אז יש בוודאי איזה שרת Nexus, בנוסף ישנם מספר שרתים שמריצים אפליקציות Web, שרת Apache או NGINX (או IIS). הכל רץ טוב ויפה (כשזה רץ…), אבל כשצריך להגדיל את התשתית, מישהו יצטרך לחפש כדורים נגד כאבי ראש עם כל הבירוקרטיה שיש ב-Corporate.

עם Open Shift הדברים שונים. Open Shift (שאגב, היא מערכת PAAS לכל דבר ועניין!) משתמשת בקונטיינרים כדי להריץ את מה שאתה צריך כשכל דבר רץ בקונטיינר נפרד. יש לך אפליקציה ב-PHP שצריכה לכתוב ל-MySQL? כמה קליקים ויש לך 2 קונטיינרים, תוסיף Route ושתיהם מדברים אחד עם השני, שתיהם לא צריכים לשם טסטים לדוגמא להיות עם יותר מ-1 ג'יגה זכרון (סה"כ ל-2 הקונטיינרים) ושתיהם יחד לא יצטרכו יותר מליבה אחת של המעבד בשרת וזה ירוץ מעולה תחת POD יחיד (POD זו ההגדרה של מספר קונטיינרים שרצים בקבוצה). רוצים לגדול עם האפליקציית PHP? שתי קליקים עם העכבר בממשק ה-WEB ותוך שניות ספורות יש עוד קונטיינרים שמוכנים לקבל גולשים, ולא – אתה לא צריך לשבור את הראש על Routing, על Load Balancing וכו' – בתוך Open Shift יש את Kubernetes שעושה את העבודה לבד ברקע. כך גם אם קונטיינר מסוים יפול, המערכת תרים מיידית קונטיינר נוסף תוך שניות ספורות (במקום לחכות כמה דקות עד שיקום VM עם כל התהליכים שהוא צריך לאתחל) והמערכת יכולה להמשיך לתת שרות.

מערכת Open Shift באה בעצם להקל על צוותי ה-IT, אבטחת המידע, נטוורקינג וכו'. עם Open Shift מגדירים יוזרים למערכת שנכנסים לפורטל כלשהו, וכל יוזר מקבל "קיצבה" מסויימת של משאבים ובאותם משאבים הוא יכול להרים קונטיינרים עם הדברים שהוא צריך. הוא לא יכול להרים כל דבר שהוא רוצה, יש קטלוג מסודר של אפליקציות או Frameworks שהוא יכול להשתמש בהם (ואם צריך להרחיב – זו אחריותו של מנהל ה-Open Shift).

אז איך בעצם זה עובד? הנה תהליך עבודה פשוט לדוגמא:

מפתח כותב קוד ובודק אותו מקומית. לאחר שהוא מרוצה מהקוד, הוא "דוחף" אותו ל-SCM של החברה ואז מערכת ה-CI/CD נכנסת לפעולה (אם זה פרויקט קיים), מקמפלת את הקוד, מריצה בדיקות או מה שמוגדר ב-Pipeline ולסיום היא פונה ל-Open Shift. ה-Open Shift לוקח את הקבצים הבינאריים (Artifacts לדוגמא) ובונה מהם יחד עם הדברים שצריך (סביבת ריצה וכו') קונטיינר והמערכת מפעילה את הקונטיינר. המפתח יכול לקבל הודעה במייל שהכל מוכן וכשהוא נכנס לפורטל של Open Shift, יש URL שלחיצה עליו תעביר את המפתח לאתר שהקונטיינר מריץ. עכשיו המפתח יכול להוסיף תכונות, לתקן וכו' – והכל חוזר מחדש. מפתחים בד"כ לא עובדים לבד – והמערכת תומכת בקבוצות כך שמפתחים יכולים לעבוד יחדיו על אותו פרויקט.

צריך להריץ Deployment בשיטות כמו Blue-Green או AB? שתי השיטות נתמכות.

אחרי שהקוד מוכן, נרצה להריץ אותו בפרודקשן. מה אז?

כאן מגיע יתרון גדול של Open Shift. לא משנה איזו תשתית וירטואליזציה יש לך, תהיה הפופולרית ביותר או אזוטרית ביותר, בין אם זה מקומית או בענן פרטי או ציבורי – Open Shift תרוץ. כל מה שאתה צריך זה מספר מכונות VM (או ברזלים פיזיים) ו-Subnet כתובות פרטי וציבורי. מה שנשאר לך לעשות זה להקים Open Shift במכונה אחת (או כאשכול), "לשדך" את שאר מכונות ה-VM שיריצו מערכת Atomic Host (זו גירסת לינוקס מאוד מצומצמת שנועדה להריץ קונטיינרים) ומשם לקמפל את הגירסה היציבה ולהריץ אותה עם רפליקציה. מערכת ה-Kubernetes הפנימית תדע להפיץ את הקונטיינרים בין מכונות ה-VM (וכן, יש גם Auto Scaling ו-HA) ואם אתם מריצים את זה בענן, שרות ה-Load Balancer ידע להעביר את התעבורה ל-IP חיצוני (לא צריך ציוד יעודי יותר בתוך החברה שיעשה LB). קונטיינר נופל? VM נופל? המערכת תדע להתאושש לבד.

ומה עם אבטחת מידע? כאן דווקא החיים יותר קלים. עם VM כשיש אבטחת מידע, אתה צריך לעבור מכונה מכונה ולהתקין את עדכוני האבטחה. תארו לכם שיש לכם מאות (או אלפי) VM ואתם יכולים לדמיין לבד את הכאב ראש הכרוך בכך. עם קונטיינרים לעומת זאת, בין אם יש חור אבטחה בקוד שלכם או באחת מהחבילות שהקונטיינר משתמש, כל מה שתצטרכו לעשות זה Rebuild לקונטיינר ואם יש לכם רפליקציה של הקונטיינר, המערכת תוריד כל פעם קונטיינר ותשאיר את השאר רצים (תוך עדכון ה-Load Balancer) כך שמבחינת הגולשים המערכת תהיה זמינה וכך כל הקונטיינרים יוחלפו בגרסאות מעודכנות (בזמן ה-Build המערכת מורידה את הגרסאות של החלקים השונים עם התיקוני אבטחה אוטומטית). כך שכשזה מגיע לבעיית אבטחה, כל התהליך לוקח דקות ולא שעות או ימים!

עד כה כל הטכנולוגיה שדיברתי עליה מדברת על הרצת דברים שכתובים ללינוקס, אבל מה עם אלו שכותבים ב-DotNet? ובכן, מאז שמיקרוסופט ורד-האט חתמו על הסכמי שת"פ, האהבה פורחת ביניהם וכיום ניתן לקחת אפליקציות שכתובות ב- #C עם DotNet ולבנות אותן על לינוקס ולהרים קונטיינר כזה. בשלב זה טכנולוגיות הקונטיינרים של מיקרוסופט עדיין לא עובדת ישירות טוב עם Open Shift אבל אפשר לבנות להריץ אפליקציות כפי שציינתי. אגב, ניתן לשלוט על Open Shift בעזרת ה-CLI גם מתוך Windows (כל מה שצריך זה להתקין Ruby, Git ולהריץ מספר קטן של פקודות).

להלן הדגמה של ASP שרץ עם Open Shift:

הוידאו הבא ידגים איך מקימים מערכת CI/CD מלאה יחד עם Open Shift:

ומה לגבי הטמעת מערכת כזו בחברה?

גם כאן, כמו ב-CloudForms/ManageIQ ישנם מספר גרסאות:

  • יש גירסה שרצה על הענן של רד-האט ומשלמים Pay As you Go, בין אם ב-VM או בברזלים נפרדים.
  • יש גירסת קוד פתוח (גירסה שמהנדסי רד-האט מפתחים, יכולים לצוץ באגים!) שנקראת Open Shift Origin.
  • וישנה גירסת ה-Open Shift Enterprise בתשלום עם תמיכה לשנה או 3 שנים במסלולים שונים.

מבחינת הטמעה וקאסטומיזציה – זה מאוד תלוי בחברה ובדרישות. הקוד של Open Shift כתוב ב-GO.

מבחינת הדרכה – מכיוון שמדובר במוצר שיש לו אינטרקציה ישירות עם מפתחים, QA, IT ועוד – יש צורך בהדרכות (הדרכה בסיסית שיכולה לקחת חצי יום – יום והדרכה שלוקחת קצת יותר ל-IT ולמי שינהל את המערכת).

לסיכום: קונטיינרים יכולים לחסוך הקמת VM מרובים ותחזוקתם. מערכת Open Shift יכולה להקל בצורה רצינית על כל תהליך הקמת סביבות הרצת טסטים, פרודקשן, ועוד. בכל מה שקשור למעבר לענן, Open Shift מקלה על בחירת ספקי ענן ובמקביל מגדילה את המבחר ספקים (כך לדוגמא אפשר להשתמש בספק כמו Digital Ocean עם מכונות במחירים זולים בהרבה מספקי ענן ציבורי ובמקרים רבים החבילה תכלול מספיק תעבורה כך שלא תצטרכו לשלם על כך בנוסף!)

גילוי נאות
הטמעות והדרכות לגבי מוצר זה מסופקים ע"י "חץ ביז"