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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

גילוי נאות
מעבר לקונטיינרים הוא שרות שניתן ע"י חץ ביז

פרויקט נסיוני: קונטיינרים ו-Raspberry Pi-3

גילוי נאות / תודות
מכשירי ה-Raspberry Pi-3 ניתנו לי ע"י SuSE ישראל

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

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

כשזה מגיע לפיתוח, בין אם מדובר בפיתוח Low Level או בפיתוח בשפות אחרות, רוב הזמן המפתחים יכתבו את הקוד על ה-PC שלהם וישתמש ב-Cross Compile עם הקומפיילר החביב עליהם כדי ליצור קבצים בינאריים לציוד מבוסס ARM. אחרי הכל, לקמפל דברים על ARM זה לא כיף (זה איטי … אלא אם יש עליך איזה 500$ למערכת Jetson TX2 של nVidia ששם זה עובד יפה). הבעיה מתחילה בכל מה שקשור לבדיקות הרצה "על הברזל". פתרון של אמולציה זה לא רע (במיוחד אם האפליקציה לאנדרואיד וכתובה Native ב- ++C), אבל לפעמים צריך להריץ את האפליקציה "על הברזל" – במיוחד אם האפליקציה מתקשרת דרך ה-GPIO של הלוח (או דרך USB, יציאות סריאליות בלוח, JTAG וכו') – במקרים כאלו אמולציה לא תעזור ולחבר PC, להריץ אמולציה, למפות כתובות לתוך האמולציה בשביל להריץ את האפליקציה – זה סיבוך עם פוטנציאל להרבה נקודות כשל.

בקטע הזה – קונטיינרים על ARM יכולים להיות פתרון מעולה:

  • האפליקציות עצמם יכולות לרוץ אפליקציה פר קונטיינר על ה-Pi-3 ועוד קונטיינר יכול לשמש כ-DB קטן לדוגמא (SQLite) או אפליקציה קטנה שמקבלת תוצאות טסטים מהקונטיינר הראשון ואפשר להרחיב ולהרים קונטיינר נוסף שמקבל סדרות טסטים להריץ משרת כלשהו, כך שקונטיינר A (שמריץ את האפליקציה העיקרית) מתחבר לקונטיינר C (שמקבל משרת חיצוני את הטסטים שיש צורך להריץ), מבצע את הפעולות ומדווח את התוצאות לקונטיינר B (שמריץ DB או אפליקציה קטנה שאוספת לוגים ויוצרת סטטיסטיקות קטנות). שלושת הקונטיינרים רצים על מכשיר Pi-3 יחיד שמשמש בעצם כ-Node ומנוהל ע"י Master עם Kubernetes או OpenShift (שהם רצים על שרת רגיל).
  • לא צריך לכתוב גרסאות שונות של האפליקציה מחדש ל-eMMC, מערכת ה-Scheduling של הקונטיינר תעיף את הקונטיינר עם הגירסה הישנה ותפעיל על אותו מכשיר קונטיינר חדש. לא צריך Reboot, לא צריך להגדיר מחדש כלום. המפתח מוציא 20 גרסאות ביום עם תיקונים שונים? זמן ההקמה לבדיקה מתקצר בעשרות אחוזים.
  • לא חשוב מה המעבד ARM שיש, כל עוד יש לו גירסת לינוקס וחיבור רשת (ולא מדובר ב-MCU שעליו מבחינת חוסר משאבים לא ניתן להריץ קונטיינרים – כמו במקרים שיש לך כמה קילובייטים בודדים) – ניתן לעשות את הדברים הללו.
  • הקץ לאמולציות איטיות 🙂

ביצעתי בימים האחרונים טסט קטן שכולל 3 לוחות Raspberry Pi-3 ששימשו כ-Nodes ומכונת CentOS אחת שהריצה את OpenShift (שבתוכו יש את Kubernetes). מכיוון שהח"מ אינו חברת שמייצרת פתרונות חומרה, הקמתי מערכת שמריצה LAMP (שהתוכן מאוחסן ב-NFS) ו-2 מכונות וירטואליות שמריצות 20 קונטיינרים רזים (שמריצים ab כ"דפדפנים"). זה לא היה טסט לבדיקת ביצועים, אבל במחשבה שניה – כל Pi-3 הצליח להחזיק בערך כמה עשרות חיבורים סימולטניים. הפלתי כל פעם לוח (ניתוק חשמל) מתוך 3 לוחות ה-Pi-3 ולקח בממוצע כ-8 שניות עד שהמערכת זיהתה Node לא פעיל והזיזה את התקשורת ל-Nodes התקינים האחרים.

לסיכום: האם לעבור מעולם השרתים לעולם ה-Raspberry Pi? כמובן שלא. לעומת זאת, חברות שכן מפתחות פתרונות על לוחות עם מעבדי ARM יכולים לנצל את עניין הקונטיינרים לביצוע טסטים, בדיקת גרסאות תוכנה ועוד.

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

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

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

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

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

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

ענן פנימי

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

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

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

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

קונטיינרים

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

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

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

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

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

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

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

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

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

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

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

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

סיכום

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

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

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

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

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

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

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

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

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

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

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

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

על תשתית קונטיינרים לחברות מסחריות

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

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

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

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

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

עתה נחלק ל-2 את החברות בארץ: יש כאלו שקוד פתוח זה "בעורקים" שלהם – יש להם צוותים שמכירים לינוקס מאוד לעומק, נסיון עשיר ב-Python ו-Go והם יכולים לקמפל לינוקס קרנל בין פיהוק למשנהו ואם יש בעיה בתוכנת קוד פתוח – מישהו בצוות יכול לחטט ולתקן. לאותן חברות שמחפשות פתרון קונטיינרים מקיף אני פשוט ממליץ ללכת על OpenShift Origin על תשתית וירטואליזציה ולהתחיל להשתמש. כל מה שאתם צריכים בשביל להריץ קונטיינרים, להקים, לבנות, Load balancing, HA וכו' וכו' – הכל כבר שם. תורידו מה-GIT ותתקינו ואין לכם צורך לשלם על כלום.

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

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

  • אם אתם חושבים להקים מכמות של כמה מכונות בודדות (VM או פיזי) ועד כמה עשרות כאלו (הם נקראים Nodes) – אז מבחינת תמחור, ה-Docker Datacenter זול בהרבה מהפתרון עם OpenShift. בנוסף, אם מערכת ההפעלה העיקרית שלכם היא Windows והקונטיינרים שלכם יריצו קוד שרץ על מערכות מיקרוסופט – Docker Datacenter הוא הפתרון היחידי כרגע המתאים לפלטפורמות מיקרוסופט.
  • אם לעומת זאת אתם מתכננים על מאות Nodes ומעלה – הפתרון של OpenShift שווה יותר (וזול יותר)
  • אם אתם מעוניינים להקים תשתית חדשה לגמרי שתהיה נפרדת מתשתית הוירטואליזציה הנוכחית שלכם ושאותה תשתית חדשה תריץ קונטיינרים – אז אני ממליץ לרכוש את ה-OpenStack החדש (שם קוד: Magnum) שדואגת גם לתשתית כולה (Compute, Network, Storage, Authentication, Images וכו') וגם להרצת קונטיינרים, בניה, LB, HA וכו'. גם רד-האט וגם SuSE ישראל מוכרים את OpenStack Magnum. אינני יכול לפרסם מחירים של אף מוצר אבל מה שאני כן יכול לרמוז – זה שכדאי להתעניין אצל 2 הספקים במחירים. התחרות רצחנית!

כדאי לזכור משהו חשוב: אין מעבר קל בין Docker Datacenter ל-OpenShift. שתיהן אמנם משתמשות ב-Dockerfile כדי להרים קונטיינרים מבוססי Docker, אולם כל המערכות "מסביב" הינן שונות לחלוטין. ב-Docker Datacenter משתמשים ב-Docker Swarm ואילו ב-OpenShift משתמשים ב-Kubernetes. אפשר לייצא ולייבא קונטיינרים דרך סקריפטים אבל מנסיון – זה לא כיף גדול וזה די מורכב.

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

לחשוב בחיוב על העסקת עצמאים

 

הערה
הפוסט הזה נכתב בכלליות על עצמאים בתחום ההיי-טק בארץ.

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

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

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

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

הבעיה בכל הסצנריו שתיארתי לעיל? המחיר. כמה יותר? בניגוד למצב שאני מוכר ללקוח לדוגמא הפצת לינוקס כלשהי ואני אקבל 10-20% מהמכירה הסופית, לחברות שמעסיקות אנשי מקצוע – הרווח הרבה יותר גדול. כמה יותר גדול? בסביבות 50-150%. בנוסף, לכם אין מושג ירוק כמה הבחור שהם שולחים באמת מכיר את התחום או פשוט "מתגלח על הזקן" שלכם.

סתם דוגמא מלפני מספר חודשים: ללקוח שלי ישנה מערכת שכתובה בשפה שאינני מכיר אותה מספיק טוב ויש בקוד מספר תקלות רציניות (הוא ידע על כך מראש והוא לא לקח אותי כדי לכתוב באותה שפה אלא לדברים אחרים לחלוטין). הצעתי לו שאחפש לו ללא תשלום מישהו אחר שיעשה ספציפית והוא ישלם לאותו לקוח בנפרד. הגיעו 2 הצעות מחברות, חברה אחת הציעה מחיר של 600 שקל לשעה עם מינימום 5 שעות עבודה, והחברה השניה הציעה 650 שקל לשעה (עם מינימום 4 שעות עבודה). סתם לשם השוואה, מאותו לקוח גביתי כ-300 ש"ח לשעה. בסופו של דבר מצאתי עצמאי שגבה מאותו לקוח 280 ש"ח לשעה עם מינימום 3 שעות עבודה (היו הרבה שעות עבודה בין כה). האם אותו לקוח חסך? בהחלט, בכך שהוא לקח את העצמאי לעשות את אותה עבודה (ואותו עצמאי בסופו של דבר קיבל מאותה חברה פרויקט גדול נוסף בעקבות עבודתו המעולה).

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

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

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

מכירות – לא עדיף לרכוש ישירות מיצרן התוכנה?

הנה שאלה שאני נשאל עליה פעמים רבות (עוד לפני ההכרזה שלי על מכירות פתרונות מיצרני לינוקס): האם לא עדיף לרכוש פתרון X ישירות מהחברה היצרנית?

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

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

בניגוד למיקרוסופט, ליצרני הפצות לינוקס אין פתרון לכל דבר. כשזה מגיע לפתרונות ניהול תשתיות, הפתרונות של רד האט יותר טובים, אבל כשזה מגיע ל-OpenStack או לפתרון אחסון Scale Out או פתרון עדכונים לשרתי Windows ולינוקס – הפתרונות של SuSE יותר טובים וכשזה מגיע לפתרון אחסון Scale Up הפתרונות של אף אחת מהיצרניות לינוקס אינו מספק ברמה טובה (במקרים כאלו עדיף לבנות אחד מקוד מקור ולמכור ללקוח תמיכה).  יותר מכך – פתרונות רבים כוללים תוכנות שונות שאין להן קשר לאף  אחת מהיצרניות. אם לדוגמא תרצה לנטר מאות ואלפי מכונות וירטואליות או קונטיינרים – פתרון של ZABBIX יעשה את הדברים באופן אוטומטי ואם רוצים גרפים יפים מאוד – אפשר לשלב בקלות את Grafana לדוגמא. מישהו מיצרני הפצות הלינוקס משווק זאת? לא. אפשר לבקש לשלב את הפתרונות מיצרן ההפצה, אך במקרים כאלו תתכונן לשלם הרבה "אקסטרא" מכיוון שמערכות התמיכה של יצרני ההפצה לא תומכות ב-Zabbix או Grafana (ותוכנות רבות אחרות) וזהו חסרון גדול של רכישה ישירות מיצרן הפצת הלינוקס.

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

מעכשיו – יש גם מכירות

במחירים כאלו – אין לנו כל כוונה לרכוש את המוצר!

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

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

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

עברו 48 שעות ואותו מנמ"ר מרים אליי טלפון. ה-PoC שהוא חשב עליו? מבוטל. מדוע? הצעות המחיר שהוא קיבל היו לדבריו "מבהילות" והוא לא מוכן לשלם מחירים כאלו. מכיוון שאני מכיר מחירים, ביקשתי שישלח לי את ההצעות במייל, אולי יש כאן אי הבנה של איזה איש מכירות או משהו. קיבלתי את ההצעות ומכיוון שאני מכיר את המחירים של יצרן התוכנה – חשכו עיניי. קודם כל שהיו חסרים חלקים שגם עולים בתשלום אבל גם כך – הצעות המחיר היו בין 180 ל-250 אחוז מהמחיר שהיצרן מבקש וההצעות לא כללו מחירים נוספים הכוללים התקנה/אינטגרציה וכו'. פשוט קובץ ISO ומספרים סריאליים פר שרת.

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

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

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

אז החל מהיום, אם אתם מחפשים מוצרים ופתרונות של רד-האט או SuSE, "חץ ביז" הוא פרטנר רשמי של 2 החברות ואתם מוזמנים ליצור קשר

 

תכירו את Open Shift

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

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

אם נסתכל בתשתית ה-Corporate במחלקות הפיתוח לדוגמא, נמצא במקרים שרת SCM כמו GIT (או SVN, מרקיוריאל ואפילו רחמנא ליצלן .. CVS וכו'), אלו שהחלו להיכנס לעולם ה-CI/CD הקימו בוודאי שרת Jenkins ואולי כמה Slaves, אם החברה מפתחת ב-JAVA אז יש בוודאי איזה שרת Nexus, בנוסף ישנם מספר שרתים שמריצים אפליקציות Web, שרת Apache או NGINX (או IIS). הכל רץ טוב ויפה (כשזה רץ…), אבל כשצריך להגדיל את התשתית, מישהו יצטרך לחפש כדורים נגד כאבי ראש עם כל הבירוקרטיה שיש ב-Corporate.

עם Open Shift הדברים שונים. Open Shift (שאגב, היא מערכת PAAS לכל דבר ועניין!) משתמשת בקונטיינרים כדי להריץ את מה שאתה צריך כשכל דבר רץ בקונטיינר נפרד. יש לך אפליקציה ב-PHP שצריכה לכתוב ל-MySQL? כמה קליקים ויש לך 2 קונטיינרים, תוסיף Route ושתיהם מדברים אחד עם השני, שתיהם לא צריכים לשם טסטים לדוגמא להיות עם יותר מ-1 ג'יגה זכרון (סה"כ ל-2 הקונטיינרים) ושתיהם יחד לא יצטרכו יותר מליבה אחת של המעבד בשרת וזה ירוץ מעולה תחת POD יחיד (POD זו ההגדרה של מספר קונטיינרים שרצים בקבוצה). רוצים לגדול עם האפליקציית PHP? שתי קליקים עם העכבר בממשק ה-WEB ותוך שניות ספורות יש עוד קונטיינרים שמוכנים לקבל גולשים, ולא – אתה לא צריך לשבור את הראש על Routing, על Load Balancing וכו' – בתוך Open Shift יש את Kubernetes שעושה את העבודה לבד ברקע. כך גם אם קונטיינר מסוים יפול, המערכת תרים מיידית קונטיינר נוסף תוך שניות ספורות (במקום לחכות כמה דקות עד שיקום VM עם כל התהליכים שהוא צריך לאתחל) והמערכת יכולה להמשיך לתת שרות.

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

אז איך בעצם זה עובד? הנה תהליך עבודה פשוט לדוגמא:

מפתח כותב קוד ובודק אותו מקומית. לאחר שהוא מרוצה מהקוד, הוא "דוחף" אותו ל-SCM של החברה ואז מערכת ה-CI/CD נכנסת לפעולה (אם זה פרויקט קיים), מקמפלת את הקוד, מריצה בדיקות או מה שמוגדר ב-Pipeline ולסיום היא פונה ל-Open Shift. ה-Open Shift לוקח את הקבצים הבינאריים (Artifacts לדוגמא) ובונה מהם יחד עם הדברים שצריך (סביבת ריצה וכו') קונטיינר והמערכת מפעילה את הקונטיינר. המפתח יכול לקבל הודעה במייל שהכל מוכן וכשהוא נכנס לפורטל של Open Shift, יש URL שלחיצה עליו תעביר את המפתח לאתר שהקונטיינר מריץ. עכשיו המפתח יכול להוסיף תכונות, לתקן וכו' – והכל חוזר מחדש. מפתחים בד"כ לא עובדים לבד – והמערכת תומכת בקבוצות כך שמפתחים יכולים לעבוד יחדיו על אותו פרויקט.

צריך להריץ Deployment בשיטות כמו Blue-Green או AB? שתי השיטות נתמכות.

אחרי שהקוד מוכן, נרצה להריץ אותו בפרודקשן. מה אז?

כאן מגיע יתרון גדול של Open Shift. לא משנה איזו תשתית וירטואליזציה יש לך, תהיה הפופולרית ביותר או אזוטרית ביותר, בין אם זה מקומית או בענן פרטי או ציבורי – Open Shift תרוץ. כל מה שאתה צריך זה מספר מכונות VM (או ברזלים פיזיים) ו-Subnet כתובות פרטי וציבורי. מה שנשאר לך לעשות זה להקים Open Shift במכונה אחת (או כאשכול), "לשדך" את שאר מכונות ה-VM שיריצו מערכת Atomic Host (זו גירסת לינוקס מאוד מצומצמת שנועדה להריץ קונטיינרים) ומשם לקמפל את הגירסה היציבה ולהריץ אותה עם רפליקציה. מערכת ה-Kubernetes הפנימית תדע להפיץ את הקונטיינרים בין מכונות ה-VM (וכן, יש גם Auto Scaling ו-HA) ואם אתם מריצים את זה בענן, שרות ה-Load Balancer ידע להעביר את התעבורה ל-IP חיצוני (לא צריך ציוד יעודי יותר בתוך החברה שיעשה LB). קונטיינר נופל? VM נופל? המערכת תדע להתאושש לבד.

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

עד כה כל הטכנולוגיה שדיברתי עליה מדברת על הרצת דברים שכתובים ללינוקס, אבל מה עם אלו שכותבים ב-DotNet? ובכן, מאז שמיקרוסופט ורד-האט חתמו על הסכמי שת"פ, האהבה פורחת ביניהם וכיום ניתן לקחת אפליקציות שכתובות ב- #C עם DotNet ולבנות אותן על לינוקס ולהרים קונטיינר כזה. בשלב זה טכנולוגיות הקונטיינרים של מיקרוסופט עדיין לא עובדת ישירות טוב עם Open Shift אבל אפשר לבנות להריץ אפליקציות כפי שציינתי. אגב, ניתן לשלוט על Open Shift בעזרת ה-CLI גם מתוך Windows (כל מה שצריך זה להתקין Ruby, Git ולהריץ מספר קטן של פקודות).

להלן הדגמה של ASP שרץ עם Open Shift:

הוידאו הבא ידגים איך מקימים מערכת CI/CD מלאה יחד עם Open Shift:

ומה לגבי הטמעת מערכת כזו בחברה?

גם כאן, כמו ב-CloudForms/ManageIQ ישנם מספר גרסאות:

  • יש גירסה שרצה על הענן של רד-האט ומשלמים Pay As you Go, בין אם ב-VM או בברזלים נפרדים.
  • יש גירסת קוד פתוח (גירסה שמהנדסי רד-האט מפתחים, יכולים לצוץ באגים!) שנקראת Open Shift Origin.
  • וישנה גירסת ה-Open Shift Enterprise בתשלום עם תמיכה לשנה או 3 שנים במסלולים שונים.

מבחינת הטמעה וקאסטומיזציה – זה מאוד תלוי בחברה ובדרישות. הקוד של Open Shift כתוב ב-GO.

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

לסיכום: קונטיינרים יכולים לחסוך הקמת VM מרובים ותחזוקתם. מערכת Open Shift יכולה להקל בצורה רצינית על כל תהליך הקמת סביבות הרצת טסטים, פרודקשן, ועוד. בכל מה שקשור למעבר לענן, Open Shift מקלה על בחירת ספקי ענן ובמקביל מגדילה את המבחר ספקים (כך לדוגמא אפשר להשתמש בספק כמו Digital Ocean עם מכונות במחירים זולים בהרבה מספקי ענן ציבורי ובמקרים רבים החבילה תכלול מספיק תעבורה כך שלא תצטרכו לשלם על כך בנוסף!)

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

שאלות ותשובות על Cloudforms/ManageIQ

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

ש: האם CF/MIQ מתאים להחליף את הממשק ה-Windows/Flash/Web של vSphere?
ת: באופן עקרוני CF/MIQ בהחלט יכולים להחליף הממשק הקנייני של vSphere (או vCenter כפי רבים מכירים זאת), כמו שהוא יכול להחליף את ממשק ה-SCVMM בכל מה שקשור למכונות VM, אבל שימוש בכלי כזה רק לשם החלפת ממשק כמוהו כחיסול זבוב עם תותח 🙂

חשוב – שימוש ב-CF/MIQ אינו מייתר רכישת vSphere. ה-CF/MIQ מתממשק ישירות ל-CF/MIQ ולפיכך יש צורך ברכישת הרשיון vSphere.

המטרה העיקרית של CF/MIQ היא לנהל Life Cycle מלא של מכונות VM, וכדי לייעל תהליכים להקמת VM שאינם קשורים ישירות לפלטפורמת ה-VM שלך (פרטית או ענן). תהליכים הקשורים לבירוקרטיה בחברה, אורך חיי VM, פורטל בקשות הקמת VM ע"י הצוותים השונים בחברה, מימוש נהלים, עדכוני אבטחה (בשלב זה במכונות Linux Guest) ועוד. אם נשווה את זה לכלים המוכרים בתחום VMWare למשל, אז זה משהו כמו vRealize Orchestrator + vCenter Server – רק ש-CF/MIQ לוקחים את זה צעד קדימה לאפשר לך להתחבר גם לפלטפורמות VM אחרות ולעננים פרטיים וציבוריים.

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

ש: האם ניתן להשתמש בחלק מה-Appliances גם בגירסה הפתוחה (MIQ) וגם בגירסה המסחרית (CF)
ת: ברוב המקרים התשובה היא "כן", אבל אז אינך יכול לקבל תמיכה רשמית למערכות CF/MIQ. חברות שמעוניינות בפתרון, צריכות או להשתמש בגירסה המסחרית או בגירסה החופשיה (ללא תמיכה רשמית).

ש: האם ישנה פלטפורמת אוטומציה ב-CF/MIQ?
ת: בהחלט! בברירת המחדל CF/MIQ תומכת ב-Puppet יחד עם Foreman, ניתן להשתמש גם ב-Chef וב-Ansible.

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

ש: איזו גירסה יותר מעודכנת ועם יותר Features ואיזו גירסה נחשבת יציבה?
ת: ה-ManageIQ כולל את "המילה האחרונה" מבחינת תכונות המערכת. זו המערכת שמפותחת מדי יום (לתוך GIT מרכזי פתוח) וניתן לשלוף את הגירסה האחרונה או גרסאות קודמות. האם מערכת כזו נחשבת יציבה? כל עוד לא הולכים ל-Bleeding Edge (או ה-Master ב-GIT) – אז יחסית כן, אם כי יכולים לצוץ באגים פה ושם.

לעומת זאת ה-Cloudform זו מערכת שמבוססת על ManageIQ אם כי לא על הגירסה האחרונה של ManageIQ. לגירסה זו נערכים בדיקות ומתוקנים באגים ורק למוצר הרשמי ניתנת התמיכה הרשמית של רד-האט.

ש: מה המחיר של Cloudforms?
ת: עניין המחיר הוא דינמי, זה תלוי על איזו מכונה אתה מריץ את CF, כמה Appliances אתה צריך, מהו סוג השרות שאתה מחפש (NBD, 24/7 וכו'), האם אתם משתמשים בעוד מוצרי רד-האט וכו'. אינני יכול לתת מספרים אבל אני כן יכול לרמוז שהמחיר נמוך ממחיר vRealize Operations (ואתה מקבל יותר, ואף אחד לא "יושב לך על הצוואר" מבחינת כמות VM) 🙂

ש: אנחנו משתמשים באובונטו במערכות שלנו, האם המוצר (המסחרי או הפתוח) יכול לרוץ על VM אובונטו?
ת: מכיוון שה-CF הוא Appliance, הוא מגיע כ-VM מוכן שצריך רק לבצע לו Deploy, להגדיר כתובת IP (או DHCP), להיכנס למסך הניהול ולהגדיר את שאר הדברים משם (ניתן כמובן לבצע SSH ולהשתמש במכונה כמכונת לינוקס אם רוצים לשנות דברים, לא מומלץ אם לא מכירים CF/MIQ).
יחד עם זאת, אם אתם משתמשים בגירסת ManageIQ, ישנם הוראות ברשת איך להקים זאת על VM מבוסס אובונטו (ולכך כמובן לא ניתן לקבל תמיכה מרד-האט).

ש: היכן ניתן לראות רשימת Features שקיימים בגירסה האחרונה?
ת: הנה (לחצו להגדלה)

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

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

ש: האם יש תמיכה ב-Cluster/High Availability?
ת: בהחלט! זה אחד הדברים הראשונים שהתיעוד מסביר איך לעשות אם אתה רוצה להשתמש במערכת כ-Cluster.

ש: כמה זמן לוקח לאינטגרטור מטעם רד-האט בארץ להקים PoC של Cloudform מקומית? האם יש גירסת Trial?
ת: זה מאוד תלוי ב-Scope של ה-PoC ותלוי במסמך ה-SoW. לדוגמא: הקמה של Appliance וחיבור לפלטפורמת ה-VM הנוכחית שלכם אפשר לבצע תוך יום עבודה. קאסטומיזציה, טפסים, כתיבת תוספים – אלו דברים שלוקחים זמן נוסף. כל פרויקט לגופו.

לגבי Trial – בהחלט יש.

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

ש: יש לנו שרתים פיזיים רבים (שאינם מריצים VM אלא אפליקציות יעודיות). האם CF/MIQ יכול לסייע בהקמה/ניהול?
ת: כן. ה-CF/MIQ כולל התחברות לשרת PXE וניתן גם להתממשק ל-IPMI שיש בשרת, כך שהוא יכול להתקין מערכת עם Kickstart ולהריץ עליה אוטומציה לבצע דברים שדרושים לשרת.

ש: יש תמיכה ב-LDAP/Active Directory?
ת: בהחלט. מטרת המערכת בסופו של דבר לתת למספר אנשים גדול בחברה להיכנס ולמלא בקשות שונות ולמנהלים לתת הוראות ואישורים.

ש: האם יש תמיכה במחירים פנימיים (כלומר שכל מכונת VM עולה סכום מסוים מהתקציב) ואפשרויות של Chargeback?
ת: כן. יש תמיכה מלאה לכל עניין קרדיטים, תקציבים, Chargeback ועוד.

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