קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

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

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

השוואה: PKS מול OpenShift

יצא לי לשוחח עם לא מעט חברות שרוצות להשתמש בקונטיינרים. רבים כבר התחילו ממזמן להשתמש ב-Docker (הערה: לא הגיע הזמן להכיר ולהשתמש ב-cri-o?) והם החלו להשתמש ב-Docker-compose להרמת מספר קונטיינרים במכה אחת. חלקם מתחילים להשתמש בשרותים המנוהלים לקונטיינרים בעננים הציבוריים וחלקם רוצים פתרון On Prem ומטבע הדברים הם מתחילים לקרוא על Kubernetes וכשהם מתחילים להבין כמה הוא מורכב לתפעול (ומגירסה לגירסה זה נהיה יותר ויותר מורכב) – הם מבקשים המלצות על פתרון קל יותר להקים ולנהל אשכול Kubernetes (ובקיצור בשמו החביב: K8S).

רוב מוחלט של החברות הבינוניות והגדולות משתמשות ב-VMWare (מי שמשתמש ב-Hyper-V וירצה פתרון קל להתקנה וניהול ל-K8S – בהצלחה עם זה) ומטבע הדברים הם מעדיפים משהו מחברה גדולה וידועה כמו VMWare, ששמחה מאוד למכור להם את PKS. המוצר עצמו נמכר בשתי תמחורים שונים – פר POD (כאשר POD הוא מעין "קבוצה" כאשר כל POD מכיל קונטיינר אחד או יותר, ברוב המקרים יריצו קונטיינר עם אפליקציה ועוד קונטיינרים שמכילים אפליקציות נסמכות תחת POD אחד ואז יש גם תקשורת בין הקונטיינרים בקבוצה) או פר ליבות. זה מתחיל ב-50 PODS או ליבות. (המלצה: לא לרכוש פר POD. בכל ליבה אפשר להריץ עשרות PODs).

המתחרה העיקרי והיותר גדול ומיועד ל-Enterprise להרצת Kubernetes היא מערכת Openshift. גם היא תומכת באופן טבעי ומלא ב-VMWare (כן, כולל תמיכה ב-NSX-T), רק שבניגוד ל-PKS, היא לא מיועדת רק להקמה וניהול של Kubernetes במובן הסיסטמטי, אלא היא יותר מיועד לכל השרשרת – מרמת ההנהלה, אנשי אבטחת מידע, ומפתחים. ב-PKS אם אני רוצה להקים אפליקציה, אני צריך להשתמש ב-Cloud Foundry (או דרך ה-cli ב-kubectl), צריך במקרים רבים לכתוב קבצי YAML (ימח שמו וזכרו עם כל הקטע של רווחים!) שמצריכים ידע מספק ב-K8S. עם Openshift – יש לך Template (שתמיד אפשר לכתוב נוספים) והמתכנת עושה הכל דרך ה-Web UI. יש קטלוג מובנה שמאפשר להתחבר לאינטרנט ולהוריד אוטומטית templates נוספים והקמה של אפליקציות נוספות בכמה קליקים, יש אבטחת מידע הרבה יותר רצינית מ-PKS (בגלל זה רוב הקונטיינרים הזמינים לציבור לא ירוצו על Openshift אלא אם משנים הגדרת אבטחה שבחברה עלולים לפטר אותך אם תשנה אותה), יש גרפים וניטור מובנה, קל מאוד לשייך בין אפליקציה לשרות (נניח אפליקציית JAVA לקונטיינר אחר שמריץ MySQL – משתמשים ב-BIND בתפריט ותוך שניות ספורות המערכת תבנה את הכל) ויש עוד תוספות רבות שכלל לא קיימות ב-PKS. בקיצור, מי שיקים מערכת Openshift (קראו בהמשך על כך למי שמעוניין להתנסות אישית במחיר יקר של 0 שקלים) ויקים מערכת PKS, יראה את ההבדלים מהר מאוד. אגב, אחת האפשרויות שכיום אין ב-PKS ומאוד חשובה כשרוצים להוסיף ולהוריד מכונות וירטואליות המריצות קונטיינרים – כלל לא קיימת ב-PKS, אך קיימת בגירסת Openshift האחרונה.

וכאן אני מגיע להמלצה לא פופולרית שאני ממליץ: אל תרכשו PKS.

לא, זה לא קשור למחיר. מי שישווה בין Openshift ל-PKS יראה כי המחיר של Openshift ל-On Premise יותר יקר מ-PKS (בחלק מהמקרים, תלוי בחישובי ליבות, כמויות וכו')

הבעיה קשורה יותר ל-VMWare ולזמן הנוכחי. VMWare מציעה את PKS (גרסאות Essential, Enterprise) אבל אותה חברה גם מציעה את Tanzu Kubernetes Grid. היא מדברת על ניהול אשכולות של Kubernetes עם Tanzu Mission Control – אל תחפשו לרכוש או להוריד, זה מוצר של חברת Heptio (ש-VMWare רכשה) שעושים בו שינויים והוא כרגע בבטא ללקוחות VMware ולא זמין להורדה. יש גם את עניין ה-Health אשכול ה-K8S שלך והחלק הזה ממוצר וקוד מחברות ש-VMWare רכשה: Wavefront ו-CloudHealth.

בקיצור, VMWare מכינה איזה משהו גדול שמשולב מקוד ממקורות שונים שאמור לתת לך מענה מבחינת הקמת וניהול אשכולות K8S שונים הן מקומית והן בענן, אבל עד שזה יהיה מוכן ויציב – יקח זמן. כ-Enterprise, היציבות מאוד חשובה והדבר האחרון שאתם רוצים לעשות זה לעבור למשהו אחר השנה או שנה הבאה ולך תדע כמה זה תואם אחורה והאם המיגרציה תעבוד חלק…

אם כל מה שאתה מחפש זה דרך קלה ונוחה להקים אשכול K8S ואתה רוצה גם תמיכה מסחרית, אבל אתה לא רוצה את Openshift ואת כל הערך הנוסף שהוא נותן לכל הצוותים, אז פשוט תרכוש או תוריד את Rancher (כאן נמצאת גירסת הקוד הפתוח), החברה כבר קיימת מספר שנים, המוצר יציב ונותן את מה שהוא מבטיח, והמחיר יותר זול מ-PKS.

לאלו שכן רוצים לנסות את Openshift על הדסקטופ שלהם (לא על ESXI או פתרון וירטואליזציה מרכזי, כל עוד יש לך 32 ג'יגהבייט זכרון, הגירסה המצומצמת שניתנת להורדה תופסת 16 ג'יגהבייט זכרון, לגמרי), מוזמנים לגלוש לקישור הבא. תצטרכו להירשם ל-רד-האט כדי להוריד "קוד סודי" ולהדביק אותו בזמן ההתקנה. האפליקציה נקראת Code Ready Containers והיא יכולה לרוץ על לינוקס, מק ו-Windows. המערכת משתמשת בוירטואליזציה במחשב המקומי כך שב-Windows היא תפעיל את אופציית Hyper-V. טיפ קטן: אם אתם מחוברים ל-Active Directory, תתחברו למכונה שלכם עם שם משתמש מקומי. באג ידוע.

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

קונטיינרים, אבטחת מידע, ושימוש בוירטואליזציה

אני רוצה לחזור לימים שמיקרוסופט שחררו את Windows 95. הנה מערכת הפעלה חדשה, טענה מיקרוסופט, שיכולה להריץ ריבוי משימות מבלי שאפליקציה אחת תגרום לקריסת שאר האפליקציות שרצות! כולנו כמובן יודעים את האמת הפשוטה שאפליקציות בהחלט גרמו למערכת ההפעלה לקרוס כמו כלום, אפליקציות "בלעו" זכרון וניהול הזכרון היה די כושל, בוודאי כשמשווים זאת למערכות היותר מתקדמות שמיקרוסופט הוציאו שנים לאחר מכן כמו ה-NT 4.0 וה-2000 וכו'. הסיבה המרכזית לכך היתה כמובן כל הסביבה "מתחת" – DOS, שלא היתה ממש בנויה טוב לדברים כאלו, וה-Protected Mode שאינטל הוסיפה החל במעבדי i386 לא ממש עזר הרבה (אם כי לא באשמת אינטל).

שנת 2018, חברות רבות עוברות להשתמש בקונטיינרים אבל ישנה אי נוחות מבחינת אבטחת מידע לגבי קונטיינרים. למי שלא מכיר – הסיבה שקונטיינרים רצים מהר היא בגלל שהקונטיינר אינו מכיל Kernel או דרייברים שמתממשקים ל-Kernel. קונטיינרים מקבלים שרותים מ-Kernel יחיד שרץ על אותה מכונה (פיזית או וירטואלית) וכך כל מה שיש בקונטיינרים הם ספריות ואפליקציה שצריכה לרוץ (ולצערי רבים עדיין בונים קונטיינרים שמכילים מספר אפלקציות/שרותים במקום להריץ רק אפליקציה אחת. זה "מתנקם" אחר כך באנשי Devops שעוברים להשתמש ב-Kubernetes).

מדוע אי נוחות מבחינת אבטחת מידע? כי הקונטיינר הוא לא יותר מאשר Process, שלא-כל-כך קשה "לצאת" ממנו אל ה-Host ומשם לחולל נזקים. רד-האט עם מערכת ה-OpenShift שלה לא מאפשרת (בברירת מחדל) לדוגמא לקונטיינרים לרוץ כ-root או להריץ בתוכה אפליקציות כ-root, וכל המערכת רצה עם SELinux מופעל (כ-Enforcing), כך שאם אתה מבטל SELinux, אין OpenShift. בפתרונות אחרים מבוססים Kubernetes חוסמים תקשורת בין ה-Pods, אבל זה לא תמיד יכול לסייע – במיוחד אם המערכת חשופה החוצה ומריצים מאות pods שמכילים Apache או NGINX לדוגמא.

לשם כך נצטרך קודם להיפטר מ-Docker.

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

במקום Docker, תכירו את CRI-O. (מבטאים "קריאו")

CRI-O זו מערכת חלופית ל-Docker שיודעת לבצע מה ש-Docker מבצע (ולכן היא תואמת ל-Docker), רק שהיא צורכת פחות משאבים, ואחד הדברים המעולים שיש בה הוא שניתן בעצם להגדיר קונטיינרים שאנחנו בוטחים בהם (Trusted) וקונטיינרים שאיננו בוטחים בהם (Untrusted) ולהריץ את 2 הסוגים במקביל, כאשר קונטיינרים שאיננו בוטחים בהם, ירוצו דרך מערכת QEMU כמכונה וירטואלית (sandbox) עם kernel קטן וכל השרותים הנחוצים להרצת קונטיינר. במילים אחרות – בשינוי קובץ YAML נוכל בקלות להקים את הקונטיינרים בצורה מופרדת או בצורה רגילה.

CRI-O מתחבר ל-Kubernetes בצורה חלקה ואינו מצריך הטמעת טלאים, וכמו כן CRI-O משתמש בשיטה של אינטל (שנקראה בעבר Clear Containers וכיום Kata Containers) כדי להריץ קונטיינרים בצורה מבודדת, אך שעדיין מאפשרת להשתלב בתוך אותם Namespaces לדוגמא.

להלן הדגמת וידאו קטנה איך עם CRI-O בשילוב Kubernetes מאפשר להריץ קונטיינרים שאנחנו מגדירים כ-Trusted ואיך משלבים קונטיינרים שאנחנו מגדירים כ-Untrusted ורצים בתוך סשן VM (לחצו מצד ימין למטה על האייקון עם החצים כדי לצפות בכל הטרמינל, הנגן לא יודע לבצע Scale לוורדפרס):

כפי שאנחנו יכולים לראות, השילוב רץ יפה מאוד.

לאלו המעוניינים לנסות את הדברים הללו, חשוב לשים לב לנקודות הבאות:

  • כרגע, לא ניתן להריץ את הדברים בענן ציבורי בתוך Instance רגיל אלא אך ורק בתוך Bare Metal Instances. כמו כן לא ניתן להשתמש ב-CRI-O בתוך שרותים כמו ECS.
  • אם אתם רוצים להריץ זאת בתשתית מקומית שלכם, ואתם מריצים Kubernetes על מכונות VM, יש להגדיר את אותן מכונות VM עם Nested Virtualization על מנת להריץ קונטיינרים Untrusted.
  • אם אתם רוצים לנסות את הדברים על מכונת הדסקטופ שלכם עם Minikube, יש להפעיל את minikube עם ההוראות כאן.
  • אם אתם משתמשים במערכת OpenShift (גירסה 3.11 ומעלה), ניתן להוסיף תמיכת CRI-O בנוסף לתמיכת Docker למערכת. ההוראות – כאן.
  • אם אתם משתמשים ב-CAAS של SuSE, בגירסה 3 ומעלה ניתן לבחור בין Docker ל-CRI-O. עוד פרטים ניתן לקרוא כאן.

לסיכום: CRI-O מאפשר לנו להריץ בצורה קלה ומאובטחת קונטיינרים שלא אנחנו בנינו ושהורדנו ממקורות אחרים ובמקביל הוא מאפשר לנו להריץ קונטיינרים שאנו בוטחים בהם (ושאנחנו בנינו) כפי שהרצנו עד היום, רק מבלי להשתמש ב-Docker עצמו ובמשאבים הגדולים שהוא צורך.

כמה מילים על מעבדי Power

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

אבל יש עוד אופציה שחלק קטן מהאנשים מכירים – אלו מעבדי ה-Power של IBM, ספציפית מעבדי Power8 ו-Power9.

קצת היסטוריה: אפל, IBM ומוטורולה החליטו אי שם בשנות ה-90 להתחרות באינטל ולהוציא מעבדים משל עצמם תחת השם PowerPC. מוטורולה הוציאה את המעבדים, אפל השתמשה בהם בשמחה ו-IBM גם השתמשו בהם בחלק מהשרתים והיה אפילו מחשב ThinkPad יחיד שיצא עם מעבד PowerPC שהריץ OS/2 (וזמן קצת לאחר מכן שיווקו הופסק כי לא היתה לו דרישה).

עם הזמן אפל נטשה את ה-PowerPC, ומוטורולה המשיכו ליצור למשך זמן מה מעבדים כאלו לשווקים נישתיים כמו Embedded. ב-IBM הבינו שאם הם רוצים להתחרות באינטל, הם צריכים לעבוד ולפתח את המעבדים בעצמם וכך IBM שחררה במשך השנים מספר מעבדי Power שונים. בהתחלה המעבדים הללו היו עמוסים בתקנים קנייניים שלא תמכו טוב בסטנדרטים כמו זכרון ECC רגיל, אך החל מ-2015 ב-IBM הבינו שכדאי לרדת מהעניין ולהשתמש בחומרה סטנדרטית, וכך מעבדי ה-Power8 ו-Power9 החלו לתמוך בזכרון רגיל לשרתים, תקן PCIe לכרטיסים (ב-Power9 התקן הוא PCIe 4.0 שכרגע לא נמצא באף שרת מבוסס מעבדי אינטל, זה רק יחל להופיע בשנה שנתיים הבאות, אם כי רוב הסיכויים שהחברות יקפצו ישר ל-PCIe 5.0) ועוד.

מבחינת ארכיטקטורת מעבד, הארכיטקטורה של Power9 היא מורכבת ולא אכנס לפרטי פרטים בפוסט זה (למעוניינים, דף ה-WIKI הזה מסביר יותר), אך נאמר כך: במעבדים כמו EPYC או Xeon, אנחנו רגילים למצוא Cores ו-Threads, כאשר הכלל הקבוע הוא שכל 2 Threads תופסים בעצם ליבה אחת. ב-Power9 זה שונה: ה-Threads נקראים Slices ועל כל Core ניתן לפנות ל-שמונה Slices. ישנם 2 סוגי מעבדי Power9, ה-SMT4 ו-SMT8 כאשר SMT4 מכיל 12 slices ו-SMT8 מכיל 24 slices. מבחינת ליבות, המעבד קיים במספר גרסאות, החל מ-4 ליבות ועד 22 ליבות.

המעבדים הללו יכולים להיות ב-2 תצורות: אחת בשיטה הידועה והפופולרית של Scale Up (נקראת: SU) והשניה היא Scale OUT (נקראת: SO). מערכות שמשתמשות ב-Power9 SU לדוגמא הינן מערכות עם 4 מעבדים ואילו מערכות SO הינן מערכות עם 2 מעבדים. מערכות SU כוללות תמיכה בזכרון ישיר למעבד (Directly Attached) מסוג DDR4 ואילו מערכות SO משתמשות בזכרון כזכרון חוצץ. מהירות הגישה לזכרון ב-SO היא עד 120 ג'יגהבייט לשניה ואילו ב-SU היא 230 ג'יגהבייט לשניה (הרבה יותר מכל מעבד מבוסס X86-64).

אחד היתרונות הגדולים של מעבדי Power9 היא קישוריות מאוד גבוהה לציודים הסובבים למעבד. במידה ומשתמשים ב-GPU של nVidia או ציודים אחרים, ב-IBM משתמשים בדבר שנקרא Bluelink ובעברית פשוטה: כל התקשורת בתוך המכונה עצמה היא הרבה יותר מהירה מהמעבדים המתחרים.

IBM משווקים מספר מכונות, כאשר חלק מהמכונות מגיעות עם מערכת קניינית של IBM ומתוכה בעזרת תוכנת PowerVM אפשר לבנות מכונות VM שמריצות לינוקס ויש ל-IBM גם מכונות שמריצות ישר לינוקס עוד מה-Boot (כמו L922, S914,AC922 ועוד). למעוניינים (יש כאלו?) אפשר להריץ על המערכות הללו גם .. AIX. מבחינת מערכות לינוקס הקיימות ל-Power9, המבחר הוא: SLE של SuSE ו-RHEL של רד-האט. ניתן להריץ גם גירסת Debian על Power9 אבל רק מה"עץ" של ה-Unstable עם מינימום Kernel 4.15 ומעלה.
אה, ואי אפשר להקים מכונות VM עם Windows על מכונות כאלו. אין תאימות ל-X86-64..

אז למי מיועדות המערכות הללו?

הקהל הראשון שירצה לשמוע על המערכות הללו הן חברות שמעוניינות לפתח AI או Deep Learning. בכל מכונה כזו ניתן להכניס 4-6 כרטיסי GPU מסוג Tesla של nVidia, ואם נבדוק את הביצועים של GPU כזה על מערכות Xeon בהשוואה למערכות Power9, נקבל שהביצועים של Power9 מבחינת קישוריות הם פי 7-10 יותר גבוהים. אם נתרגם זאת לתוכנות המקובלות, אז TensorFlow רץ פי 2.3 יותר מהר, Caffe פי 3.7 יותר מהר, ו-Chainer פי 3.8 יותר מהר על מערכות Power9 בהשוואה למעבדי Xeon החדשים ביותר.

הקהל האחר שגם יעניין אותו המכונות הללו הם חברות שרוצות להריץ קונטיינרים והרבה. כאשר כל מעבד תומך בעד 2 טרהבייט זכרון ויש לך 96 Threads/Slices, אתה יכול להריץ המון קונטיינרים, גדולים כקטנים – על מכונה אחת (ואין שום בעיה לעבוד עם מס' מכונות). IBM מציעים את תוכנת ה-Cloud Private שמיועדת לניהול קונטיינרים והיא רצה על בסיס שכולם מכירים – Kubernetes. אם כבר מדברים על קונטיינרים – כלים ומתודות של CI/CD עובדים יפה מאוד על מערכות Power9.

קהל נוסף שדווקא כן מכיר את ה-Power9 הם אלו שרוצים להקים HPC גדול. ל-IBM כבר יש פרויקטים של HPC שרצים כבר עם Scale גדול כמו Summit, Sierra, MareNostrum 4.

כמו תמיד, יהיו מי שירצו לדעת מי משתמש במערכות כאלו – הרבה מאוד חברות בחו"ל, וחברה שאולי שמעתם עליה.. Google.

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

לסיכום: מערכות Power9 הן מפלצות עבודה לכל דבר ועניין והן נותנות תפוקה הרבה יותר גבוהה בהשוואה למערכות מבוססות Xeon/EPYC. הארכיטקטורה שונה, המאיצים שונים, המעבדים שונים, אבל אם אתם מחפשים את המהירות והביצועים הגבוהים – כדאי לדבר עם IBM ולקבל הדגמות ואולי כדאי שתשקלו לרכוש מכונות כאלו.

מעבר ל-CI/CD בחברות גדולות

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

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

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

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

  1. לבחור צוות שיעבור ל-CI/CD מתוך כל הצוותים שיש בחברה. כדאי שבצוות יהיו אנשים עם מוטביציה ועם ראש פתוח. בלי זה – המעבר יכשל, מבטיח לכם.
  2. להעדיף כלים מבוססי קוד פתוח או פתרונות מסחריים מבוססי קוד פתוח. כלים קנייניים הם מקור לצרות בעולם ה-CI/CD שמתפתח בקצב מהיר. לעומת זאת, כלים בקוד פתוח צריכים בד"כ הרצה של פקודת YUM או APT כדי לעדכן.
  3. האם בהזדמנות זו מכניסים פתרון קונטיינרים? (אפשר לבצע CI/CD ללא קונטיינרים) – אם כן, כדאי להחליט אם הולכים על פתרון מסחרי של Kubernetes (כמו CAAS של SuSE) או על OpenShift של רד-האט שהוא גם מבוסס Kubernetes אבל נותן הרבה הרבה יותר יכולות. (ישנם כמובן גם פתרונות אחרים אבל הם לא עונים לצרכים של Enterprise).
  4. פיתוח כ-Multi Platform – חשוב במיוחד לבנקים, חברות ביטוח וחברות פיננסיות. זה נחמד וטוב לפתח ל-Windows אבל אפשר בעזרת עבודה די קצרה לעבור ל-Multi Platform. עובדים ב-JAVA? מצוין, אפשר גם עם לינוקס, צריך בסה"כ לשנות מספר סקריפטים (אם כתבתם) כדי לעבוד בלינוקס. עובדים עם Dot Net? תכירו את Dot Net Core שמאפשר לכם עבודה עם Windows ולינוקס. היתרון של עבודה עם לינוקס הוא שמגוון רחב של כלים יהיה זמין לכם (במיוחד אם אתם עובדים עם קונטיינרים).
  5. טסטים טסטים טסטים … יש עדיין מקומות שמעסיקים אנשי QA. ברוב המקומות לעומת זאת, כבר אין חיה כזו מהסיבה הפשוטה שהיום פשוט כותבים טסטים שרצים במערכת כמו Jenkins המבצעים בדיקות Unit testing ועוד מספר סוגי טסטים על מנת לוודא שמה שמפותח – הוא יציב ועובד.

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

ועוד משהו אחד שרבים לא יאהבו שאני כותב זאת: החיה הזו בשם "איש Devops" זו המצאה שגויה של אנשים שלא מבינים מה זה Devops. הבה נסתכל על משהו פשוט בחברה גדולה: החברה מחליפה תוכנת גיבוי, תוכנת Code Repository, אולי כלי אוטומציה ועוד מספר דברים. האם אותה חברה צריכה פתאום שכיר נוסף? לא, כי צוות ה-IT אמור לדעת לתמוך בכלים. אפשר לקרוא למישהו מבחוץ שילמד ויתרגל את הצוות, אבל הצוות יכול בהחלט להמשיך ולתחזק את אותם כלים. אדרבא, הן אנשי ה-IT והן צוותי הפיתוח צריכים להכיר את הכלים (ברמות מסויימות כמובן, ה-IT ברמה של Sysadmin והשאר ברמה של Usage).

לסיכום: פרויקטים של CI/CD עם או בלי קונטיינרים לוקחים זמן להתממש ולהחליף מערכות קיימות. כדאי לשים את כל הדברים על השולחן כי תמיד דברים צצים שמחייבים עבודות נוספות מעבר להגירה על מנת להצליח בפרויקט. כדאי להתחיל עם צוות אחד עם אנשים בעלי ראש פתוח ומשם להמשיך.

דעה: על רכישת CoreOS ע"י רד-האט

[stextbox id='info' caption='הערה']הדברים הנכתבים כאן הינם דעתי האישית, אינני כותב מטעם Red Hat[/stextbox]

בימים האחרונים פורסמו באתרי טכנולוגיה שונים החדשות כי חברת רד-האט רכשה את חברת CoreOS. חברת CoreOS היתה מתחרה של רד-האט בכל הקשור למערכת לניהול Kubernetes (בשם Tectonic), ניהול Registry לקונטיינרים (Quay), וכמו כן את Container Linux (מערכת הפעלה מצומצמת להפעלת קונטיינרים) וכמובן את etcd שהוצאה כקוד פתוח ורבים (כולל רד-האט) משתמשים בו.

רד-האט (Red Hat) כידוע, היא החברה הכי גדולה בהפצת לינוקס ובמערכות מבוססות קוד פתוח ומטבע הדברים, כשהיא רוכשת חברות קטנות אחרות, יהיו כאלו שידאגו מה יהיה עם המוצרים שהם רכשו, מה עם תחרות וכו' וכו'. בפוסט זה אנסה להסביר מה הולך לקרות לדעתי בהתבסס על רכישות קודמות של רד-האט (כמו Qumranet, InkTank, Gluster ואחרים).

בניגוד לחברות מסחריות אחרות שקונות חברות טכנולוגיה שונות ואחרי שנה שנתיים קוברות את המוצרים שנרכשו, ברד-האט עובדים בצורה שקופה לחלוטין. אם ניקח לדוגמא את 3 החברות שהזכרתי לעיל, בחברת רד-האט עדיין ממשיכים לפתח את המוצרים בצורה פתוחה לחלוטין ובד"כ באתר GitHub, כך שכל אחד יכול להוריד גירסה ואם הוא מעוניין – לעשות Fork. כמובן שהמוצר המסחרי בסופו של דבר שונה במעט מהמוצר ב-GitHub (אם תסתכלו בכל המוצרים שרד-האט מוציאה ב-GitHub, אף אחד מהם אינו כולל סמלים של רד-האט עצמה, עקב עניינים של סימנים רשומים וכו') בכך שהקוד למוצר המסחרי כולל גם טלאים ותיקונים (שנמצאים ב-Master לאחר מכן) וכוללים תיעוד רציני למוצר.

אז לעניות דעתי הדברים הבאים הולכים להתרחש. כל השינויים לא הולכים לקרות מחר, אלא סביר להניח שלקראת סוף השנה או החל משנה הבאה:

  • אחד הדברים הראשונים שלדעתי הולכים להשתנות הוא דווקא בצד של רד-האט והוא מוצר ה-Atomic Host. אינני חושב ש-Atomic Host ימחק, אבל יכול להיות שיהיו שינויים שיגיעו מ-Container Linux של CoreOS.
  • בכל מה שקשור ל-Registry, אני בספק אם יהיו שינויים רציניים אם בכלל במוצרים של רד-האט. ה-Registry הנוכחי שקיים ב-OpenShift לא ממש שונה למיטב זכרוני ממה שקיים ב-Quay, אבל יכול להיות שיהיו שינויים מעטים.
  • לגבי Tectonic – כאן זו שאלת המיליון דולר. רד-האט מייעדת את OpenShift ללקוחות גדולים, אלו שמוכנים לשלם כמה עשרות אלפי דולרים על מערכת OpenShift Enterprise (ועוד 2000-3000$ פר Node, ויש עוד כמה תשלומים על כל מיני חלקים) ורד-האט כבר הפיקה לקחים מהעבר לא לעצבן את הלקוחות הגדולים בשבירת תאימות אחורה. אני מאמין שבשנה שנתיים הקרובות יהיו 2 מוצרים: יהיה Tectonic שכולל שינויים (והמרה/תמיכה בפורמט קודם) להיות תואם לפורמט של OpenShift והוא ייועד לתחום ה-SMB (כלומר Small/Medium Business) ותהיה מערכת ה-OpenShift Enterprise שתוכל להמיר מערכת Tectonic ל-OpenShift – לאלו שגודלים ורוצים לעבור ל-OpenShift Enterprise.
  • לגבי etcd – השינויים שיהיו הם מול ה-Upstream, כלומר מה ש-CoreOS קובעים (פחות או יותר) יכנס ל-OpenShift.
  • לגבי RKT – יכול להיות שיקחו חלקים ממנו לצרכי שיפור Docker Container Engine (אני בספק) אבל אישית אני לא רואה את זה ממשיך כמוצר מסחרי.
  • לגבי השאר – כל פרויקט יעבור בחינה אם הוא מתאים לשילוב בדברים קיימים או שהוא ישאר ב-github.

רבים ישאלו: מדוע בעצם רד-האט רכשה את CoreOS? הרי יש להם מוצר כמו OpenShift הן בגירסת Online (שכל אחד יכול להיות מנוי ולהקים קונטיינרים מבלי להרים מקומית מאומה) והן גירסת Enterprise, אז מה להם ול-CoreOS? התשובה היא פשוטה: גודל שוק ולקוחות. השוק יותר ויותר מתרכז סביב פתרונות גדולים, בין אם מדובר בפתרונות ענן של ספקי הענן הציבורי, פתרון Kubernetes ישיר (גירסת הקוד הפתוח) או פתרון ניהול קונטיינרים מבוסס Kubernetes עם "פנים" ל-Enterprise. תמיד יהיו פתרונות כמו DC/OS, Rancher ואחרים שיכולים להתאים לכל מיני סקטורים, אבל ה-Enterprise דורש דברים אחרים ש-Kubernetes עצמו לא נותן לא מבחינת אבטחה, לא מבחינת רגולציה, עמידה בסטנדרטים משפטיים ועוד, והדבר הכי קרוב שיש עבור Enterprise כולל הדרישות הגבוהות שלהם (ולאלו שמוכנים לשלם) זה OpenShift.

אז מה יעשו אלו שכבר הטמיעו מערכות מבוססות CoreOS? אני מאמין שבמשך השנה-שנה וחצי קרובות הם ימשיכו לקבל שרות מ-CoreOS בהתחלה ולאחר מכן מ-רד-האט (לקוחות ששילמו יקבלו מייל ישיר מ-CoreOS עם פרטי יצירת קשר).

תכירו את Kubevirt

הערה: פוסט זה כבר אינו רלוונטי. הוא שוכתב מחדש ונמצא בקישור הזה.

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

כאן בדיוק מגיע החלק שאני לא אוהב לעשות רק שאין ברירה – להחזיר את הלקוח למציאות, אותה מציאות שאומרת שאי אפשר להעביר כל פיפס לקונטיינר. לעיתים צריכים "לפרק" VM אחד לכמה וכמה קונטיינרים, לעיתים זה כלל לא אפשרי (כשה-VMמחובר לחומרה כלשהי, כשהקונטיינר משתמש ב-Kernel modules), כשה-VM הוא בכלל Appliance סגור ובעוד מקרים רבים נוספים.

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

אחת הבעיות שנוצרות מהכנסת קונטיינרים ומערכת ניהול/אורקסטרציה (כמו Kubernetes, OpenShift, Docker-swarm ואחרים) היא שמעתה צריך לנהל 2 מערכות שונות. האחת לניהול השרתים הוירטואליים שלכם (Hyper-V, vSphere) ואחד לניהול הקונטיינרים שלכם ולמרות שברמה העקרונית שתיהן מרימות דברים שהם מופרדים (קונטיינרים, VM), יש תהום של הבדלים ביניהם:

  • ב-Kubernetes הרשת מנוהלת בצורה אחרת לגמרי
  • כל עניין ה-Clustering הוא משהו שונה וחדש שלא קיים בשום פתרון וירטואליזציה
  • דיסקים בכלל מוגדרים בצורה שונה ואין אפשרות לנהל את ה"דיסקים" בפתרון כמו Kubernetes (להגדיל, להקטין דברים שקיימים)
  • שיטת העבודה עם Kubernetes (ו-OpenShift) היא בכלל שיטה "הצהרתית" (כלומר אתה מצהיר מה אתה רוצה שיקרה, המערכת עובדת על לקיים את רצונך. Genie כזו 🙂 ).

יחד עם זאת, לא היה נחמד יותר להשתמש ב-Kubernetes (או OpenShift או CAAS של SuSE)?

ובכן, יש פרויקט חדש של רד-האט שעובד בדיוק על הדברים הללו. הוא לא לפרודקשן והוא לא יפעיל לכם מכונות וירטואליות של Hypervisor מסחרי (בשלב זה, בהמשך יהיה אפשר לתחזק/להגדיר מכונות של vSphere מכיוון שהפרויקט משתמש בספריית libvirt). זה רק בשלבי תכנון וקידוד ראשוניים.

תכירו את Kubevirt.

הרעיון של Kubevirt הוא די פשוט: בתוך Kubernetes יש דבר שנקרא CRI (ר"ת Container Runtime Interface). פרויקט oVirt מרחיב את ה-CRI ואת Kubernetes עצמו כך שיוכל להפעיל גם מכונות וירטואליות כאילו מדובר בהפעלת קונטיינרים. בד"כ ע"מ ליצור POD עם קונטיינר, אנחנו יוצרים קובץ בפורמט YAML (או JSON, בהתאם להעדפות), וכאן הדברים יהיו דומים. הנה דוגמא לקובץ YAML כזה.

אם נשתמש ב-kubevirt עם קובץ ה-YAML הזה, תקום לנו מכונה וירטואלית קטנה (64 מגה זכרון) והדיסק שלה יהיה iSCSI. כך נוכל לערב בין קונטיינרים למכונות VM, לפי הצורך.

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

לאלו שמעוניינים להבין מה קורה מאחורי הקלעים, הוידאו הפעם מכנס KVM פורום יוכל לסייע:

וירטואליזציה והעתיד

עולם הוירטואליזציה ידע ב-30+ שנים האחרונות תהפוכות רבות. זה התחיל ב-IBM עם המיינפריים, המשך למערכות יוניקס השונות עם פתרונות מסוגים שונים (רובם מבוססי חומרה), המשיך בצעדים קטנים בעולם ה-PC (בדסקטופ, לא בשרתים), ובשרתים מודרניים זה התחיל עם "מעין וירטואליזציה" כמו chroot, jails ובסולאריס עם Zones.

עד שהגיעו VMWare שגם הם התחילו בהתחלה בדסקטופ (ה-Workstation, אחרי זה ה-GSX, אחרי זה ESX ולבסוף ESXI) והם "לקחו את הקופה" בכל הקשור להצעת וירטואליזציה מלאה. מה שהיית יכול (בד"כ) להריץ על שרת בודד, אתה יכול להריץ בשרת וירטואלי ללא שינויים. VMware נכנסה לשוק די ריק וכבשה אותו ורק לאחר מספר שנים נכנסה מיקרוסופט עם ה-Hyper-V ולאחריה נכנסו אחרים כמו אורקל עם ה-VM Server שלהם וגם רד האט עם RHEV (כיום זה נקרא RHV), ופתרונות אחרים כמו Proxmox ואחרים.

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

  • פתרון וירטואליזציה רגיל – ערימת שרתים שכל התוכן נשמר בדיסקים מקומיים.
  • פתרון וירטואליזציה רגיל – עם NAS או SAN כאשר ה-DATA נשמר על אותו פתרון אחסון.
  • פתרון וירטואליזציה hyperconvergence – שבו הכל יושב בארון אחד ובלוגיקה מאוחדת – ה-storage, הרשת (נהיית כמעט כולה וירטואלית – SDN ), וה-Compute – כמו פתרונות של Nutanix, או Simplivity או RHV (לשעבר RHEV, בגירסה החדשה 4.2 שתצא בקרוב).
  • פתרון וירטואליזציה משולב קונטיינרים – מכונות ה-VM משמשות כ-nodes והקונטיינרים רצים בתוך ה-Nodes.
  • פתרון של קונטיינרים בלבד – ה-Nodes יושבים על מכונות פיזיות (ללא וירטואליזציה) והקונטיינרים רצים על המכונות הפיזיות (פתרון לא מומלץ, הואיל וכך קשה לנטר ולטפל בשרתים).

קונטיינרים נכנסו בסערה לשוק ב-4 שנים האחרונות כאשר Docker הוביל בשוק שהיה עד כה עם פתרון Zones של Solaris ומספר פתרונות לא-ממש-משוייפים בלינוקס כמו LXC והפשוטים כמו chroot ו-jails (שקיים לגרסאות BSD). פתרון הקונטיינרים הראה לעולם מה שמנהלי Solaris ולינוקס ידעו ממזמן – אתה יכול להרים קונטיינר ב-2-3 שניות ולהריץ עליו אפליקציות. הפתרון היה מוגבל, אבל הוא בהחלט הצית את הדמיון ומספר אנשים החלו לעבוד על פתרון משלים בגוגל ולאחר זמן מה גוגל החליטו להוציא את הפתרון שלהם שמשתלב עם Docker ונקרא Kubernetes (או בקיצור: K8S ובתרגום השם מיוונית: טייס – pilot) ו-K8S נותן לך פתרון כמעט מלא לקונטיינרים – החל בשרידות, גדילה דינמית, בדיקת "בריאות" קונטיינרים, תקשורת ביניהם (באמצעות תוסף צד ג' – יש מספר פתרונות מובילים) ועוד ועוד.

חברות ענן ציבורי שנתנו שרותים המבוססים על VM קפצו על המציאה והחלו לתת פתרונות מבוססי קונטיינרים וכיום יותר ויותר חברות בתשתית הפנימית שלהם מתחילים להבין שבמקום הצורך שיהיו 100 מכונות וירטואליות, אפשר להסתדר עם 10 מכונות וירטואליות גדולות ו-500 קונטיינרים, החסכון במשאבים הוא די רציני, נוסיף לכך יתרונות נוספים של קונטיינרים וכך נוכל להבין מדוע חברות קטנות כגדולות מתחילים "לזוז" יותר ויותר לכיוון קונטיינרים.

זה המצב כרגע בשוק.

ומה העתיד צופה לנו?

מי שנמצא בתחום המחשבים עשרות שנים יכול בוודאי לראות שפתרונות ישנים תמיד עושים "סיבוב" נוסף וחוזרים כפתרונות מודרניים. קחו Mainframe מלפני 30+ שנה, דברים עתיקים כמו System/360 של IBM ונוכל לראות שם ש-IBM הריצו מערכות נפרדות כ… קונטיינרים, בשמות אחרים, במושגים שונים, אבל במבט על – אפשר להשוות זאת לקונטיינרים והנה כיום השוק חוזר ל.. קונטיינרים. אותו דבר בוירטואליזציה (גם שם ל-IBM יש הרבה קרדיט ו.. אלפי פטנטים. אם IBM היתה רוצה להתנהג כמו שמיקרוסופט התנהגה בשנות ה-90 – הייתם משלמים היום הרבה הרבה יותר על פתרונות וירוטאליזציה וקונטיינרים).

לעניות דעתי, הדבר הבא שיכנס – יהיו הקונטיינרים VC (לא, אני לא מדבר על vCenter שבין כה הולך למות לטובת VCSA לשמחתי). מה זה קונטיינרים VC? התשובה לכך היא Virtualized Containers ויש מספר חברות (הכי גדולה היא אינטל עם ה-Clear Containers) שיציעו זאת.

איפה זה נכנס? הבעיה כיום עם קונטיינרים היא שההפרדה בין קונטיינר לקונטיינר היא חלקית. אם נפעיל קונטיינר A ונכנס אליו, הוא לא יכול לדבר כברירת מחדל עם קונטיינרים אחרים או עם ה-host אלא אם נגדיר לו כך ספציפית (בצורה של Volume או בהגדרות רשת). יחד עם זאת, אם אני מצליח לקבל גישת root ל-host עצמו, אני לא רק שיכול לראות את כל התליכים שהקונטיינרים מריצים, אני יכול לשבש את כל המערכת. יש פתרונות לכך כמו SELinux ו-AppArmor אבל הרוב לא משתמשים בכך ובחברות גדולות כמו בנקים וכו' העניין די מעכב הכנסת פתרונות מבוססי קונטיינרים. (אצל חברות הענן כמו אמזון וגוגל, המצב שונה לחלוטין וגם אם תצליח לפרוץ את הקונטיינר – לא ממש תגיע ל-host, והם משתמשים בפתרונות חומרה כדי להגן על הדברים, פתרונות חומרה משלהם שהם אינם מוכרים. ככלל, שרתים אצל יצרני הענן שונים מאוד בתצורה הסופית מהשרתים שחברות קונות).

כאן נכנסים ה-VC. ה-Virtualized Containers הם בעצם מכונות וירטואליות לכל דבר ועניין שיריצו את האפליקציה שלכם, רק שהם בנוים בצורה אחרת. לדוגמא עניין ה-BIOS ותצורת ה-PC הקלאסית – הועפו החוצה ודברים רבים שונו כך שה-VC לא יצרכו משאבים כמו VM רגיל, אבל מצד שני תקבל את ההגנות של וירטואליזציה כך שגם אם יש לך root ל-host עצמו, זה לא אומר שתוכל לראות תהליכים רצים (תוכל לראות מכונות וירטואליות שרצות אבל די קל גם להגן עליהן עם פתרונות הצפנה, שימוש ב-HSM וכו' וכו').

אפשר לקבל מעט יותר פרטים על כך ב-Kata Containers , הגירסה הבאה של OpenStack כאן שתתמוך בפתרון VC, ואני משער ש-Kubernetes יתמכו בהמשך גם ב-VC של חברות אחרות ושל אינטל.

ומה עם הפתרונות של VMware?  ל-VMWare כיום יש את vSphere integrated containers אבל אני מאמין שב-vSphere 7 הפתרון יהיה שונה, וגם ב-VMWare יבינו שרעיון ה-VC הוא רעיון לא רע בכלל להטמעה ושימוש, ומכיוון שב-VMWare יש צוות ענק של אנשי לינוקס, הם יכינו פתרון כזה (הימור שלי: פתרון ה-VC שלהם יתאם ללינוקס, לא ממש ל-Windows, לפחות לא בגירסה הראשונה) כך שתוכל להרים לך קונטיינר או VM, וזה לא ישנה הרבה, והפתרון יכלול גם Scale Out דינמי. (אין לי NDA מול VMWare וידע פנימי רשמי מה שקורה שם ולכן אני מסייג את הדברים, אלו רק שמועות ששמעתי).

עוד תחום שלדעתי יקבל יותר ויותר מקום (אך הדבר יקח זמן עקב שמרנות של חברות) הם מעבדי ARM. חברות כמו Qualcomm, Cavium ואחרות מתחילות להוציא מעבדי ARM V8-A עם 16/32/64 ליבות, מיקרוסופט עובדת ותשחרר בקרוב Windows 2016 לשרתי ARM ויש שמועות שגם ב-VMware וחברות אחרות עובדים על כך (הפצות לינוקס לשרתי ARM כבר קיימים כיום (גירסת SuSE קיימת כאן, וכאן ההכרזה של רד-האט, וכאן של Ubuntu). הרעיון עצמו הוא פשוט: בשרתים כאלו יש לך עשרות ליבות ואתה לא צריך לשלם 10000$ על מעבד כזה, והליבות הללו יכולות להריץ דברים קטנים ביעילות מופלאה. קונטיינרים הם (יחסית) קטנים, אז למה שלא תריץ את הקונטיינרים שלך על מעבדי ARM? צריך ברזלים? HPE הכריזו על כמה דגמים, DELL ו-Lenovo ממלאים את פיהם מים כרגע, אבל בוודאות אני יכול לאמר לכם – הם בונים כאלו בימים אלו לקראת הכרזה בקרוב.

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

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

יהיה בהחלט מעניין 🙂

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

[stextbox id="info" caption="גילוי נאות"]"חץ ביז" הינו עסק שמוכר שרותי אינטגרציה ויעוץ למספר מוצרים לתשתית קונטיינרים[/stextbox]

מערכות קונטיינרים בפלטפורמות שונות (קרדיט: 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 מוצרים גדולים וידועים שנמכרים ומקבלים תמיכה פה בארץ וכדאי לשקול את היתרונות והחסרונות של כל אחד לפני רכישה.