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

בניית מכונות VM בצורה יותר טובה

תחום הקונטיינרים קיבל בשנים האחרונות דחיפה רצינית תודות לפתרונות כמו Docker, OpenShift, Kubernetes ומערכות רבות נוספות, ואחד הדברים הראשונים שכל מי שנכנס לעולם הקונטיינרים לומד הוא שקונטיינרים זה דבר זמני – אתה מפעיל, מכבה, וכל התוכן שבקונטיינר עצמו – נעלם, ולכן משתמשים בפונקציות כמו Volume (במערכות כמו Kubernetes יש לנו את PV/PVC) כדי למפות משאב חיצוני (כמו תיקייה במכונה) אל קונטיינר ושם יאוחסן המידע, כך שגם אם הקונטיינר נמחק, ה-DATA נשאר.

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

הדבר שאני מדבר עליו – חלוקה.

נניח ואנחנו צריכים VM שיתן לנו שרות מסוים. נניח SQL, שרת Web, שרת GIT, ועוד ועוד, כל דבר שנותן לנו שרות. ברוב המקרים שאני ראיתי – מקימים VM, מתקינים עליו את מערכת ההפעלה הרצויה ואת האפליקציה שתתן לנו את השרות הרצוי. היכן יאוכסן ה-DATA שאותו אפליקציה תנגיש? בתוך ה-VM. אחרי הכל – תמיד אפשר להגדיל דיסקים וירטואליים, זכרון וכו'.

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

הבעיה הגדולה משחזור גיבוי של מכונה כזו: אתם תאבדו נתונים שנכנסו מאז הגיבוי האחרון. נכון, במקרים של SQL או MySQL אפשר פשוט ליצור DUMP לפי הרצת שחזור ואז למחוק את הנתונים לאחר השחזור ולהעלות את ה-DUMP, אבל במקרים אחרים זה קצת יותר מסובך: מה אתם עושים עם שרת Gitlab לדוגמא שמאבד את הסנכרון? יש לכך כמובן פתרונות, אבל שוב – אפשר להימנע מכל הבעיות האלו.

איך נמנעים? די פשוט: מתחילים להשתמש בשרותי ה-Network File שקיימים, דוגמאות:

  • אם אנחנו מרימים MySQL או SQL של מיקרוסופט על לינוקס, אפשר למפות את התיקיות DATA שהשרות נזקק להן – למפות ל-NFS Share (אם אתם מריצים SQL של מיקרוסופט על לינוקס עם NFS, ודאו כי מדובר ב-NFS 4.2 וה-mount צריך לכלול את הפרמטר nolock)
  • אם אתם מרימים שרת אפליקציית GIT או שרת WEB – אפשר למפות ל-NFS את התיקיה שה-DATA עצמו (כמו קבצי php,html, גרפיקה וככו') יאוחסן. כל מה שצריך זה פשוט ליצור בסטורג' את ה-NFS Share ולבצע mount שיוגדר בקובץ fstab.
  • ב-Windows נשתמש באותן שיטות, רק עם SMB במקום NFS.

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

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

לסיכום: מכונות VM לא צריכות להיות "מפלצות VM" עם דיסקים בגדלים של מאות ג'יגה עד טרהבייטים. בדרך כלל אין צורך ש-VM מבוסס לינוקס לדוגמא יהיה בגודל של יותר מ-10-20 ג'יגהבייט. אם ה-VM נותן שרותים, אני ממליץ פשוט לאחסן את הנתונים לשרותים דרך NFS/CIFS, כך גם תקבלו מהירות read/write יותר גבוהה (דיסקים וירטואליים עדיין יותר איטיים בהשוואה ל-NFS "טבעי", אגב), וגם כשתצטרכו לשחזר מ-snapshot או גיבוי, לא תצטרכו לדאוג לגבי עניין האם ה-DATA החשוב מעודכן.

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

קונטיינרים – הפתרונות שקיימים ומה כדאי לבדוק

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

(הערה: מכיוון שמערכות כמו OpenShift, IBM Private Cloud, CAAS, Rancher ועוד מבוססים על Kubernetes ועל זה הם הוסיפו דברים אחרים, אתייחס בפוסט זה ל-Kubernetes או בשמו המקוצר הידוע – K8S).

אחד הדברים הראשונים שמנמר"ים ואנשי IT רבים עדיין לא מבינים, זה את הבסיס, שקונטיינרים אינם מכונות וירטואליות. קונטיינר שקם משתמש ב-Images והוא לא מיועד לאחסן נתונים באופן פרמננטי כמו במכונה וירטואלית, לשם אחסון נתונים יש Volumes שעליהם אתייחס בפוסט זה בהמשך. בקונטיינר אין מערכת הפעלה מלאה, אלא מה שהותקן בעת הקמת ה-Image וברוב מוחלט של המקרים מדובר במשהו מזערי שאמור לספק את דרישות האפליקציה שתרוץ בקונטיינר. בנוסף, קונטיינר מאובטח לא אמור להריץ שרותים כמשתמש root אלא כמשתמש רגיל (ללא הרשאות root/sudo) ולבסוף – קונטיינרים לא אמורים להריץ מספר אפליקציות, אלא אפליקציה אחת בכל קונטיינר/POD ו"לדבר" עם POD/קונטיינרים נוספים שמריצים אפליקציות אחרות, בשביל זה יש לנו TCP/IP ובשביל זה יש שרות DNS פנימי שרץ על K8S שיודע לתקשר בין החלקים והשרותים השונים.

הדבר השני שחשוב להבין בקונטיינרים, זה שזו מערכת מאוד דינמית. לא מומלץ לנסות לקבוע למערכת על איזה שרת לרוץ, מערכת K8S יודעת לבד באיזה שרת להקים את הקונטיינרים, היא יודעת למדוד עומסים וכשצריך – היא תקים את הקונטיינר בשרת אחר אם השרת שכרגע הקונטיינר רץ – עמוס או תקול. אין Live Migration של קונטיינרים, יש להרוג את הקונטיינר ולהריץ אותו מחדש במקום אחר, ובגלל זה כל מידע שצריך להישמר – צריך להיות מאוחסן ב-Volume, אחרת המידע ימחק.

הרעיון של Volume הוא שונה מכל מה שאנחנו מכירים וקשור לאחסון. במערכות וירטואליזציה לדוגמא, אנחנו מגדירים "אחסון" (כמו Datastore ב-VMWare) שיש לו Backing שיכול להיות iSCSI, NFS ובמקרה של Hyper-V זה יכול להיות CIFS. בפתרון הסטורג' שלנו אנחנו מקימים LUN או מחיצה כלשהו שייוצאו כ-NFS/CIFS לפתרון הוירטואליזציה (לא ניכנס עכשיו לכל עניין שרידות, Multipath ושאר ירקות) ועל המקום הזה פתרון הוירטואליזציה שלנו יוצר/משתמש בדיסקים וירטואליים כדי להריץ את מערכת ההפעלה ולאחסן את המידע שלנו.

ב-Volumes לעומת זאת, הדברים שונים לחלוטין. אנחנו עדיין צריכים את ה-Backing (רק שיש הרבה יותר אופציות מאשר iSCSI, NFS – יש 26 אופציות, ו-OpenShift מוסיף עוד כמה) מהסטורג' כדי לאחסן את ה-Volumes, אבל כשאנחנו באים ליצור/להשתמש ב-Volume, אנחנו צריכים קודם כל להגדיר Persistence Volume, להגדיר מה הגודל של אותו Persistence Volume, מה יקרה ל-DATA באותו Volume אחרי שהקונטיינר מת, ומה ההרשאות שיהיה לאותו Persistence Volume מבחינת קריאה/כתיבה. בהגדרות הקונטיינר עצמו אנחנו נשתמש ב-Persistence Volume Claim (או PVC בקיצור) כדי להתחבר לאותו Persistence Volume (או PV בקיצור) ולהגדיר גם Path להיכן להתחבר. ה-PV בדרך כלל מוגדר ברמה של מגהבייט או ג'יגהבייט.

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

לכן, אם אנחנו רוצים להקים פלטפורמת K8S, אנחנו קודם כל צריכים להחליט, האם אנחנו מקימים את זה "על הברזל" או על מכונות וירטואליות? אם על מכונות וירטואליות והפתרון מבוסס vSphere, אז אנחנו יכולים להסתכל על VMware Kubernetes Engine™ VKE לדוגמא (ואפשר במקביל להציץ גם ב-PKS של VMWare/Pivotal). חובבי מיקרוסופט? בחודש הבא יוצא Windows Server 2019 שכולל את Kubernetes בתוכו. אם לעומת זאת אנחנו מעדיפים פתרונות כמו OpenShift, CAAS ואחרים, נצטרך להקים מכונות לינוקס ועליהן להריץ את אותם פתרונות. לא אכנס כאן ליתרונות וחסרונות של פתרונות "טבעיים" מול הקמת פתרונות על מכונות וירטואליות – אבל אחת הנקודות שחשוב לזכור, זה שפתרונות שמקימים על מכונות וירטואליות – זה שקל להזיז את הפתרון לעננים או למקומות אחרים במקום להיות "נעול" על פתרון שיצרני ה-OS ווירטואליזציה מציעים. חוץ מזה קיים גם עניין המחיר.

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

  • תקשורת 10 ג'יגהביט. שוב, אין בקונטיינרים Live Migration שמשתנה בו כמה קבצי קונפיגורציה וה-VM "קופץ" למכונה אחרת, יש הקמה מחדש של קונטיינרים ולמרות שה-Image נמצא בסטורג', בחלק מהמקרים הוא מועתק לדיסקים מקומיים ולכן פתרון תקשורת 1 ג'יגה יאיט הכל.
  • סטורג' עם שרידות – יש לא מעט חברות שבטוחות שזה שהדיסקים מחוברים בבקר RAID כפול יש אחלה שרידות. לדעתי – עדיף שרידות שאם "ראש" נופל, "ראש" אחר לוקח מיידית פיקוד, אבל שוב – הכל תלוי בתקציב וכמה הפלפורמה תהיה פרודקשן.
  • דיסקים מקומיים – מאוד חשוב. ה-Images ימצאו בדרך כלל ב-Container Registry, אבל הם יועתקו לדיסקים מקומיים ברוב המקרים ועם הדיסקים מקומיים איטיים, זמן הקמת הקונטיינר יתארך (ותהיו בטוחים שיהיו ערימות קונטיינרים, חוץ מהקונטיינרים שלכם, תלוי בפלטפורמה). דיסקים מכניים זה פתרון לא רע אבל אם רוצים ביצועים – תחשבו על SSD Mixed Intense.
  • אם המערכת הולכת להיות חשופה החוצה לאינטרנט (הכוונה השרותים כמו WEB חשופים לאינטרנט) – אז אבטחה רצינית היא חשובה: לא להקים Images כ-root, תקשורת ו-Namespace מופרדים ועוד דברים חשובים שמצריכים הכרה עמוקה עם פלטפורמת הקונטיינרים. תזכרו: קונטיינר שרץ כ-root וחשוף לרשת – יכול לתת לפורץ הרבה יותר ממה שאתם חושבים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

על קונטיינרים וחומרה

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

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

עולם הקונטיינרים משנה מספר דברים חשובים:

  • אפשר להקים הרבה פחות מכונות VM כדי לתת את אותו שרות.
  • קונטיינרים צריכים 30-70% פחות משאבים בהשוואה להרצת אותה אפליקציה שרצה ב-VM
  • מבחינת Scalability – קונטיינרים עושים את העבודה בצורה יותר טובה בהשוואה ל-Scaling של מכונות VM, והגדילה הרבה הרבה יותר מהירה בהתאם לעומסים.

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

אם נסתכל על חברות ענקיות כמו פייסבוק וגוגל, נראה שבהתחלה השרתים שלהם היו שרתים מאוד צנועים, והם פשוט הכניסו המון שרתים על מנת לבצע Scale Out עם מעבדי Xeon. לאחרונה, אותן חברות החלו לעבור לארכיטקטורות מתחרות, בגוגל לדוגמא עברו למעבדי Power של IBM ומעבדי ARM חדשים ו-Facebook גם מכניסים מעבדי ARM. זה לא ללקוחות שלהם, זה בשביל להריץ את הקונטיינרים שלהם.

לכל אחד מהארכיקטורות האחרות יש יתרונות על פני מעבדי ה-Xeon (גם החדשים) של אינטל:

  • למעבדי ARM יש את היתרון הגדול של כמות ליבות גדולה וצריכת חשמל נמוכה, מצב אידיאלי כאשר כל קונטיינר אינו צריך עוצמת מעבד רצינית ולפיכך ניתן להריץ יותר קונטיינרים פר מכונה פיזית מבלי לצרוך כמות חשמל כה גדולה. כך לדוגמא מערכת Apollo 10 של HPE תוכל בקרוב לקבל מעבדי ARM בגירסה יעודית. חברת Qualcomm לדוגמא יצרה מעבד שנקרא Centriq ויצרני שרתים מובילים שמחים לאמץ ולמכור שרתים עם פתרון זה.
  • למעבדי Power יש הרבה יותר כח מכל מעבד Xeon שיש לאינטל. אלו המעבדים שמפעילים את ה-MainFrame למיניהם ו-IBM מוכרת לדוגמא שורת מכונות שמריצות לינוקס בצורה טבעית עם אחריות ושרות מלאים (עם Red Hat 7.4) וכל מכונה יכולה להריץ הרבה יותר קונטיינרים בהשוואה למכונה מבוססת Xeon (תלוי כמובן במפרט).
    יתרון נוסף של מעבדי Power9 של IBM – זה שניתן להריץ קונטיינרים באופן טבעי ישירות על ה-Main Frame, ולקבל לא רק ביצועים טובים, אלא את השרידות הכי גבוהה שיש (זו המערכת היחידה שאתה יכול להוסיף זכרון, מעבדים כשהמערכת רצה).

נשאלת כמובן השאלה: מה עם תאימות בינארית? התשובה לכך היא די פשוטה: המערכת הפעלה שתרוץ בקונטיינרים כבר קיימת לקונטיינרים. מה שנשאר הוא לקמפל ספריות וקוד פנימי של החברה ובכך בעצם ליצור קבצים בינאריים לפלטפורמה שנבחרה וכך נוכל לבנות Images שהם אופטימליים (ללא שום המרות או אמולציות) לפלפורמה שנבחרה. לדוגמא – אם האפליקציות שהחברה כותבת הם ב-JAVA ורצים על Tomcat, אז ה-JDK קיים באתר של IBM ויש קונטיינר מוכן עם Tomcat ל-Power9. אותו הדבר קיים גם ל-ARM.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שבוע טוב 🙂

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

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