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

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

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

[stextbox id="info" caption="גילוי נאות"]הטמעות והדרכות לגבי מוצר זה מסופקים ע"י "חץ ביז"[/stextbox]