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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

על קונטיינרים ו-Appliance

בעשור האחרון סייעתי לא פעם ולא פעמיים בהקמת Appliance לחברות פיתוח, כתיבת החלקים של גיבוי, עדכונים, וגם Installer כשהיה צריך. בד"כ החלק שלי היה יותר קשור לרמת ה-OS, דיסקים, הגדרות מערכת וכו' ופחות כתיבת קוד לאפליקציה עצמה.

אם יש משהו שאני יכול לאמר על Appliances זה שהחיים איתם מבחינת הכנה – אינם קלים. תמיד אפשר כמובן לכתוב איזה updater לדוגמא שיתחבר לכל מיני מאגרי חבילות (REPO) ויוריד את חבילות מערכת ההפעלה ועדכוני התוכנה וחתימות (אם צריך, נניח), אבל מה אתה עושה אם לקוח לא מוכן לחבר את ה-Appliance עקב הוראות בטחוניות באותה חברה/מוסד/ארגון? אתה צריך ליצור מעין "Delta" של החבילות סיסטם + עדכונים ולשלוח לו את זה כדי שהוא יוריד לדיסק און קי, "ילבין" ויתקין את זה.

נחשוב על סיטואציה שמתרחשת אצל כל חברה שמייצרת Appliance (בין כ-VM ובין כקופסא פיזית) – החברה החליטה שבמסגרת הגירסה הבאה של התוכנה, היא מחליפה בדרך גם את הפצת הלינוקס שלה, ולא חשוב אם מדובר בשדרוג לגירסה אחרת מאותה הפצה או במעבר מ-Ubuntu ל-CentOS. המימוש לתהליך הזה די מורכב הואיל ומדובר על דריסה של מערכת קיימת ואם זה נשבר באמצע, ללקוח יהיה Appliance במצב לא שמיש (נקרא גם Brick). מעבר לכך זה גם מאוד תלוי אם המערכת הוקמה עם Volume Management (תתפלאו כמה Appliances אין להם את זה) ושההגדרות והנתונים יושבים על Logical Volume אחד, ה-DB יושב על Logical Volume אחר וכו' וכו'. בלי זה – כתיבת השדרוג הולכת להיות מורכבת ומסובכת (מנסיון…)

וכאן בדיוק קונטיינרים יכולים מאוד לעזור בשילוב LVM (ר"צ של Logical Volume Manager). את ה-Appliance אפשר לבנות בתצורה הבאה לדוגמא (בניכוי כל הדברים הקשורים ל-Volume Groups וכו'):

  • מחיצת boot/ בגודל 1 ג'יגהבייט (זה הסטנדרט המומלץ בסנטוס 7, אגב) ללא LVM
  • LV לוגי שמכיל את ה-OS עצמו בלבד.
  • LV שמכיל את ספריות ה-DB וקבצי קונפיגורציה
  • LV שמכיל קונטיינרים
  • LV לגיבויים
  • LV שמיועד לקבצים זמניים, Cache וכו'
  • LV ספייר (ריק, לשימושים שונים במהלך חיי ה-Appliances כמו פריסת Plugins זמניים, קבצי התקנה זמניים ועוד ועוד)

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

מבחינת קונטיינרים, יהיו במערכת מינימום 2 קונטיינרים (או 3, תלוי בחברה, מה המוצר, מורכבות ועוד):

  • בקונטיינר הראשון תרוץ אפליקציית Web שמטרתה העיקרית היא ניהול ה-appliance עצמו ברמת סיסטם: עדכוני תוכנה, יצירת גיבוי ושחזור, הרצת בדיקות תקשורת, התחברות ל-AD (אם צריך) ו/או למערכות אחרות. לאותו קונטיינר אנחנו נמפה הן את ה-DB והן את תיקיית קבצי הקונפיגורציה כך ששינויים ישמרו, גם אם לקונטיינר יקרה נזק/יפול/ימחק. לקונטיינר הזה המשתמש יגש דרך כתובת ה-IP של ה-appliance אך דרך פורט אחר שאינו 80/443 ומומלץ שיהיו לו יוזרים שונים מהיוזרים שמשתמשים ב-appliance עצמו.
  • בקונטיינר השני תרוץ האפליקציה העיקרית שלנו וגם בקונטיינר זה אנו נמפה את התיקיות קונפיגורציה ואת תיקיית ה-DB. לכאן המשתמש יגיע דרך HTTP או דרך HTTPS לפי העדפותיכם כמובן (אגב, טיפ קטן לחברות שבונות appliances – תנו דרך קלה להכניס תעודות SSL).
  • אופציונאלי: קונטיינר שלישי יריץ את ה-DB וגם אליו נמפה את תיקיית ה-DB. הסיבה שאני ממליץ להפריד את ה-DB לקונטיינר אחר היא שבמקרים רבים ללקוח יש הרבה פעילות וה-Appliance מגיב באיטיות כשהוא בעומס, ולכן כדאי לחשוב על מתן אפשרות הקמת Appliance רק עם ה-DB.

היתרונות בעבודה בדרך זו:

  • יצרן ה-Appliance יכול להשתמש בכל גירסה באיזו הפצת לינוקס שירצה, מבחינת המערכת – זה בסך הכל Image שקונטיינר מריץ. האפליקציה בקונטיינר מתממשקת לתיקיה של ההגדרות וה-DB ויכולה לזהות אם ההגדרות ישנות (או הנתונים ב-DB ישנים) ולשדרגם בהתאם.
  • כשיש עדכון חרום או עדכון רגיל שאיננו החלפת גירסת Major, העדכון שירד יהיה די קטן והוא ירד בצורה מאובטחת מ-repository של היצרן דרך התשתית של docker, המערכת תעדכן את קבצי ה-image, תבנה קונטיינר חדש ותחליף את הקיים בצורה שקופה.
  • כשיש שדרוג לגירסת Major חדשה, קונטיינר אחר נותן חוויית שימוש הרבה יותר אינפורמטיבית ללקוח, הוא יכול לראות מה קורה מבחינת אחוזי הורדה, מה המערכת עושה.
  • עדכוני מערכת ההפעלה הראשית (שאינה נמצאת בקונטיינר) הם בטוחים וגם אם יש תקלה, המקסימום שיהיה צורך זה לעדכן את ה-OS המינימלי. זה לא נוגע בקונטיינרי (ההגדרות יושבות ב-LV אחר).
  • אם הלקוח גודל מחר וצריך DB עם רפליקציות וכו' – השינויים שיש צורך לבצע הם מינוריים.
  • הזמן שלוקח מגילוי תקלה בתוכנה ועד שחרור ללקוחות (לאחר בדיקה) – מתקצר משמעותית. מהרגע שהחברה שחררה עדכון, הלקוח יכול להיכנס לקונטיינר הניהול, ללחוץ על Update מבלי להוריד קבצים.
  • זמן הירידה והעליה של ה-Appliance לאחר שדרוג מתקצר משמעותית.
  • אפשר לפתוח לטובת הלקוחות ערוצים נוספים כמו testing, beta, stable והלקוח יוכל לבחור לעבור, מדובר בסופו של דבר רק בהחלפת קונטיינר (חשוב לזכור: האפליקציה של הלקוח תצטרך להתמודד עם קבצי הקונפיגורציה וה-DB מבחינת שינוי ושדרוגם)
  • הלקוח יוכל לבצע (או שהמערכת תבצע עבורה) גיבוי של הקונפיגורציה וה-DB במהירות (מדובר ב-LV snapshot שהוא חלק בסיסי בלינוקס) ו-rollback במקרה הצורך.

במקרים כמו עבודה של Offline עקב דרישות של ארגונים בטחוניים או אגף אבטחת המידע של החברה, יהיה צורך בשינויים- אבל את זה אני משאיר מחוץ למאמר זה 🙂

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

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