לקצר דרכים – ולסבול מאוחר יותר

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

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

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

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

אחד הנזקים, לדוגמא, קשור לשדרוג. אם מישהו הקים מערכת Kubernetes והוא ינסה לשדרג אותה – סביר להניח שהוא יתקל במספר שגיאות, שאם הוא לא מבין בתחזוקה והקמת הפלטפורמה, יכולים פשוט להשבית לו את המערכת, וכנ"ל לגבי הרצה של כל מיני קונטיינרים חיצוניים תוך שימוש בקבצי YAML שאיש מהחברה לא עבר עליהם: צריך לזכור שקוברנטיס לא שואל יותר מדי שאלות לפני הטמעה של קבצים כאלו (kubectl apply -f something.yaml).

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

חג שמח.

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

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

(הערה: לפני כשנתיים כתבתי את הפוסט הזה על Kubevirt. מאז דברים רבים השתנו ופוסט זה הוא פוסט עדכון לכלי).

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

אפליקציית Kubevirt מרחיבה בעצם את Kubernetes/OpenShift ומוסיפה למערכת תמיכה בקונטיינרים מסוג נוסף: קונטיינר שמריץ VM. כך בעצם אפשר לקחת VM מהדוגמאות לעיל ו"להכניס" אותו לתוך קונטיינר, כך שנוכל להריץ אותו כמו שאנחנו מפעילים קונטיינרים נוספים, ובכך נוכל להשתמש באפליקציה שרצה ב-VM, נוכל לשכפל את הקונטיינר לפי פרמטרים שנרצה, נוכל לשדרג את הקונטיינר ועוד ועוד.

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

רוצים לשחק עם זה פה ועכשיו מבלי להקים Kubernetes שלם? בשמחה! כנסו ללינק הזה ואתם מוזמנים לאחר מכן להיכנס ללינק הזה כדי להכיר את לשדרג מכונות VM בתוך קונטיינרים.

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

קונטיינרים וגדילה, צרכים מול מציאות

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

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

תובנות על OpenShift בחברות גדולות

יוצא לי בלא מעט מקרים לתת יעוץ לחברות גדולות לגבי עניין המעבר ל-Devops, שימוש בקונטיינרים, Docker, שימוש ב-Jenkins ושאר כלים. כמובן, כמו תמיד, בחברות גדולות, אף אחד אינו רץ להטמיע טכנולוגיה זו או אחרת רק בגלל שחץ בן חמו (או נציגי Presale של רד-האט, אין לי קשר אליהם) המליץ עליה. יחד עם זאת, בדרך כלל ההמלצה שלי לפני שמרימים אפילו PoC של OpenShift – אני מבקש מהחברה שתתן לי להיות "הטיפש" – להיות עם צוות שינסה את הדברים החדשים ובעצם ללמוד את התהליכים שהצוות משתמש בהם – החל מכתיבת קוד, שימוש ב-SCM, קומפילציה, טסטים, תהליכים נוספים עד לתוצר הסופי (קבצים בינאריים, Artifacts וכו').

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

  1. ניהול קוד (Source Code Management – SCM)
    ברוב המקרים שישבתי לפגישת היכרות ושיחה על המערכות הקיימות, בד"כ מערכת ניהול הקוד היתה TFS של מיקרוסופט או בחלק מהמקרים SVN. מקומות בודדים הכניסו איזו "תת מערכת" של GIT (בשימוש של Gitlab או BitBucket).
    הבעיה: שום מערכת קונטיינרים המבוססת על Kubernetes לא תומכת באופן רשמי לא ב-TFS ולא ב-SVN. כולן תומכות באופן טבעי ב-GIT.
    הפתרונות שיש הם מאוד עקיפים:
    עם TFS יש פתרון די עקיף לבעיה כפי שמוסבר כאן.
    עם SVN הפתרון הוא למשוך את הקוד למכונה מקומית שמחוברת לשרת GIT, ולאחר מכן לבצע Commit, Push לשרת ה-GIT המקומי. זה פתרון די "מכוער" ובעייתי מכיוון שאם מישהו שכח להוריד ולהעלות קוד ל-GIT, ה-Build יהיה בעייתי. אגב, שרת SVN הוא יחסית קל מאוד להמרה ל-GIT, במידה והחברה מעוניינת לעבור ל-GIT.
  2. מכונות Windows ולינוקס ביחד.

    לא מעט חברות גדולות כותבות קוד ל-Windows וסקריפטים ל-Windows (ראיתי גם מקרים של Build ל-JAR/WAR שכתובים ב-Batch file), וכאן ישנה בעיה מהותית – Kuberenetes בעצמו לא רץ בצורה טובה על Windows והפתרון שיגיע בשנה הבאה יאפשר גם ל-Kubernetes וגם ל-OpenShift להשתמש ב-Nodes שהם גם Windows וגם לינוקס (אם כי שרתי ה-Master וה-Infra יצטרכו להיות מבוססי לינוקס).
    עד אז תהיה בעיה לקמפל קוד בצורה יציבה של דברים כמו DOT Net (כדאי לעבור ל-Dot Net Core שנתמך ורץ על לינוקס), ויהיה צורך להמיר קבצי batch ל-shell כדי לקמפל את הדברים על Windows.

  3. בחירת אסטרטגיה ב-OpenShift
    באופן עקרוני, שימוש ב-OpenShift מחייב בחירת אסטרטגיה, ו-OpenShift תומך ב-4 אסטרטגיות פופולריות: Docker, Source to image (S2I), Jenkins Pipeline ו-Custom (שהוא מאוד מתקדם וברוב המקרים לא יהיה בו שימוש אלא במקרים מיוחדים ששאר האסטרטגיות אינן עונות על כך)
    1. אסטרטגיית Docker מאפשרת שימוש ב-Images קיימים מבחוץ (ממקומות כמו Docker Hub לדוגמא) ושניבנו פנימית כחלק מהרמת אפליקציות. יש עם האסטרטגיה הזו 3 בעיות:
      1. רוב ה-Images שתמצאו בחוץ לא יפעלו עם OpenShift כי הם רצים כ-root ו-OpenShift בנוי בראש ובראשונה לאבטחה הדוקה ולכן הוא חוסם מיידית הרצה של Images כאלו (אפשר לבטל זאת אבל אז מישהו יחטוף על כך ממחלקת אבטחת מידע)
      2. בלא מעט מקרים שוחררו Images שמריצים מספר אפליקציות במקביל בתוך אותו Image וזה הורס כל דבר שקשור לגדילה רוחבית (Scaling) ולכן לא מומלץ להשתמש ב-Image כזה.
      3. טכנית, מבחינת אבטחה בקונטיינרים, דברים צריכים לרוץ רק ב-Foreground ולא ב-background ולכן קונטיינרים שיריצו דברים ב-background (שרותים כמו nginx, apache, postfix ועוד ועוד) – הקונטיינר "ימות" לאחר זמן קצר והמערכת תנסה להקים אותו שוב ושוב, מה שיצור loop (במיוחד אם מופעל Replication Controller – RC).
    2. אסטרטגיית Source to image (כלומר S2I): עם אסטרטגיה זו מערכת OpenShift מושכת ImageStream (כלומר Image "שלד"), יוצרת Image חדש שאליו היא "שופכת" את הקוד מ-GIT, מבצעת שינויים שצריך (הרשאות, התקנת קבצים נוספים כמו דרך PHAR ב-PHP או NPM עבור Javascript ועוד ועוד), ולבסוף בונה Image סופי שאותו המערכת מריצה ומקימה POD עם קונטיינר המכיל את ה-Image. באסטרטגיה זו ניתן "לקשור" (דרך Webhook) בין REPO של GIT לבין אפליקצייה ב-OpenShift וברגע שיש שינוי ב-GIT, המערכת תבנה אוטומטית Image חדש וכשתסיים היא תוריד את ה-POD הקיים ותפעיל מיידית את ה-POD עם הקונטיינר החדש (ניתן כמובן לבצע Blue/Green Deployment – פרטים כאן וזה קיים לא רק ברמת אפליקציות אלא גם ברמת מכונות)
    3. אסטרטגיית Jenkins: עם אסטרטגיה זו אנחנו מגדירים הכל מראש: מאיפה הקוד ימשך, מה ה-pipelines וכו' וכו' ו-OpenShift יקים בכל פעם קונטיינר Jenkins, יקמפל, יריץ את ה-pipelines, יפזר מה שצריך לפזר, יבנה Image חדש ויריץ POD עם קונטיינר המבוסס על ה-Image החדש. הדרך הזו יכולה להתאים לאלו שכבר משתמשים ב-Jenkins על לינוקס.

ישנם עוד חלקים הקשורים להקמת מערכת שיש צורך לערב הן את מחלקת אבטחת מידע והן את צוות ה-Storage. בגופים פיננסיים ובטחוניים יהיה צורך לשים דגש על שרתי Registry מקומיים (לחשיפה מופחתת לאינטרנט, אבל עדיין יש צורך לשאוב קבצי Image, בלי זה אי אפשר להקים שום דבר, ואין זה משנה אם מדובר ב-OpenShift או בכל מערכת אחרת מבוססת Kubernetes), שילוב עם Active Directory, הרשאות וכו' (מובנה ב-OpenShift, לא קיים ב-Kubernetes) ועוד דברים רבים.

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

על 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 שחברות דורשות.

כשהאתר דורש יותר ויותר משאבים בפתאומיות

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

הבעיה הגדולה מגיעה כשיש כמות גולשים גדולה שמגיעה במכה אחת, בין אם לכמה דקות או לכמה שעות או כמה ימים. תחשבו לדוגמא על חברה שיש לה אתר מסחרי ובשבוע הקרוב מתקיים מבצע של 20-50% הנחה על מגוון מוצרי החברה ואנשים מעוניינים לרכוש. מה עושים לקראת המבצע? זה תלוי, ובד"כ יבחרו באחת (או יותרת) מהאופציות הבאות:

  • הגדלת משאבי המכונה הוירטואלית (יותר זכרון, יותר ליבות)
  • אופטימיזציה של מערכת האתר – טיוב שאלות SQL, בניה יותר טובה של Cache, אולי מעבר ל-NGINX, שינוי PHP לעבודה כ-FPM ועוד ועוד..
  • שכפול והקמת מכונה זהה ומעל המכונות Load Balancer תוך מתן פתרון גם ל-SQL (שיטות Master/Slave, Multi Master ועוד)
  • אם אתם משתמשים בשרותי ענן כמו אמזון ושרותים כמו RDS, אולי תעברו ל-Instances יותר גדולים, אחסון יותר מהיר וכו'.

אם האתר שלכם נמצא בשרותי ענן ציבורי, בד"כ תהיה אופציה נוספת שנקראת Auto Scaling שתאפשר לכם להוסיף מכונות בהתאם לעומס (אתם יכולים לבדוק עומס על ה-CPU, עומס על הרשת, כמות זכרון פנויה וכו') ובד"כ זה פתרון טוב שעובד יפה והרבה חברות משתמשות בו. גם עניין הוספת VM לזה שקיים, ביצוע רפליקציה של SQL והוספת Load Balancer היא אפשרות טובה כשצריכים אותה.

אך לשיטות האלו יש מספר בעיות:

  • אם האתר עצמו מאוחסן ב-NFS או OCFS2 לדוגמא, תקלה בקוד או חדירה ע"י פורץ ושינוי הקוד (כמו במקרים של Defacement) – תשפיע על כל השרתים שלך. כנ"ל בעת שדרוג -אם השדרוג לא מצליח, שום אתר לא באוויר וכולם מקבלים את אותה שגיאה. בנוסף, אתם מייצרים צוואר בקבוק חדש מכיוון שכל פעם שהאתר צריך ולו את הקובץ הכי קטן – הוא צריך לבצע קריאה ל-Storage, ו-NFS לדוגמא פשוט לא מתאים לזה, אתם יוצרים צוואר בקבוק חדש.
  • מחיר – להוסיף עוד VM + Load Balancer זה לא כזה יקר (לעסק שמתפרנס [גם] מהאינטרנט לדוגמא), אבל כשאתה צריך להוסיף עוד 20 מכונות VM העסק מתחיל להיות קצת יקר וזה לא חשוב אם מדובר בספק אירוח ישראלי או בענן ציבורי.
  • תחזית: כמה הולכים להיכנס לאתר? אתה לא יודע. אתה יכול להעריך בהערכה גסה, אבל אתה לא תדע אם יכנסו פחות או יותר ואם אנשים לא עפו מהאתר או לא הצליחו להיכנס בגלל שהשרתים היו עמוסים, בגלל תקלה, ובקיצור – עניין הניחוש הזה קשה כמו לנחש כמה אנשים יגיעו לחתונה..

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

מכונות VM הם פתרון טוב, אבל יש כיום פתרון יותר טוב והוא כמובן קונטיינרים: אפשר להקים קונטיינרים שיריצו את הקוד PHP, קונטיינרים שיתנו את שרות ה-WEB עצמו, קונטיינרים ל-SQL, קונטיינרים ל-Cache וכו'. הקונטיינרים עצמם אינם דורשים משאבים גדולים – מכיוון שהקונטיינר לא צריך את כל מערכת ההפעלה מותקנת בו אלא אך ורק חלק שצריך להריץ אפליקציה ספציפית, אפשר להפעיל קונטיינרים עם כמות זכרון קטנה (נניח 512 מגהבייט זכרון) בהתאם לצרכים. בנוסף, קונטיינרים הם דבר שניתן לשכפל מאוד מהר (בניגוד ל-VM – קונטיינר משוכפל בשניות). כך בעצם ניתן "להמיר" את האתר שלך למספר קונטיינרים שישוכפלו בין מכונות VM (או Instances), תקבל Load Balancer בחינם, והמערכת תדע לגדול ולקטון בהתאם לצרכיך.

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

  • להקים מספר קונטיינרים שיתפזרו בין VM שונים, יאוחדו לקבוצות וכך המערכת תוכל "לדבר" בין החלקים
  • אם יש תקלה בקונטיינר מסוים, אפשר להרוג אותו והמערכת תקים מיד קונטיינר אחר זהה, כך שאם לדוגמא מישהו פרץ לקונטיינר מסוים, הפגיעה היא מקומית (תלוי כמובן בהגדרות היכן נמצאים הקבצים שנפגעו – בקונטיינר או על NFS/OCFS2 וכו'), ניתן להרוג את הקונטיינר ולהמשיך (כדאי כמובן לתקן את הקוד)
  • עם מערכת כמו Kubernetes ניתן לבצע תהליך הטמעה של גירסה חדשה כך שעדיין ישמרו גירסאות ישנות ולעבור לחדשות לפי קצב שיוחלט (לפי גילוי באגים ותיקונם וכו') וכך יחסך מצב של השבתת מערכת רק כי צריך להחליף גירסה.
  • אפשר להשתמש בהפצות לינוקס אחרות (או בקונטיינרים של Windows – אם אתם מריצים WIndows Server 2016) בתוך הקונטיינרים כך שאין זה משנה מה ההפצת לינוקס שמותקנת על ה-VM עצמו.
  • אין צורך בהגדרות זהות פר VM – ישנה מערכת ETCD שדואגת שההגדרות בין ה-Nodes יהיו זהות לחלוטין בין אחת לשניה באופן אוטומטי.
  • יעילות פר VM – הפצות כמו Atomic, CoreOS, RancherOS ואחרות – ניתן להתקין אותן על ה-VM ובכך לחסוך RAM שתפוס בד"כ על ידי הפצת הלינוקס ב-Node עצמו (אחרי התקנת הפצות כפי שציינתי לעיל – הזכרון התפוס נע בין 50-100 מגהבייט בלבד וה-Node גם עושה Boot מאוד מהר) ובאותו זכרון פנוי ניתן להשתמש לטובת הקונטיינרים.
  • על אותה מערכת Kubernetes ניתן גם להעלות קונטיינרים אחרים עם גרסאות שונות של האתר, לא צריך VM חדש לשם כך.
  • ויש עוד יתרונות.

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

אפשר כמובן לעבוד על Kubernetes בלבד (ויש כמובן גם API – שהוא יותר "client") לשפות שונות כמו PHP, Python, דוט.נט ועוד, אולם אם בחברה יש מספר מפתחים לאתר, אני ממליץ להשתמש בכלי כמו OpenShift Origin כדי לבצע את כל הדברים ב-Kubernetes (כולל דברים ש-Kubernetes לא עושה כמו בניית קונטיינרים, עבודה כמשתמשים וקבוצות ועוד) או בכלי אוטומציה אחרים לבצע הן את הדברים דרך Kubernetes והן את ה"מסביב".

מבחינת עבודה עם Kubernetes – המערכת הזו כתובה ופועלת מעולה – כשזה נמצא על ספק ענן ציבורי כמו גוגל או אמזון. אם זה בתשתית של ספק אירוח מקומי, יש צורך לבצע "שמיניות באויר" בכדי להתחבר למכונות הללו מבחוץ כי היא פשוט בנויה לשימוש פנימי כאשר תקשורת מבחוץ מגיעה דרך תשתית ספק הענן. ב-OpenShift לעומת זאת, פתרו זאת עם HA-PROXY ועם ניתוב חכם כך שאין צורך להסתמך על שרות כמו Load Balancing של ספק ענן חכם ואפשר להשתמש בפתרון המובנה.

מבחינה טכנית, לאלו שיש כבר אתרים גדולים, אין היום שום כלי למיטב ידיעתי שיכול לעשות לאתר שלכם המרה ממצב שהוא רץ על Shared Hosting או VPS/VM או Instance למצב קונטיינר. את הדברים יש צורך לבצע ידנית ויכול להיות שיהיה צורך לבצע מספר שינויים קטנים בתהליך העבודה (שימוש ב-GIT, הפרדה בין תהליכים ועוד) וכמובן יש צורך במחשבה ובבניית תהליך כיצד להכניס את OpenShift לעבודה אצלכם (כך שלא מדובר במשהו שמבצעים בכמה שעות או ביום עבודה אחד).

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

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

הכלים שמתאימים לניהול תשתיות וירטואליזציה

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

כיום – הכל השתנה. המייל שלכם, סביר להניח שיושב אצל ספק ענן כלשהו (כמו מיקרוסופט או גוגל), אולי יש לכם גם תשתית וירטואליזציה בענן, אולי אתם משתמשים גם בכמה שרותי SAAS שונים לאחסן דברים חיצונית או לקבל שרותים חיצוניים מספק כלשהו בתשתיות SAAS/PAAS/IAAS וכו' ובקיצור: יותר ויותר דברים כבר אינם בבעלותכם הפיזית המלאה ואתם בעצם משלמים על שרותים שונים כשמי שמנהל את הברזלים לאותם שרותים – הוא אותו ספק, לא אתם. לכם מעתה יש "תשתיות" שמורכבות מדברים שיש לכם ב-DC המקומי ועוד דברים חיצוניים.

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

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

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

ענן פנימי

יש לכולם כיום תשתיות וירטואליזציה כמו vSphere או Hyper-V ואותן תשתיות עושות את העבודה בצורה לא רעה, אבל לפעמים צריך להתרחב – להוסיף דברים כמו קונטיינרים, ושרותי AAS שונים פנימיים, בין אם זה DB, Storage, imaging ועוד ועוד והפתרונות שהזכרתי בהתחלה לא בנויים לתת את השרותים הללו (אם שמוליק מהפיתוח צריך DB של 2 ג'יגהבייט, עם הפתרונות שהזכרתי בהתחלה תצטרך להקים לו VM או להקצות לו ב-DB הראשי מקום, והקצאה לטסטים לדוגמא ב-DB הראשי זה לא בדיוק רעיון טוב).

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

מערכת Open Stack קיימת כקוד פתוח שניתנת להורדה כאן ובנוסף היא קיימת כפרויקט RDO למשתמשי Fedora/CentOS/RedHat. שימו לב, המערכת מאוד מורכבת ואינה מקבלת תמיכה רשמית.

גירסת OpenStack מסחריות קיימות ל-Red Hat, ל-SuSE וגם לאובונטו. כל חברה דורשת מחיר אחר ואתם יכולים לבחור לפי ההפצה המועדפת עליכם.

קונטיינרים

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

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

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

ישנם פתרונות רבים בקוד פתוח לבצע את הדברים הנ"ל אולם הפתרון הכי פופולרי הוא Kubernetes שמאפשר דרך ה-Shell/CLI לעשות את הדברים הללו וכמובן ניתן להכניס את הכל לסקריפטים. Kubernetes מתאים למי שמכין קונטיינרים בעצמו / משתמש בקונטיינרים שניבנו ע"י אחרים, אולם Kubernetes אינו כולל את כל ה-Life Cycle של קונטיינרים ואינטגרציה עם כלי CI/CD, ממשק משתמש טוב, ניהול משתמשים ופרויקטים ועוד פונקציות רבות ש-Kubernetes אינו כולל.

לפיכך הכלי שאני ממליץ לדברים אלו הוא OpenShift (גירסה מסחרית) או OpenShift Origin (גירסת קוד פתוח) – של רד-האט. כלי נוסף שאני ממליץ עליו הוא Rancher שיתרונו הגדול על פני OpenShift הוא בכך שזו מערכת Multi Platform.

ניהול תשתיות וירטואליזציה

בין אם יש לכם בחברה OpenStack, קונטיינרים, vSphere, Hyper-V, או תשתית בעננים ציבוריים כמו Amazon AWS, Google Cloud Platform או Microsoft Azure – ניהול דברים אלו מצריך כלי ניהול נפרדים (או במקרה של כלי אוטומציה – כתיבת חלקים נפרדים).

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

חשוב לציין – Cloudforms הוא "כלי מתרחב" – כלומר זהו כלי שניתן להרחבה לא רק ע"י תוספים אלא ע"י כתיבה ב-YAML כל מיני פונקציות נוספות שמתאימים לארגון. רבים מנסים להשוות את Cloudforms ל-"vcenter עם תמיכה בתשתיות נוספות", אך השוואה זו מוטעית. Cloudforms יכול להתרחב בצורה משמעותית בהשוואה ל-vcenter/VCSA והוא כולל מערכת שלמה לביצוע Orchestration, Life Cycle, עמידה בסטנדרטים פנימיים ועוד.

תשתית וירטואליזציה מתחרה

מקודם התייחסתי ל-OpenStack שיכול להתאים להקמת ענן פרטי בחברה, אולם לעיתים חברות מחפשות מערכת "פחות מפלצתית", משהו שיותר מזכיר את ה-vSphere או את ה-Hyper-V. הסיבות יכולות להיות קשורות בתקציב קטן או שאין תקציב גדול להרחבת תשתית וירטואליציה ב-R&D, מעבדות וכו'. איך אמר לי לקוח פעם "תבנה לי מטוס בתקציב של רכב סובארו".

כולם מכירים כמובן את VirtualBox, אך כלי זה אינו מתאים לסביבה מעבר לכמה מכונות VM בודדות שרצות על ברזל יחיד. הפתרון הכי טוב שיש בקוד פתוח הוא oVirt (גירסת קוד פתוח) או RHEV (בגירסה המסחרית) של רד-האט. שתי המוצרים מבוססים על פלטפורמת KVM בלינוקס והמוצרים יודעים לא רק להתממשק לסביבות וירטואליזציה אחרות (במידה וצריך), אלא לעשות את כל מה שמצפים מתשתית וירטואליזציה: Live Migration, Cloning, High Availability, Fault Tolerance, Load Balancing ועוד.

סיכום

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

קונטיינרים: ה"קרב" בין OpenShift ל-Docker DataCenter

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

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

בימים האחרונים השתמשתי בגירסת ה-Trial ל-Docker DataCenter (ובקיצור: DDC), למדתי אותה, הקמתי אותה אצלי ב-LAB הקטן שלי. השתמשתי ב-Swarm שבתוכו (שזה בעצם ה-Scheduler ועוד) ובשאר הכלים שגירסת ה-Enterprise כוללת. הייתי צריך להקים כ-5 מכונות וירטואליות (Nodes) כדי שהדברים יעבדו, עוד לפני שיכלתי להקים קונטיינר אחד. בסופו של דבר, המערכת עבדה בצורה טובה, יחסית. (אם כי נתקלתי באיזה באג או 2 שמצאתי להם "עיקוף").

מבחינת מחיר: DDC אינו זול. מחיר גירסת ה-Enterprise פר Node הוא 1500$ לשנה (כפי שניתן לראות כאן, גללו לאמצע הדף). על מנת להרים מערכת Enterprise, תצטרכו לרכוש לפחות 5 רשיונות: manager, registry, cache – אלו הם חלקים שרצים כ-VM נפרדים ב-DDC, עוד Node ל-Worker (שעליו בתכל'ס רצים הקונטיינרים) ותצטרכו מינימום עוד אחד אם אתם רוצים שרידות ועמידה בעומסים. (אפשר כמובן להריץ את החלקים השונים כקונטיינרים, אבל Docker ממליצים להרים את החלקי ניהול כמכונות VM נפרדות), כלומר אנחנו מתחילים במחיר של 7500$ לשנה. כל Node נוסף – עוד $1500.

הבעיות עם DDC פחות קשורות לבאגים או תכונות, אלא בעיה כללית שיש לחברת Docker בכל מה שקשור ל-Enterprise. הבעיה הראשית שלהם מאוד מזכירה את ההתנהגות של חברת רד-האט בצעירותה: רד-האט היתה משחררת גירסת לינוקס חדשה כל שנה ושוברת את התאימות הבינארית בין גירסה לגירסה. גירסה 5 לא תאמה לגירסה 4, גירסה 6 לא תאמה ל-5, גירסה 7 היתה עולם אחר לגמרי שלא תאם לגרסאות קודמות מבחינה בינארית. כלי ניהול הגיעו ונעלמו כלעומת שבאו, ויצרני תוכנה וחומרה התעצבנו מכל המהלכים הללו והן הביעו את דעתן בשיחות מול רד-האט ובעיתונות הטכנולוגית. לקח לרד-האט במשך שנתיים להבין שהדרך הזו אינה מקובלת לא על יצרני תוכנה וחומרה, ולא על Enterprise וכך נולדה משפחת ה-RHEL (כאשר כל הפיתוחים ושבירת התאימות עברו לגירסת Fedora), וכיום RHEL ניתנת עם תמיכה ועדכונים ל-10 שנים. ב-Docker לעומת זאת, שבירת התאימות היא עניין שבשגרה לגבי מוצרי הקוד פתוח, ומה לגבי הגירסה המסחרית שחברות משלמות? אה, לזה הם מוכנים לתת עדכונים ותיקונים למשך .. שנה אחת. מי בדיוק ה-Enterprise שמוכן לקנות מוצר שיהיה לו תמיכה ותיקונים לשנה אחת בלבד ובשנה אחר כך ב-DDC תישבר התאימות? שאלה מעולה!

ב-רד האט, למודי הנסיון, הדברים שונים לחלוטין.

ברד-האט יודעים שחברות לא ששות כל כך מהר לשלם עבור מוצרים שמיועדים לסביבות פיתוח, טסטים, QA, סביבות אוטומציה וכל דבר שאינו פרודקשן, ולכן רד האט אומרת: קחו את מוצר ה-OpenShift Container Platform (ובקיצור: OSCP) בחינם או את גירסת OpenShift Origin היציבה (נכון להרגע זו גירסה 1.4, כל עוד אתה מארח את הכל על התשתית שלך או תשתית הענן שלך), רק תזכור – זה לא מקבל תמיכה! כלומר את OSCP אפשר להרים על הלאפטופ (מספיק מכונת VM אחת או על הפצת הלינוקס במכונה ללא VM) או בשרתים הפנימיים לפיתוח וכו'. מעוניין בגירסה מסחרית עם תמיכה? הנה המחירון של Grey Matter. כפי שאתם יכולים לראות, על כל Node המחיר הוא 2724 ליש"ט ואם ה-Node הוא שרת פיזי, המחיר הוא 6810 ליש"ט (זה לפני מו"מ כמובן) עם תמיכה לשנה, ויש גם מחיר ל-3 שנים תמיכה, סטנדרט או פרימיום.

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

בסופו של יום, 2 המוצרים מציעים טכנולוגיות שונות. האחת (DDC) משתמשת ב-Swarm כדי לנהל את ה-Scheduling, Load Balancing, FT וכו' ואילו השניה משתמשת ב-Kubernetes. רוצה לדעת מי יותר פופולרי? תשאל את המפתחים ואנשי ה-Devops בחברתכם מי מכיר מה, אתה תקבל תשובה מהר מאוד מדוע Kubernetes כה פופולרית (כי היא קלה להתקנה וניהול בהשוואה ל-Swarm). ה-OpenShift של רד-האט תומך בגדילה של עד 1000 Nodes, ועד 120,000 pods. במילים אחרות, עם מערכת OpenShift אחת אתה יכול תיאורתית לארח את האתרים ואפליקציות בגדלים ענקיים!

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

Exit mobile version