תמיכת מוצר מול הסכם בנק שעות

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

אתן דוגמא: במקרים מסויימים מתקבלים פניות לגבי האם ניתן שרות ברמות 1-3. בד"כ כשמתקבל אימייל כזה, אני מרים גבה. אישית – אני לא מכיר מה זה רמות 1-3 מהסיבה הפשוטה שכשעסק או חברה פונים ל"חץ ביז" – הם מחפשים פתרון לבעיה XYZ. עדיין היום אף לקוח או לקוח פוטנציאלי לא שאל אותי על רמות 1-3. השאלה העיקרית שנשאלת היא האם אפשר לקבל פתרון מ"חץ ביז" או לא. אם מדובר בבעיה ש"חץ ביז" נותן לה פתרון – אז בשמחה, מסכמים מחיר, תנאי תשלום וכו' ומתחילים לעבוד יחד. אם לא – אז לא.

רמות 1-3 (ושאר רמות) הן דרך מצוינת "לחלוב" מעסקים כספים. ככל שהרמה עולה, אתה משלם יותר. בעולם הלינוקס לדוגמא, רמות לא קיימות. כשאתה קונה לדוגמא SLES או RHEL, אז אתה מקבל תמיכה על גירסת הלינוקס שרכשת (בהמשך אכנס ליתרונות ולחסרונות). אם התמיכה בחבילה שרכשת אינה מספקת לסיטואציה שלך, אז אתה יכול לרכוש שרותי Incident או Consulting (כל חברה והמושגים שלה) שבה אתה תשלם כמה מאות דולרים לשעה, ויצרן ההפצה יקדיש לך מישהו שישב על המערכת שלה למצוא מה התקלה ואיך לפתור אותה. היכן יש רמות בעולם הלינוקס? ברמת הדחיפות. אם ניקח לדוגמא את רמות התמיכה של Red Hat, נוכל לראות שיש רמות ב-SLA. רוצה שרות טלפוני? שלם 800$ פר עותק הפצה. רוצה שרות מהיר? המחיר קופץ ל-1500$ פר עותק (שוב, המחירים אינם כוללים מצבים שבהם מהנדס מוצמד לעסק שלך לפתור את הבעיה, שם התשלום ליצרן ההפצה הוא בנפרד ממה ששילמת על ההפצה).

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

כשזה מגיע לעסקים וחברות שמריצים עשרות/מאות/אלפי מכונות לינוקס לעומת זאת, אין יתרון ברכישת מנוי שנתי לתמיכה של יצרן ההפצה. בעסקים וחברות, ברוב המקרים התוכנות שמריצים על הלינוקס – הן יותר חדשות ממה שמגיעים עם ההפצה. לדוגמא, גירסת PHP שמגיעה בהפצת RHEL 7.4 היא גירסה 5.4.16 כאשר הגירסה היציבה היום לפי אתר PHP היא 7.1.10. אם תתקין את 7.1.10 על ה-RHEL ויהיו לך בעיות שה-PHP לא מצליח לרוץ, רד-האט לא תתן לך שרות הואיל והם נותנים אך ורק שרות לחבילות שהגיעו עם ההפצה עצמה, לא מ-REPO נוספים. דוגמא נוספת: רוצה להשתמש ב-NodeJS? הגירסה שקיימת היום ב-EPEL REPO היא אכן גירסת ה-LTS האחרונה, אבל שוב – מכיוון שזה REPO חיצוני, אין תמיכה רשמית מצד רד-האט.

לכן אני ממליץ לחברות לחשוב על כמה נקודות:

  • אם יש בחברתכם IT שנותן תמיכת לינוקס, ואתם חושבים במהלך השנה להכניס טכנולוגיה/פלטפורמה חדשה – קחו יעוץ חיצוני (גם אם זה לשעות בודדות) שמכיר את הטכנולוגיה החדשה. חבל שתשרפו עשרות שעות על תקלות שהיועץ החיצוני כבר מכיר.
  • אם בחברתכם יש חובה להשתמש בהפצה מקורית (RHEL או SLES) ואתם רוצים עדכונים, אז מומלץ לחשוב על רשיונות SuSE Linux Enterprise עם Expanded Support – זה יתן לכם עדכונים גם ל-RHEL וגם ל-SUSE וזה גם יותר זול מ-RHEL מבחינת רישוי שנתי.
  • כיום כמעט בכל פרויקט לינוקס, החבילות מגיעות מבחוץ (Github או REPO חיצוניים) אינן נתמכות ע"י יצרן ההפצה ולכן אם אין לכם צוות לינוקס בחברה שיכול לבצע אינטגרציה במסגרת הזמן שאתם רוצים – קחו יעוץ חיצוני (כדאי לסכם שיכתבו עבורכם תיעוד).
  • אם אתם משתמשים (או חושבים לעבור) לאובונטו, עדיף לרכוש בנק שעות חודשי ליעוץ מומחה.

על OpenShfit, הטמעה וציפיות בחברות

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

חלק לא קטן מהטענות ששמעתי הגיעו מצד גופים שחשבו ש-OpenShift זה כלי עם GUI מרשים ל-Kubernetes. הנחה זו היא די מוטעית. אם מחפשים GUI וכלי ניהול בשביל Kubernetes, אפשר להסתכל על מוצר בקוד פתוח שלא עולה כלום כמו Rancher. לעומת זאת, Openshift זה כלי שבא לתת לך הכל ללא צורך בהזדקקות לשרותים חיצוניים מהאינטרנט כמו Containers Registry וכו'.

על מנת להבין יותר את התפיסה של OpenShift, נדמיין סיטואציה אחרת לחלוטין: יש לנו 10 מפתחי JAVA ויש לנו שרת לינוקס גדול ורציני. למפתחים יש משתמש משלהם (נניח דרך אוטנתיקציית AD) על שרת הלינוקס ועל השרת מותקן באופן מרכזי ה-JDK וכלים אחרים שהמפתחים משתמשים, וכל מפתח יכול לבצע login ולבצע checkout מה-GIT המרכזי ולהריץ את האפליקציות JAVA שלו. אין צורך שיהיה לו ידע בניהול מערכת לינוקס, אבל מומלץ שיהיה לו ידע ממש בסיסי ב-BASH, ודברים פשוטים אחרים שאפשר ללמוד בשעה שעתיים – בשביל להריץ את מה שהוא כתב. מי שינהל את שרת הלינוקס מבחינת הגדרות, עדכונים וכו' – תהיה מחלקת ה-IT בחברה. לחובבי Windows אפשר לדמיין את הסיטואציה כשרת Windows שנותן שרותי RDP וכל משתמש נכנס עם המשתמש המאושר שלו והוא עושה מה שהוא צריך לעשות. הידע שהוא צריך – הוא שימוש בסיסי ב-Windows, לא יותר מזה.

השוני הכי גדול בין Kubernetes ל-OpenShift מבחינת כל מה שקשור לקונטיינרים – היא הגישה. ב-Kubernetes אם אני רוצה לבצע Deploy, לבצע Scale, רפליקציה, כתיבת שרותים ודברים רבים אחרים – אני צריך לכתוב קבצי YAML (או JSON) שאותם אני צריך להזין ל-Kubernetes ואני צריך גם לבדוק לוגים כדי לראות שכל רץ תקין, ולכן בחברות שמשתמשות ב-Kubernetes רוב העבודה הזו נופלת על איש ה-Devops. לעומת זאת, עם OpenShfit, הדברים בנויים יותר בכיוון שרת הלינוקס וה-JAVA. עם OpenShift אני מגדיר משתמשים (ומחבר את OpenShift ל-AD על מנת לשמור על סינכרון שם משתמש/סיסמא/הרשאות) ואותו מפתח יכול להריץ דברים ישירות דרך ה-CLI או ה-GUI ויש לו כלים מוכנים כדי שהוא לא יצטרך לשכתב קבצי YAML כדי לבנות קונטיינרים עם הקוד שלו בתוך ה-OpenShift. אם הוא רוצה לבצע לדוגמא Scale או Deploy, הוא פשוט יכול ללחוץ כמה קליקים ולהשתמש ב-Template מוכן, לתת שורת כתובת של ה-GIT שלו, ותוך דקות ספורות ה-POD עם הקונטייר/ים שלו ירוצו, הוא יכול לראות מתוך ה-GUI את הלוגים ואף לקבל גישת טרמינל מוגבלת לתוך הקונטיינר כדי לבדוק אם הכל תקין וכו' וכו' ואם הוא רוצה לשמר את מה שהוא עשה בתור קובץ YAML/JSON, המערכת תשמח ליצור עבורו את הקובץ הנ"ל.

לכן, מבחינת חברה, OpenShift עושה את החיים יותר קלים מבחינת הטמעה ושימוש בקונטיינרים, ניהול תשתית המכונות המריצות את OpenShift ואת הקונטיינרים עצמם, כלומר הצורך במישהו יעודי רק כדי להריץ דברים בקונטיינרים פוחת ואפשר להוציא זאת לשרות חיצוני או ללמד את צוות היוניקס/לינוקס את הדברים הדרושים, ובנוסף קל לראות אם ישנן בעיות בתשתית ה-OpenShift (מערכת Heapster נותנת גרפים עשירים פר Node, פר POD וכו' וכו', וגם ניתן לחבר את OpenShift ל-ELK, גרפאנה ושאר החברים). בנוסף, מכיוון ש-OpenShift מבוססת על Kubernetes, ניתן ליישם את מה שרץ על OpenShift על מערכת Kubernetes במקרים לדוגמא בהם הוחלט ש-OpenShift ירוץ בפיתוח ו-Kubernetes או פתרון תואם רץ בפרודקשן (אם כי זה קצת יותר מורכב).

ונקודה אחרונה לגבי מחיר: אני מכיר כמה מנהלי IT ששמעו את המחירים של רד-האט ולסתותיהם נשמטו. נכון, מחירים פר Node אינם בדיוק זולים, אולם המחיר יורד לחמישית אם מריצים את ה-Node כמכונת VM ומעוניינים להריץ את הגירסה המסחרית. חוץ מזה שאישית – אני ממש לא ממליץ להריץ את OpenShift על "הברזל" אלא אם יש שם למחלקת ה-IT ידע ממש עמוק ורציני בלינוקס, אחרת אפשר להפיל Node (ולא חשוב אם זה Node לעבודה או Master) די בקלות. בכל זאת, לא מדובר על הפעלת Cluster קונבנציונאלי עם HeartBeat, PaceMaker וכו'.

לסיכום: OpenShift היא לא מערכת קלה להקמה (יש צורך בידע ב-Ansible אם רוצים להקים אותה על מספר מכונות, אגב – אפשר להרים אותה על דסקטופ עם 16 ג'יגה זכרון בעזרת MiniShift) ויש צורך בידע רציני על מנת להקים ולהגדיר דברים, אבל אחרי שהכל מוקם, יש צורך בפחות ופחות "התעסקות" עם המערכת. זו מערכת שנבנתה עם מחשבה מראש על מפתחים שלא הולכים לעבור קורס קונטיינרים, יחד עם שמירת כל הרגולציות ו-Lifecycle שחברות דורשות.

התהליך המומלץ בעת ביצוע פרויקט ע"י יועץ

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

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

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

לעניות דעתי, דברים צריכים להתבצע בדיוק ההיפך.

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

לכן, בשלב הראשון – תיאור הפרויקט צריך לכלול קודם כל את הפירוט מה האפליקציית קצה שצריכה לרוץ. האם מדובר במערכת Build? האם מדובר באפליקציות ישנות? גרסאות טסט של המוצר/שרות וכו' וכו'. יש מקומות שפתרון וירטואליזציה יתאים, ויש מקומות שפתרון קונטיינריזציה יתאים יותר ויש גם מקרים שעקב דרישות – יהיה צורך להריץ את זה על ברזל פיזי.

משם עוברים לשאר החלקים – אחסון (Storage), רשת (Network) ומחשוב (Compute). היכן מומלץ לחשוב על פתרון NFS והיכן מומלץ על פתרון בלוק כמו iSCSI? האם ללקוח יש תשתית תקשורת מתקדמת (10/25/50 ג'יגהביט) או שצריך לעבוד ב-Teaming? האם חיבור הסטורג' "יחנק" עקב עבודה מאומצת של הפתרון שהלקוח רוצה שירימו לו? האם הלקוח צריך לעבוד ב-HA או DR או שאם נופל הפתרון ויש השבתה זמנית זה לא יהיה קריטי בשבילו? ועוד לא דיברנו על שילוב אוטומציה, Workflow ועוד דברים אחרים.

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

עדכונים לגבי ESXI

זמן רב לא כתבתי על VMWare ESXI והגיע הזמן אולי לפרסם כמה דברים שחלק מהקוראים יודעים וחלק לא וגם לתת לכם זמן לחשוב לגבי גירסה עתידית של ESXI והאם כדאי יהיה לעבור אליה.

נתחיל בהווה: אם יש לכם גרסאות 4, 5, 5.1, 5.5 אז אולי הגיע הזמן יהיה לחשוב על שדרוג. לפי המסמך הזה של VMWare, גרסאות 4, 5.0, 5.1 כבר סיימו את חייהם מבחינת תמיכה ואם אתם מריצים גירסה 5.5 – היא תסיים את חייה ב-19/9/2018 כך שכדאי בתכנון התקציבי להכניס הוצאת שדרוג.

אם אתם משתמשים בגירסה 6.0 של ESXI אז מאוד מומלץ לשדרג לגירסה 6.5U1. השינויים בין 6.0 ל-6.5 הם רבים וכוללים שינויים ועדכונים ל-vSAN, עדכוני דרייברים רבים, מעבר ל-VSCA (ב-VMware ממש רוצים שתעבור ל-VCSA והם נותנים "הטבות" ב-VCSA כמו כלי מיגרציה, High Availability "טבעי", וגיבוי ושחזור "טבעיים" (של ה-Appliance, לגיבוי מכונות VM תמשיכו להשתמש ב-Veeam). ההתקנה של VCSA הרבה יותר קלה ואתם יכולים לקרוא על מגוון התכונות החדשות במסמך הארוך והרשמי כאן או בגירסה המקוצרת כאן. השדרוג מ-6.0 ל-6.5U1 עולה לכם … 0 שקלים מבחינת רישוי.

אם יש לכם גירסה 6.5, מאוד מומלץ לשדרג ל-6.5U1 בגלל כמה סיבות, להלן חלק מהן:

  • גירסת VSAN שודרגה ל-6.6 (והיא מצריכה ESXI 6.5 כולל VCSA 6.5 או אם אתם עדיין בגירסת Windows – אז vCenter Server 6.5 – מומלץ בחום לעבור ל-VCSA, הוא יעביר לכם את הנתונים אוטומטית) ואם אתם עובדים All Flash תקבלו הפתעה נחמדה – שיפור של 50% בביצועים. בנוסף תכנון גדילה עובר עתה תהליך Pre-check כך שהדברים יהיו יותר בטוחים ולא יפלו עקב חישוב שגוי מצד מנהל המערכת. בנוסף מקבלים את vRealize Operation Management, תהליך ה-Deploy יותר קל, תהליך בדיקת התקינות שופר מאוד, אין יותר צורך ב-Multicast (אני יכול לדמיין אנחת רווחה מאנשי התקשורת), שיפורים ב-Cross Site Protection (לאלו שמשתמשים בזה, לא מכיר כאלו) ועוד. אפשר לקרוא מה חדש כאן.
  • אם אתם חושבים לרכוש ברזלים חדשים כמו שרתים מבוססי מעבדי EPYC (שאפו!) או שרתים מבוססי דור 5 של Xeon – תצטרכו את ה-Update 1 של גירסה 6.5, אחרת תקבלו מסך סגול והמון עצבים. לאלו שרוצים להריץ בביתם כ-LAB את גירסה 6.5 על מעבדי Ryzen או Threadripper או Skylake-X – גם אתם תצטרכו את גירסת 6.5U1. (לא מומלץ לנסות על Kabylake-X – ניסיתי, זה נופל לאחר זמן מה מבחינת ביצועים ו-VMware אפילו לא מוכנים להתייחס לכך).
  • עדכוני דרייברים – ישנם עדכונים לכל כרטיסי הרשתות, החל מכרטיסים בסיסיים כמו כרטיסים מבוססי אינטל של 1 ג'יגהביט ועד לכרטיסים של 40/50 ג'יגהביט (למיטב ידיעתי כרטיסים של 100 ג'יגה תצטרכו דרייבר יצרן עדיין).
  • ה-vCenter יכול להיות ב-High Availability באופן טבעי ללא צורך בקפיצת ראש לבריכה בעומק חצי מטר. מגדירים Active, Passive ו-Witness ויאללה – יש HA. פונקציה זו אינה קיימת בגירסת Windows. כמו שאמרתי – VMWare מאוד רוצים שתעופו מגירסת ה-Windows לטובת גירסת ה-Appliance.
  • שדרוג מכונות ESXI הרבה יותר קל וברוב המקרים אוטומטי לגירסה אחרונה עם VCSA. שימו לב: קודם משדרגים Appliance ורק אז את ה-Hosts.
  • גם VUM עבר שדרוגים בכל הקשור לעדכונים ומעתה הוא יכול גם לשדרג אוטומטית (אם תרצו) מכונות VM לגירסה אחרונה (או גירסה שתקבעו) של תאימות VM.
  • בכל הקשור ל-Auto Deploy, מי שמנהל את ה-vSphere בחברה אולי ישמח לדעת שהוא פחות יצטרך להשתמש ב-PowerCLI ועכשיו יש ניהול גרפי מלא של הדברים וגם בניית Image חדש של ESXI Boot תוך כדי הוספה והעפה של דרייברים.
  • ויש עוד ערימות של תכונות חדשות…

אחד הדברים החשובים לגבי תשתית vSphere מהגירסאות הקיימות לגירסה 7 העתידית – זה שגירסה 7 העתידית תהיה שונה מאוד ממה שהיה עד כה. זה לא סוד ש-VMWare עובדים לאט (רק בגירסה 6.5 הם התחילו לתמוך ב-VMWare tools חתומים והתקנה של מערכות הפעלה עם Secure Boot), אבל בגירסה 7 הם רוצים לסגור פערים. העולם עובר לקונטיינרים וכרגע ל-VMware אין תשובה ב-vSphere באופן רשמי, כנ"ל לגבי פתרון תחרותי ל-OpenStack או Azure Stack של מיקרוסופט (אם כי יש להם כלי להקים OpenStack בתוך vSphere – ראו למטה), כך שגירסה 7 תהיה שונה לחלוטין מכל הגרסאות הקודמות. אי אפשר למסור עליה פרטים (אין לי הסכם NDA עם VMware אבל מצד שני אין לי חשק מחר לקום בבוקר ולקבל טלפון וצעקות מאנשים שם) אך מה שכן אפשר לאמר – שהיא בהחלט תקל על חברות גדולות שרוצות לעבור להשתמש בקונטיינרים (ויש לה כבר פרויקטים בקוד פתוח בנושא, אפשר לראות אותם כאן – ויש המון). משהו אחד שאני יכול להמר (אין לי בסיס משמועות לכך) זה ש-VMWare גם תבצע אינטגרציה של VMWare Integrated Openstack לתוך vSphere בעזרת מוצרים משלימים שיש כבר ל-VMware ובעזרת חלקים בקוד פתוח (שהיא תשחרר שינויים תחת אותם רשיונות). אגב, למי שלא מכיר את התוכנה – מוזמן לעקוב אחר המצגת הנחמדה כאן.

לסיכום: ישנם לא מעט חברות גדולות שרוצות להישאר רק על VM, לא ענן מבוסס OpenStack, לא קונטיינרים (אולי בעתיד) וחברות רבות הן גם מאוד שמרניות, לכן אני חושב שנראה כאן מעין "קו" וירטואלי בין מוצרים והטמעות שחברות יבחרו. עד גירסה 6.5U1 ה-vSphere סובב כולו סביב VM והתשתיות לספק את הדרישות ל-VM (רשתות, סטורג' וכו'). מגירסה 7 המוצר יהיה הרבה יותר גדול ומורכב בהרבה מהיום ולא בטוח שחברות ירצו לקפוץ אליו  ויש מצב שיותר ויותר חברות יחליטו להישאר עם 6.5U1 ואת השאר להעביר לעננים ציבוריים במקום לשדרג לגירסה 7 (ודרך אגב, אני מאמין שגירסה מוקדמת שלה אנו נראה ב-VMWorld שתתרחש עוד 18 יום ולאחר מכן ב-VMWare Europe. אגב, בכנס הזה נראה את התשובה של VMWare לאינטגרציה עם עננים ציבוריים, לא רק של אמזון).

הולך להיות מעניין…

קונטיינרים, OpenStack ושינוי מערכות

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

אז החלטתי לכתוב פוסט שינסה לתת כמה טיפים לגבי נושאים אלו.

נתחיל ב-OpenStack: למרות שזו פלטפורמה מעולה לוירטואליזציה ומערכת ליצירת שרותי PAAS/SAAS/IAAS, כדאי לקחת בחשבון את העלויות שלה. כן, ישנה גירסה חופשית אך גירסה זו משתנה מדי כמה חודשים ואין שום בטחון שגירסה שתצא עוד חצי שנה תהא תואמת לגירסה הנוכחית ולכן מומלץ לחברות שרוצות OpenStack לרכוש את הגירסה שהפצות הלינוקס ומספר חברות אחרות מציעות (לא את הגירסה שכל מיני חברות מציעות של HP כ-Helion כי זו גירסה די מתה). המחיר אינו זול (מ-20K$ ומעלה) אולם אתם כחברה יכולים להיות שקטים שהמערכת שלכם תיתמך לשנים הקרובות (בין 3 ל-5, תלוי איזו גירסה קניתם ומתי) ותקבל עדכוני אבטחה ותיקוני באגים קריטיים.

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

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

יחד עם זאת, מעבר לקונטיינרים מחייב הבנה כי קונטיינרים אינם מכונות וירטואליות והדברים עובדים בצורה שונה לחלוטין בכל הרמות, החל מהקמה, הרצה, עדכוני קונטיינרים, כתיבה/קריאה ל-Shared storage חיצוני ועוד ועוד.

להלן שאלה שהח"מ נשאל עליה תדירות: האם להעביר VM לקונטיינרים? והתשובה היא: לא. קודם כל יש להכיר את עולם הקונטיינרים ורק לאחר שמכירים אותו בונים את הדברים בצורה אחרת מ-VM בכל אספקט, כך שאין כאן תהליך של "המרה", יש תהליך של בניה מחדש של Images ובשימוש ה-Images מקימים קונטיינרים, שזה די הפוך מ-VM.

כך לדוגמא, אם יש לכם אפליקציית JAVA שרצה על JBoss, תצטרכו קודם לחפש לכם פתרון אחר במקום JBoss (כמו Wildfly, tomcat וכו'), להעביר את הקוד של האפליקציה ל-GIT ואז להשתמש בכלים כמו S2I או מערכות כמו Jenkins כדי להקים את ה-Images שכוללים את האפליקציית Server להרצת ה-JAVA וכשהיא תרוץ, היא תפעיל את האפליקציה שלכם שכתבתם ב-JAVA (או להשתמש ב-OpenShift שיעשה לכם את רוב העבודה 🙂 )

למרות ש-OpenStack יכול להריץ קונטיינרים, מומלץ יהיה להשתמש במערכת Scheduling כמו OpenShift, Kubernetes, Docker Swarm, Rancher ואחרות כדי להריץ את הקונטיינרים, כלומר אם משתמשים ב-OpenStack, עדיף להרים מכונות VM שישמשו כ-Nodes כדי להריץ את הדברים הללו.

כשזה מגיע ל-Storage, אינני ממליץ לזרוק את ה-Storage מהחלון, אולם כדאי לחשוב על חלוקה מעט שונה של ה-Storage לצרכים השונים. OpenStack יכול להסתדר עם iSCSI ו-NFS, אולם קונטיינרים צריכים NFS בלבד. אם אתם משתמשים ב-Object Storage על מנת לאחסן קבצים סטטיים או תמונות לדוגמא, יכול להיות שיהיה עדיף להקים "מיני סטורג'" שמורכב משרת עם דיסקים + JBOD (במקרה הצורך) הואיל ו-Object Storage אינו מצריך מהירות גבוהה.

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

גילוי נאות
שרותים אלו ניתנים ע"י חץ ביז

העתיד: דיסקים, Storage ו-NVME-OF

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

ואז הגיעו דיסקים SSD ובהתחלה יצאו SSD עם חיבור SAS אך במקביל יצאו דיסקים SSD בחיבור SATA, וכאן החל הבלבול: הרבה אנשים מכירים את המפרט הזה של SAS מול SATA ו-SATA הרי תמיד יתן ביצועים יותר נמוכים מול SAS, לא?

התשובה: במקרים של דיסקים מכניים – בהחלט. במקרים של SSD – זה יוצא ההיפך. קחו דיסק SSD בחיבור SATA ותקבלו לדוגמא מהירות קריאה של 550 מגהבייט לשניה. לזה, שום SAS לא הגיע עם דיסקים מכניים (אלא אם מכניסים את ה-Cache של הבקר אבל זה יפה במבחנים, לא לעבודה במציאות) וכך עולם הדיסקים חזר "אחורה" ל-SATA ופורמט ה-SAS די "מת" למרות מאמצים מצד יצרני בקרים ושרתים להוציא (מאוחר מדי, LSI היו הראשונים להוציא מוצרים ב-2013) את SAS-12G, וכך המצב בשנתיים האחרונות בשוק הוא שדיסקים SSD קיימים בגירסאות SATA בלבד – אבל הדיסקים עצמם מכילים את כל תכונות ה-Enterprise כמו תיקון תקלות אוטומטי, שמירת מידע עצמאית בעת הפסקת חשמל, שרידות גבוהה בעבודות כבדות ועוד.

דיסקים SSD מבוססים SATA מאפשרים לחברות להמשיך לעבוד כאילו הם עובדים עם דיסקים מכניים או דיסקים SSD ישנים, ורבים נוטים עדיין לעשות את הטעות לעבוד כ-RAID-5,50,60 כשהם שוכחים 2 דברים מאוד חשובים:

ה-RAID-5 וה"אחים" שלו 50,60 ביצעו 2 דברים חשובים: נתנו ביצועים גבוהים הנובעים מעבודה עם ריבוי דיסקים וחלוקת העבודה בין הדיסקים, ושרידות יותר גבוהה מכיוון שאם הולך דיסק אחד או 2 (בהתאם לשלב ה-RAID) – המערכת היתה ניתנת לשיקום לאחר החלפת הדיסקים. עם SSD לעומת זאת (גירסת Enterprise!) הביצועים שהדיסקים האלו מוציאים די "חונקים" כל כרטיס רשת. תחשבו על כך: 2 דיסקים SSD ב-RAID-0 מוציאים מהירות תיאורתית של 1100 מגהבייט לשניה (בקריאה). נתרגם זאת לג'יגהביט ונקבל .. 8 ג'יגהביט, כלומר כרטיס רשת של 10 ג'יגהביט יהיה תפוס ב-80% בזמן שהוא משדר את ה-DATA מצמד הדיסקים, ושוב – אני מדבר על 2 דיסקים בלבד. אז מה בעצם נותן בקר דיסקים? ביצועים? יש כבר לדיסקים, לא צריך גם Cache. שרידות? ב-SSD ל-Enterprise יש יכולות הרבה יותר מרשימות של שרידות פנימית מאשר כמעט כל בקר RAID בשוק. ובכל זאת, חברות ממשיכות לעבוד כך. מדוע? אני חושב שזה עניין של הרגל.

בשנתיים האחרונות נכנסנו לעידן חדש של דיסקים SSD, מה שבהתחלה נקרא PCI SSD והיום פשוט נקרא NVME SSD. לדיסקים הללו לא תמצאו שום RAID כי הדיסק מחובר ישירות לתושבת PCIE X4 (בחיבור שנקרא כיום U.2, חלק מהיצרנים לצערי עדיין משתמשים בחיבור קנייני משלהם, לרווחתם של יצרני הדיסקים והשרתים, לצערם של הלקוחות ש"ננעלים" בכך שלא ניתן להכניס דיסקים יותר טובים מצד ג'). הדיסקים הללו כיחידות עצמאיות נותנות יותר ביצועים מכל מה שתשיג עם SSD ו-RAID, מהירויות של 2-4 ג'יגהבייט לשניה בקריאה ועד 2 ג'יגהבייט בכתיבה עם עשרות עד מאות אלפי IOPS (וכמובן את המילה האחרונה בשרידות, ושוב – שרידות הרבה יותר גבוהה מכל דיסק מכני שאתם מכירים) ושם כבר אין RAID (ואם רוצים RAID 0,1,10 – עושים זאת בתוכנה. הביצועים לא יהיו נמוכים יותר בהשוואה לבקר יעודי, האמינו לי, גם אם תנסו את זה על מעבד i5 פשוט [ניסיתי בעצמי מול בקר יוקרתי של LSI ]).

מי שבתחום כבר בוודאי מכיר את כל מה שכתבתי, אבל מה בעצם הלאה?

אם נסתכל מבחינת דיסקים, בשנה הנוכחית השוק מנסה להסתגל למצב חדש שבו יש הרבה יותר ביקוש מהיצע. דיסקים NVME SSD של 3-4 טרהבייט, גם אם תנפנף מול היצרן בכרטיס אשראי פלטיניום, תשלום מיידי או ערימת מזומנים – תיאלץ במקרים רבים לחכות וזה כרגע עדיין "מכה" ב-HP, DELL וגם ב-Lenovo. היצרנים נתפסו "במערומיהם" עם דרישות היסטריות לשבבי Flash מצד כל יצרני המחשבים והטלפונים. כולם רוצים שבבי NAND ועכשיו. יצרני השבבים גדלים (חברת TSMC לדוגמא, אחת החברות הגדולות ליצור שבבים – מתכננת בניה של FAB נוסף בסין בדיוק בשביל זה) ושבבי ה-3D NAND החדשים מאפשרים ליצור שבבים עם כמות אחסון יותר גדלה בליטוגרפיה בשיטות יותר "ישנות" כך שניתן פר Waffer ליצור יותר שבבים. שלבים אלו ואחרים יתורגמו לשחרור לחץ בשוק במהלך השנה שנתיים הקרובות.

אבל גם אם הבעיה תיפתר, נמצא את עצמנו בבעיה אחרת: בשביל ביצועים רציניים צריך NVME SSD וגם אם יש לך דיסקים חדשים וגדולים כאלו, איך בדיוק תשתמש בהם? זה לא שיש לך בקר RAID להגדיר Virtual Disk שעל זה אתה מתקין Windows, Linux, vSphere וכו'.. אפשר כמובן להוסיף דיסק קשיח כלשהו (ולהשתמש בבקר הפנימי כדי לבנות RAID-1 מדיסקים פשוטים) כדי להתקין את מערכת ההפעלה וכו', אבל הדבר הבא שהיצרנים ידחפו נקרא NVME-OF (זהירות, לינק לקובץ PDF). זהו הסטנדרט חדש שנבנה ע"י החברות שבנו את סטנדרט NVME, ועם הסטנדרט הזה אנחנו משתמשים בכמה מושגים שבוודאי שמעתם עליהם:

  • ה-AFA (כלומר All Flash Array) – מערכת סטורג' (או שרת) שבנוי כולו מדיסקים NVME SSD.
  • על מה נעביר את הנתונים? זוכרים ROCE? אז הוא חוזר לסיבוב נוסף, ולאלו שאוהבים לשפוך כסף כאילו אין מחר (בנקים, מכוני מחקר יוקרתיים וכו') – Infiniband.
  • ובאיזו שיטה? זוכרים iSCSI? אז נגזור משם את ה-Target ו-Initiator, שיהיה לכם חיים יותר קלים.
  • אבל מה עם כתובות IP וכו'? זה ישאר, רק שהפעם זה "נעקר" מה-OS ומועבר לביצוע ע"י כרטיס הרשת (כלומר TCP Offload).

עכשיו נשלב את הכל ביחד: נבנה שרת מבוסס Dual Xeon עם 128 ג'יגה (עדיף יותר, תלוי בכמות ה-Clients וכו') מבוסס לינוקס עם קרנל 4.8.7 ומעלה, עליו נרים מערכת שתהווה בעצם Target ובה ישבו לא רק הדיסקים אלא גם מספר כרטיסי רשת עם פס רחב (25 ג'יגה ומעלה או Infiniband). הכרטיסים יחוברו למתג תואם ומשם יחוברו לשאר השרתים שאנו מעוניינים. את חלוקת ה-Volumes וכו' נעשה על ה-Linux והמערכת בלינוקס תשדר זאת דרך ה-ROCE כבלוקים (אפשר עם שילוב TCP/IP, אפשר גם בלי אבל אז יתחילו הצרחות ממחלקת ה-IT) וה-Initiator בשרתים יתחבר ל-Target (יהיו גם אפשרויות אותנטיקציה, הצפנה וכו'). שרתים ישנים יוכלו להעלות את ה-Initiator לדוגמא דרך IPXE (או PXE לחובבי טכנולוגיה קלאסית) ומשם ה-OS יעלה ויקבל תמיכה מלאה כאילו מדובר בדיסקים מקומיים.

והביצועים? אם נשווה זאת לדיסקים NVME מקומיים, ההבדל יהיה באחוזים בודדים. מכיוון שכל השיטה מעיפה כל דבר שמוסיף Latency, הביצועים נראים כאילו מדובר בדיסקים מקומיים, רק שאין צורך לבצע תחזוקת דיסקים פר שרת והכל מבוצע ממקום אחד (ומנסיון, התחזוקה לא כזו מורכבת). סתם דוגמא: גם אם שפכתם כסף והפכתם את המערכת תקשורת שלכם ל-100 ג'יגהביט, תקבלו (במספר חיבורים במקביל) קצב של 93 ג'יגהביט בקריאה, ו-40 ג'יגהביט בכתיבה. עכשיו תנסו לדמיין מערכת VDI לאלפי משתמשים ואיך זה יעבוד, וכן – יש Initiators ללינוקס, Windows ול-VMWare כבר כיום.

כמובן שחובבי מיקרוסופט לא ישארו בצד ואם הם רוצים להקים לעצמם Target מבוסס Windows Storage Server אז הם יצטרכו להמתין קצת לגירסה הבאה.

לסיכום: דיברתי כאן על דיסקים SSD, על תקשורת שגבוהה בהרבה מ-10 ג'יגהביט, על NVME-OF (ממש על קצה המזלג). הטכנולוגיה קיימת כבר כיום (חברת Mellanox  כבר דוחפת ומדגימה אותה), אבל שום חברה לא עוברת מהיום למחר לטכנולוגיה חדשה שמצריכה החלפת מתגים וכרטיסי רשת ורכישה רצינית של NVME SSD ושרתים לכך. אלו דברים שלוקחים זמן, לפעמים שנים – אבל זהו הכיוון שהשוק ל-Data Center עובר אליו. חברות סטורג' רבות ישמחו למכור לכם את הפתרון לאחסון מחר בבוקר, אבל לפחות מבחינת TCO ו-ROI (ואם החברה מוכנה לאמץ מעט ראש פתוח) אני ממליץ לחשוב על פתרון בניה עצמית. הוא הרבה יותר קל ממה שרבים נוטים לחשוב (סתם דוגמא: הוא הרבה יותר קל מאשר הקמה וניהול של שרת ZFS) והוא פתרון שיכול להיות Scale Out די בקלות וזול בהרבה אם חושבים להרחיב – מאשר פתרון קנייני.

מוגש כחומר למחשבה 🙂

על דחיית פרוייקטים והמחיר הכרוך בכך

הנה משהו שקרה לי כעצמאי לא פעם ולא פעמיים (למען האמת, הפעם האחרונה זה קרה לי השבוע): חברת XYZ, חברה גדולה וידועה, רצתה לבצע פרויקט מיגרציה משיטות העבודה הקלאסיות שהיא עובדת עם הכלים הישנים – לכלים חדשים, לעבוד ב-Agile עם CI/CD, עם GIT ועוד.

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

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

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

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

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

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

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

לכן, במידה ובוחרים כל דבר שקשור לתשתיות, פלטפורמה, או כלי עבודה שונים, בין אם הם מבוססי קוד פתוח או סגור (ההמלצה שלי תמיד היא לעבוד עם כלי שמבוסס קוד פתוח) – היא לראות האם ב-Road Map של החברה יש שדרוגים ומעבר לטכנולוגיות ומתודות עדכניות. חברה כמו VMWare לדוגמא "פספסה מעט את הרכבת" בכל הקשור לקונטיינרים ו-OpenStack, אבל גירסה 7 שתצא בהמשך תתן יכולות להרצת קונטיינרים ותמשיך לשפר את ה-VMware Integrated OpenStack שלהם. גם חברה כמו Red Hat שהבינה שקונטיינרים הולכים להיות ה"בון טון" זרקה בגירסה 3 את כל הטכנולגיה של ה-Cartridges שלהם לטובת קונטיינרים וכיום הם מפתחים לגירסה הקרובה עבודה מלאה מול שרתי Windows Server 2016 ועושה את החיים הרבה יותר קלים לשימוש בפונקציות מסויימות ע"י אימוץ kompose.io לדוגמא. לעומת זאת, חברה מסויימת מאוד גדולה וידועה (שלא אציין את שמה אך כל איש IT מכיר אותה) מציגה את עצמה כחברה עם שרותי ענן "מתקדמים" וכל מה שמקבלים כשנרשמים – הם תשתיות כאילו אנחנו נמצאים בשנת 2010 (ולסקרנים מביניכם – לא, אינני מדבר על מיקרוסופט..)

לסיכום: מעבר לטכנולוגיות חדשות ומתודות חדשות מחייב שינוי ברמת החשיבה והביצוע לא רק ברמת המפתחים וראשי צוותים, אלא גם במהירות ההחלטה אצל בכירים. כיום השיטה של "עוד שנתיים נקנה פלטפורמת ABC ונשתמש בה" לא ממש עובדת יותר כי אם אותה פלטפורמה מתעדכנת תדיר, פלטפורמת ABC שיש כיום תהיה שונה מאוד בעתיד, ומי יודע אם בעתיד לא יהיה פתרון מתחרה יותר זול עם פונקציונאליות יותר טובה? לכן המלצתי היא להקים PoC ואם מרוצים – להתחיל להקים מערכת חדשה ולאט לאט להעביר אליה אפליקציות ומפתחים מבלי לזרוק את מערכות ה-Legacy (עדיין). הימור על רכישות עתידיות כיום – כבר אינו כה שווה לעניות דעתי.

מעבר לעננים – מבחינה כספית (מאמר עדכון)

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

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

כלומר המצב הקלאסי של היום מבחינת תשתית IT אינו מתאים כל כך למעבר לענן. אם אתם כמובן רק רוצים להעביר כמה מכונות VM בשביל אתרים שיווקיים ועוד כמה דברים שיכולים להיות "בחוץ" – אז אני ממליץ לכם לבחור ב-Digital Ocean (הנה קופון של 10$ מתנה להתחלה מבלי להתחייב). עם המכונות ב-Digital Ocean אינכם משלמים עבור תעבורה מעבר לשימוש רגיל (כל מכונה מגיעה עם כמות תעבורה חודשית מכובדת לכל הדעות), אתם יכולים להוסיף דיסק קשיח בגדלים שאתם רוצים, והמכונות די מהירות ויציבות ומה שהכי חשוב – המחיר ידוע לכם מראש, כך שסביר להניח שתוכלו להעביר חלק מהתשתית לשם ללא הפתעות כספיות.

לגבי שאר המכונות, אם רוצים להעביר לענן, הדבר הראשון עוד לפני שבכלל בוחרים ספק אינטרנט, הוא למדוד כמה משאבים האפליקציות באמת צריכות. נניח ויש לכם אפליקציית JAVA או דוט נט והגדרתם VM עם 2 ליבות ו-16 ג'יגהבייט זכרון. השתמשו בכלים הסטטיסטיים של הוירטואליזציה כדי "לחפור" בהיסטריה של אותו VM האם באמת יש שימוש ב-2 ליבות וב-16 ג'יגהבייט זכרון או שאולי מכונה זו לדוגמא יכולה להסתפק בליבה אחת ו-8 ג'יגהבייט זכרון.

דוגמא נוספת: אפליקציות כמו שרתי Web שפותחים עשרות או מאות תתי-תהליכים בהתאם לכמות החיבורים. נניח שבניתם שרת Web גדול שיקבל כמות גדולה של משתמשים כדי להפעיל אפליקציית Web שהם צריכים ויצרתם לכך 2 מכונות עם 8 ליבות וירטואליות ו-32 ג'יגהבייט זכרון בכל אחת מהמכונות. האם פתרון של 4 מכונות קטנות יותר (2 ליבות ו-8 ג'יגה זכרון) כשמאחוריהן עומד Load Balancer יהיה יעיל יותר? מבחינת עבודה בתשתית ענן, 4 מכונות קטנות עולות פחות מ-2 מכונות גדולות. באמזון לדוגמא, 4 מכונות בגודל כפי שתיארתי לעיל יעלו לכם $319 ואילו 2 מכונות גדולות כפי שתיארתי לעיל יעלו לכם $631, כלומר כמעט כפול (לא כולל דיסק, Snapshots, תעבורה וכו'). גם אם נגדיל ל-6 מכונות קטנות, עדיין המחיר יצא יותר זול מ-2 מכונות גדולות.

עוד נקודה קריטית לפני מעבר לענן היא הצורך לשנות את צורת העבודה כך שבעצם האפליקציה שתרוץ תהיה החשובה והשרת והתשתית יהיו פחות חשובים. כך לדוגמא אם יש לנו אפליקציה שצריכה לקבל כמות משתנה של משתמשים שהכמות קטנה בזמנים מסויימים ומאוד גדולה בזמנים אחרים – במקרים כאלו כדאי לחשוב על העברת האפליקציה לקונטיינרים ושימוש בתשתית קונטיינריזציה בענן (ECS באמזון, GKE בגוגל או OpenShift אם אתם רוצים להריץ משלכם משהו שיותר מתאים ל-Enterprise). בעזרת תשתית זו ניתן להוסיף אוטומטית קונטיינרים משוכפלים ומכונות נוספות (שיארחו את הקונטיינרים) וכמות הקונטיינרים והמכונות תרד אוטומטית בהתאם לכמות המשתמשים באותו זמן (כמובן שניתן להגביל את כמות המכונות שיתווספו, אם לדוגמא משהו קורה שיוצר תעבורה מזוייפת, עקב תקלות וכו'). לאלו שלא רוצים קונטיינרים או לא יכולים (קוד שרץ על Windows בלבד שלא בנוי לעבוד על קונטיינר או שהחברה לא רוצה לעבור ל-Windows Server 2016) – אפשר להקים מכונות (Instances) שישוכפלו דרך מתודת AutoScale לפי כמות המשתמשים שמתחברים או לפי כמות המשאבים שנצרכים – כך שקונטיינרים או מכונות (בהתאם לסיטואציה) הן תמיד זהות וה-Data האמיתי מגיע מבחוץ (NFS או אחסון שיתופי אחר לדוגמא).

לגבי תקשורת – כמעט כל חברה שמכבדת את עצמה משתמשת כיום בסוויצ'ים מסוגים ידועים, בין אם זה Cisco, HP ואחרים. בתשתית ענן, אין סוויצ'ים לשרותכם. הכל וירטואלי דרך ה-VPC (ו-VPN אם אתם רוצים להשתמש להתחבר מספק הענן אליכם), כך שישנה עקומת לימוד קלה אך מצד שני – העלויות עצמן זניחות.

ומה לגבי סטורג'? בניגוד לסטורג' שיש אצלכם בחברה, אצל ספקי ענן אין "סטורג'" באותו מובן. ישנו File או Block Storage שאתם קונים למכונות לפי גודל שאתם רוצים, לפי IOPS שאתם מבקשים (בזהירות – בחירה לא נכונה של סוג אחסון תפציץ לכם את החשבון באלפי או עשרות אלפי דולרים!). אם יש לכם אלפי קבצים סטטיים, אפשר להשתמש ב-S3 (יש כזה לא רק לאמזון, אלא גם למיקרוסופט ולגוגל) לאחסן שם את הקבצים וכמובן אפשר לשמור לשם גיבויים, (אם כי S3 אינו File Storage רגיל עם הרשאות שיש ל-NTFS/CIFS, חשוב לזכור). ככלל, בענן מומלץ יותר לבנות לקבוצות שרתים "מיני סטורג'" משותף בינם מאשר לנסות לעשות זאת על Block Storage ענקי – זה גם יצא זול בהרבה.

נקודה נוספת שמתאימה לחברות גדולות שיש בהן תשתית ענן פרטי והן רוצות לשלב חלק מהתשתית בענן ציבורי והתקציב שלהן בנוי כך שמחלקת המחשוב מחייבת מחלקות אחרות – כדאי יהיה לכלול בתקציב מערכת CMP (או Cloud Management Platform). הסיבה לכך היא פשוטה: כשמתחילים להשתמש ב-AutoScale לגדילה דינמית, יהיה קשה לחשב כמות משאבים פר שרת, הואיל וברגע אחד לאפליקציה של מחלקה מסויימת יש 2 שרתים ולאחר שעתיים יש 20 שרתים. מערכת CMP טובה (המלצתי כאן בעבר על CloudForms) תדע לא רק לחשב את הדברים אוטומטית, אלא גם ניתן יהיה לבנות דרכה את כל תהליך הבקשה, אישורים ובניית המכונה ללא צורך בלימוד שפה סגורה או כלים סגורים (שלא בטוח אם מחר זה יהיה קיים.. תראו מה קרה ל-vCloud Air לדוגמא).

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

קוד פתוח מול קוד סגור ו"נעילת" לקוחות

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

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

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

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

הנה דוגמא: לא מעט חברות שנכנסות יותר ויותר בשימוש עננים ציבוריים "מגלים" כשהם משתמשים בלינוקס ומערכות CI/CD את האוטומציה, ותתפלאו – חברות רבות לדוגמא עד היום לא הכניסו שום אוטומציה. יש פלטפורמות אוטומציה רבות ללינוקס כמו Chef, Puppet, SALT ובוודאי עוד כמה – אולם אני ממליץ ספציפית על Ansible מכמה סיבות:

  • הקוד של "המנוע" – פתוח לחלוטין וכתוב ב-Python.
  • אין צורך ב-"שרת" Ansible. כל הפעילות היא Serverless לחלוטין.
  • הכתיבה של ה"תסריטים" (או Playbooks איך שזה נקרא ב-Ansible) היא פשוטה ולוגית. המשתמש יכול תוך שעה שעתיים אחרי שהוא קרא את התיעוד לכתוב דברים בסיסיים שיכולים לרוץ על המכונה שלו ומכונות אחרות, כך שעקומת הלימוד – היא די קטנה.
  • יש לכם שרתי Windows? אולי הגיע הזמן גם ששם תהיה אוטומציה? אז ל-Ansible יש גם מודולים ל-Windows, בין אם מדובר להתקין קבצי MSI, להגדיר IIS, להעתיק קבצים, פעולות דוט NET, ניהול משתמשים וקבוצות ודברים נוספים. העלות לחברה? יקרה מאוד .. אפס שקלים.
  • מחפשים ממשק Web? אתם יכולים לרכוש את Ansible Tower (וביחד עם זאת לקבל תמיכה רשמית מ-רד-האט) או שאתם יכולים להשתמש בממשק וובי אחר (ויותר בסיסי) בקוד פתוח שנקרא Ansible Semaphore.
  • חושבים לעבור לאוטומציה אחרת מסיבה כלשהי? לרוב המתחרים יש כלים אוטומטיים להעביר את ה-Playbooks שכתבתם אל המערכת החדשה (אם כי עדיין לא נתקלתי בחברה שעברה מ-Ansible למערכת אחרת).

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

אותו הדבר גם בכלים לניהול סביבת חיים (Life Cycle) של קונטיינרים וסביבות המורכבות מעננים פרטיים וציבוריים. ניקח לדוגמא את קטגוריית ה-CMP (כלומר Cloud Management Platform). בתחום זה יש מתחרים רבים, החל מ-VMWare עם ה-vRealize לגרסאותיו, RightScale, ועוד. האם פלטפורמות אלו מבצעות את מה שהן מבטיחות? בהחלט! אולם אם תפסיק לשלם את התשלום החודשי או השנתי, תיתקלו באחת מהסיטואציות הבאות:

  • במקרים כמו של RIghtScale – אתה "בן ערובה", כל עוד שתשלם – הכל עובד. הפסקת לשלם, תתחיל לבנות מחדש את כל מה שבנית – על מוצר אחר.
  • במקרים כמו vRealize אם אתה מפסיק לשלם, המערכת לא תתעדכן לשרותים והגדרות חדשות של עננים ציבוריים, OpenStack ואחרים, אין תמיכה ואין עדכונים לגרסאות חדשות.

לעומת זאת, במוצר כמו CloudForms שנותן לך לבצע CMP (כולל כמובן עמידה ברגולציות וכו'), אם לא בא לך לשלם יותר, אתה יכול לייצא ולייבא את ההגדרות, הקבצים והתכנים לגירסת הקוד הפתוח (ManageIQ) בדיוק כמו שאתה יכול לעבור מ-RHEL ל-CentOS מבלי לאבד פונקציונאליות או תאימות. כשזה מגיע לקונטיינרים, אתה יכול לעבור מגירסת OpenShift מסחרית ל-OpenShift Origin שמבוססת על Kubernetes כך שבעצם למעט שרותי תמיכה (שאותם תוכל לקבל מצד ג' בין כה), אינך מפסיד דבר. להיפך: אתה שומר על כל העבודה שהצוות ביצע ואפשר לאחר המרה לגירסת קוד פתוח – להמשיך לעבוד כרגיל.

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

שבוע טוב 🙂

על קונטיינרים ואבטחה

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

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

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

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

  • אינטל מציעה את Clear Container (בגירסה 2.1.4 ששוחררה לאחרונה). היתרון של Clear Container בהשוואה לקונטיינרים של Docker הוא בכך שכל קונטיינר של Clear Container הוא בעצם מכונה וירטואלית (VM) שבתוכה מותקנת ורצה האפליקציה, משמע – בשביל להריץ Clear Container, תצטרכו להריץ זאת על Bare Metal (כלומר על "ברזלים") בלבד ולא על VM (כן, יש כמובן Nested Virtualization לכל תוכנת וירטואליזציה, אבל אף חברה לא תשתמש בזה באופן רציני בפרודקשן לדוגמא), כך שבעיה ראשונה שאני רואה – היא ששום חברה לא תסכים שמערכת תקים מכונות VM "על הברזל" בלי מערכת שתנהל את אותם VM מבחינת משאבים, ניטור ובכלל – ללא פתרון כמו vCenter שיש מ-VMWare למכונות VM – אף אחד רציני לא יכנס לזה.
    האם הפתרון של אינטל יכול להשתמש ב-Kubernetes? כן אבל זה ממש לא מוכן לפרודקשן.
  • Kubernetes בעקרון נוקט שיטת אבטחה של "הכל סגור". בברירת המחדל, כאשר אתה מקים קונטיינרים או POD, אינך יכול לגלוש אל האפליקציה שרצה בקונטיינרים או ב-POD ועליך "לחשוף" פורטים מסויימים או להשתמש ב"שרות חשיפה" כמו LoadBalancer או NodePort (שמאפשר לפתוח פורטים מסויימים שיתחברו אל ה-Load Balancer החיצוני שלכם) או ClusterIP, אך החסרון ב-Kubernetes הוא שזו מערכת Multi Platform שאינה מכירה בחלק מתכונות אבטחה שה-Kernel והמערכת יכולים לתת (כמו SELinux – גם בגירסה הנוכחית Kubernetes עדיין לא ניתן לעבוד עם זה). Kubernetes מכיר כמובן ב-namespaces ו-cgroups כדבר שנותן אבטחה, אבל לחברות רבות – זה לא מספיק.
  • OpenShift מכיל את Kubernetes ומערכת Openshift בעצם "עוטפת" את Kubernetes ומוסיפה לו בדיוק את הדברים שחברות מחפשות מבחינת אבטחה. כך לדוגמא אין אפשרות להריץ התקנת Openshift על שרתים מבלי להפעיל SELinux ו-NetworkManager כך שמראש המערכת מקימה קונטיינרים ושאר דברים בצורה מאובטחת כברירת מחדל.
  • מה עם Mesos? אני לא מומחה ב-Mesos אבל לפחות לפי כמה שהכרתי אותו, ישנה אבטחה ברמה של הקמת ותקשורת בין קונטיינרים (עם Auth), אבל אינני רואה שם שום דבר שיכול בעצם למנוע מפורץ שנמצא בקונטיינר – "לצאת החוצה", כלומר הכל תלוי בבנייה ידנית שלך לקונפיגורציות של הקונטיינר, שימוש בתכונות אבטחה של ה-Kernel (ראו לינק ראשון בפוסט זה) וכו'. אין SELinux, AppArmor שיכולים למנוע דברים גם אם המשתמש השיג root מקומי בתוך הקונטיינר.
  • לגבי Docker-Swarm: אנשים לא אוהבים שאני אומר את זה, אבל מבחינת אבטחה ב-Docker Swarm, אין ממש הרבה. כן, אתה יכול לבנות רשת מוצפנת (IPSEC), אבל מה זה עוזר אם מישהו נכנס לקונטיינר ויש לו עכשיו גישה לקונטיינר עם ה-DB? זה נחמד שיש הצפנה אבל הפורץ נכנס אחרי שיש הצפנה והרשת בין הקונטיינרים פועלת באופן שקוף (כבר בוצע Authentication). אז נכון, הוא לא יוכל לפתוח כניסות חדשות, אבל הוא בהחלט יכול להשתמש בכניסות קיימות (פורטים) ואולי לא לגרום לנזק לכל המערכת אלא רק לקונטיינרים שאליהם הקונטיינר שהוא נכנס מחובר. בקיצור, לדעתי האישית לגבי Docker-Swarm, הוא נחמד, אבל אין לו מספיק עבודה רצינית על אבטחה.

לסיכום: האם Docker עצמו יכול להיות מאובטח? בהחלט, אם אתה מתכנן להריץ מספר קונטיינרים קטן ללא Scheduler ואתה מוכן לעשות את העבודה הנוספת להגן על הקונטיינרים (הם לא מספיק מאובטחים בברירת מחדל! אם אתה מחפש להריץ קונטיינר עם פורט 80 החוצה, אתה ממש לא חייב להריץ את הקונטיינר כ-root). אם אתה משתמש ב-Kubernetes, אז יש לך Best Practice כיצד להגן על הקונטיינרים/POD וכו' ברמת התקשורת ואותנטיקציה, אבל Kubernetes עדיין לא יודע איך להגן בתוך הקונטיינר נגד פורץ. הפתרון של אינטל הוא נחמד אבל עד שיהיה פתרון לאינטל ברמה שזה רץ על VM או בשילוב עם מערכת Management ל-VM (כמו vcenter ואחרים) אף חברה רצינית לא תיקח זאת.

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