מיקרוסופט SQL ללינוקס – ההמשך

לפני כשנה כתבתי את הפוסט הזה לגבי Microsoft SQL 2017 גירסת לינוקס שמיקרוסופט הוציאה. מיקרוסופט הסבה את המוצר ללינוקס מכמה סיבות:

  • לכבוש נתח שוק מאורקל
  • לנסות לחדור לכל מיני שווקים שמשתמשים רק בלינוקס

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

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

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

בגירסה החדשה ללינוקס, מיקרוסופט הוסיפה חלקים שלא היו קיימים ב-SQL 2017 ולראשונה יש תמיכה לא רק להרצה בתוך Docker אלא בתוך Kubernetes (אפשר לראות מה חדש כאן) וסוף סוף יש גם רפליקציה טבעית, תמיכה ל-PV/PVC (כלומר Persistent Volumes). הדוגמאות שמיקרוסופט נותנת בתיעוד קשורות אמנם ל-Azure אבל אני מאמין שזה ירוץ גם על Kubernetes מקומי ובשרותים של ספקי ענן ציבוריים מתחרים.

הבעיה היחידה שאני רואה קשורה יותר לתמחור. SQL בסביבה רגילה במצב שרידותי עובד ב-2 שרתים, הן Active/Passive או Active/Active וזה עובד יפה, אך ב-Kubernetes הדברים שונים לחלוטין, אין Active/Passive ודברים כאלו, יש רפליקציות של Pods וקונטיינרים לפי הגדרות שמחליטים, לדוגמא: אם משאבי זכרון/מעבד מגיעים ל-90% – תרים Pod נוסף עם הקונטיינרים הרלוונטיים, בצע Load Balance (תלוי בשכבת הרשת שהוגדרה ל-Kubernetes) בין ה-Pods שמריצים את ה-SQL. מה המחיר שמיקרוסופט תגבה על כל SQL כזה? אי אפשר לגבות מחיר בשיטה הישנה של Cluster.

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

על קונטיינרים ו-Windows Server 2019

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

ב-Windows Server 2019 ניתן להריץ קונטיינרים בדיוק כמו בלינוקס, כשאנחנו מדברים על קונטיינרים בודדים שאנחנו משתמשים ב-Docker, ואם אנחנו מעוניינים להריץ מספר קונטיינרים שמקושרים ביניהם – נשתמש ב-Docker Swarm.

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

אז .. איך Windows Server 2019 עם Kubernetes? התשובה: זה עובד. להכניס לפרודקשן? שלא תעיזו!. מיקרוסופט עדיין עובדים על זה.

ניסיתי בימים האחרונים את Windows Server 2019 עם Kubernetes (גירסה 1.13) והלן הערותיי:

  • תצטרכו לעבוד Multi OS, הווה אומר – ה-Master Node צריך לרוץ על מכונת לינוקס. אם אתם רוצים להשתמש בטריקים כמו HAProxy כדי לחשוף שרות (או NGINX) – תצטרכו גם Node מבוסס לינוקס, בנוסף למכונות Windows שישומשו כ-Nodes כדי להריץ אפליקציות מבוססות Windows.
  • בלינוקס Kubernetes משתמש ב-iptables כדי לנהל את התעבורה הפנימית. ב-Windows זה VFP כך שעדיין יש שימוש ב-Hyper-V. זה לא הולך לרדת.
  • מבחינת משאבים – Windows זה לא לינוקס, וכל קונטיינר מצריך פי 3 משאבים (במינימום!) בהשוואה לקונטיינר שרץ על לינוקס – גם בשביל קונטיינר שיציג Hello World, כך שאם אתם רוצים להריץ הרבה קונטיינרים מבוססי Windows – תצטרכו להקצות לא מעט משאבים לכך מבחינת מחשוב.
  • אין תאימות. בניתם דברים על Windows 10 או על Windows 2016 מבחינת קונטיינרים? תצטרכו לבנות אותם מחדש על Windows Server 2019.
  • וכן .. הכל עדיין דרך CLI (דרך PowerShell).

לכן, אם אתם חושבים להריץ קונטיינרים ואין למפתחים בחברה עדיין ידע רציני, הדבר הראשון שאני ממליץ למפתחים בחברה לעשות – זה לעבוד על לינוקס ולהכיר את הדברים, ובמקביל גם לנסות על Windows. כשזה מגיע ל-Kubernetes, הדגש צריך להיות עדיין על לינוקס. כשרוצים להריץ קונטיינר Windows, אפשר להשתמש ב-Node Selector כמו בדוגמא כאן בקובץ ה-YAML על מנת ש-Kubernetes יפעיל את הקונטיינר על מכונת Windows ולא על מכונת לינוקס.

האם ניתן לקחת אפליקציות שונות ולהמיר אותן לקונטיינרים? לא, זה לא לינוקס. כיום רוב מה שנתמך כקונטיינר ב-Windows הם אפליקציות Net.

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

לסיכום: כן, ניתן להריץ Kubernetes על Windows, אך עדיין תצטרכו לפחות מכונת לינוקס אחת שתהיה ה-Master (ואם זה פרודקשן, זוג מכונות לינוקס שיעבדו כ-HA). מיקרוסופט עדיין עובדת על זה. תהליך ההתקנה עדיין מורכב (אם כי בגירסה האחרונה יותר קל להוסיף מכונות Windows לאשכול Kubernetes, וחשוב לשנות את קובץ ה-YAML לביצוע Deploy כדי שקונטיינר Windows ירוץ על מכונת Windows. ברגע שיש לכם אשכול כזה רץ, אפשר להגדיר את כלי ה-CI/CD שלכם להשתמש גם ב-Nodes מבוססי Windows ואפשר כמובן להשתמש ב-Draft, Helm לעשות את החיים קצת יותר קלים. לחברות שחושבות לעבור ל-OpenShift – בקרוב תצא גירסה שתומכת גם במכונות Windows. כמובן שאפשר לחסוך את כל הכאב ראש – עם תעברו ל-Net Core.

למעוניינים – להלן וידאו הדגמה משבוע שעבר איך Kubernetes רץ על Windows. (הוידאו ארוך: שעה וחצי!)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשענק כמו גוגל מתחרה ב-Docker

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

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

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

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

אבל מה קורה שחברה די קטנה נתקלת בענק שיכול למחוץ אותה בקלות? אני מדבר על חברת Docker מול חברה שאולי שמעתם עליה .. גוגל.

ל-Docker יש מספר מוצרים. את המוצר החופשי Docker להרצת קונטיינרים – כולם שמעו עליו, וזהו כלי מעולה להרים קונטיינרים אבל הכלי לא מספק שום דבר בכל מה שקשור להרצת מספר קונטיינרים, תקשורת ביניהם, ניהול וניטור מרוכז, שרידות, Load Balancing וכו'. בשביל זה תצטרך לשלם על גירסת ה-Docker Enterprise שקיימת ב-3 גרסאות (אפשר לקרוא על כך כאן).

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

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

העניין הוא ש-Kubernetes כבש את השוק. מדוע זה משנה? אם נחשוב על אנשי ה-Devops והמפתחים בחברה שנתקלים בתקלה, הסיכוי שהם ימצאו פתרון עם Kubernetes הוא הרבה יותר גבוה מאשר פתרונות אחרים שאינם מבוססים Kubernetes. נהיה יותר פרקטיים: חברתכם מחפשת 2-3 מפתחים שיעבדו עם קונטיינרים. אם תשאל לגבי הידע שלהם ב-Kubernetes, אתה תמצא שיש הרבה יותר אנשים עם הידע הנ"ל מאשר עם Apache Mesos, DC/OS או עם הפתרון המסחרי של Docker. מפתחים ואנשי מקצוע אחרים לומדים בעצמם דברים שהם פופולריים, ופחות דברים שלא נמצאים בשימוש רב.

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

לכן אני ממליץ לחברות לא להמר על הסוס הלא נכון. עוברים לקונטיינרים? קחו פתרונות פופולריים – בין אם זה Kubernetes עצמו או מוצר ש"עוטף" את Kubernetes ומשתמש במנוע עצמו. זה יכול להיות מוצר כמו של חברת SuSE (ה-CAAS שלהם), זה יכול להיות OpenShift של רד-האט, זה יכול להיות Rancher ויש עוד מספר פתרונות. אלו פתרונות שמתעדכנים ככל שגירסת Kubernetes מתפתחת, ולכם כחברה יהיה יותר קל בהטמעת פתרונות מבוססי קונטיינרים.

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

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