על תשתיות IT והקמת פרויקטים מבוססי לינוקס ב-Enterprise

נניח שאתם שוכרים את שרותי להקמת שרת אפליקציה לינוקסי כלשהו. לא חשוב מהי האפליקציה. סביר להניח שאקבל מכונת VM כלשהי עם הפצת לינוקס שאתם עובדים עליה. ברוב המקרים, סביר להניח שאני אצטרך חיבור אינטרנט כדי להוריד חבילות נוספות מעבר למה שקיים ב-ISO image של הפצת הלינוקס שבחרתם. לפעמים זה חבילה או 2 ולפעמים – מאות חבילות. לבקש שיורידו לי חבילה X זה לא פתרון כי לכל חבילה יש חבילות שכנות שנקראות "תלויות" (Dependencies), כך שלשם ביצוע המשימה, אני צריך את החיבור לאינטרנט, ולפעמים גם ביטול זמני של DLM ודברים כאלו שלא מאפשרים לחבילות בלינוקס לרדת.

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

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

בלינוקס, ולא חשוב איזו הפצת לינוקס, עניין החבילות שונה לחלוטין מ-Windows (אם כי ב-Windows השינויים בחבילות גם נכנסים לאט, כמו חבילות שמתקינים עם Powershell). מאגרי חבילות לדוגמא במקרים רבים לא יורדים מאיזה שרת ספציפי מסוים בחו"ל. במקרים רבים, פקודת ההורדה (yum ב-CentOS או Red Hat לדוגמא) דוגמת מהירת גישה ממספר שרתים שונים באינטרנט וגם במהלך ההורדה, אם לדוגמא חבילה מסויימת לא קיימת בשרת מסוים, ההתקנה אוטומטית "קופצת" לשרת אחר (בכתובת שונה) ומורידה את החבילות משם. אם תרצו לאחר יותר מיומיים שוב להוריד חבילות, מערכת ההתקנה שוב תדגום מהירות של מספר שרתים ויכול להיות שתבחר שרת mirror אחר כדי להוריד, כך שפתיחה ב-Firewall לכתובת URL אחת לא תסייע, מה עוד שבמקרים רבים כתובת ה-URL משתנה עם redirect ואז שוב ה-Firewall חוסם.

אז כן, הפצות לינוקס ו-Firewall בכל הקשור להתקנת חבילות – הם לא החברים הכי טובים.

מה ניתן לעשות?

ההמלצה שלי לחברות גדולות זה להקים שרת (אפשר גם שרת ישן וגם דסקטופ עם מעבד i3 יספיק עם 4 ג'יגהבייט זכרון, כל עוד מדובר על עשרות מכונות VM שיקבלו את החבילות) עם 2-3 דיסקים גדולים (SATA פשוטים של 4-8 טרהבייט, לא צריך Enterprise) ב-RAID 1 ועם 2 חיבורי רשת, רגל אחת תהיה מחוברת החוצה ורגל אחת פנימה. השרת שנקים יהיה בעצם שרת Mirror פנימי לחברה עצמה, ובשרת נריץ מספר סקריפטים שיתחברו אחת ליום לכל מיני מאגרי חבילות ויקבלו את כל החבילות של אותה הפצת לינוקס לגרסאותיה השונות. השרת מתעדכן מדי יום (לעיתים פעמיים ביום) בחבילות וכל החבילות של ההפצות יורדות ומסונכרנות עם שרת Mirror אחר או שרת Master.

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

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

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

על OpenShfit, הטמעה וציפיות בחברות

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

חלק לא קטן מהטענות ששמעתי הגיעו מצד גופים שחשבו ש-OpenShift זה כלי עם GUI מרשים ל-Kubernetes. הנחה זו היא די מוטעית. אם מחפשים GUI וכלי ניהול בשביל Kubernetes, אפשר להסתכל על מוצר בקוד פתוח שלא עולה כלום כמו Rancher. לעומת זאת, Openshift זה כלי שבא לתת לך הכל ללא צורך בהזדקקות לשרותים חיצוניים מהאינטרנט כמו Containers Registry וכו'.

על מנת להבין יותר את התפיסה של OpenShift, נדמיין סיטואציה אחרת לחלוטין: יש לנו 10 מפתחי JAVA ויש לנו שרת לינוקס גדול ורציני. למפתחים יש משתמש משלהם (נניח דרך אוטנתיקציית AD) על שרת הלינוקס ועל השרת מותקן באופן מרכזי ה-JDK וכלים אחרים שהמפתחים משתמשים, וכל מפתח יכול לבצע login ולבצע checkout מה-GIT המרכזי ולהריץ את האפליקציות JAVA שלו. אין צורך שיהיה לו ידע בניהול מערכת לינוקס, אבל מומלץ שיהיה לו ידע ממש בסיסי ב-BASH, ודברים פשוטים אחרים שאפשר ללמוד בשעה שעתיים – בשביל להריץ את מה שהוא כתב. מי שינהל את שרת הלינוקס מבחינת הגדרות, עדכונים וכו' – תהיה מחלקת ה-IT בחברה. לחובבי Windows אפשר לדמיין את הסיטואציה כשרת Windows שנותן שרותי RDP וכל משתמש נכנס עם המשתמש המאושר שלו והוא עושה מה שהוא צריך לעשות. הידע שהוא צריך – הוא שימוש בסיסי ב-Windows, לא יותר מזה.

השוני הכי גדול בין Kubernetes ל-OpenShift מבחינת כל מה שקשור לקונטיינרים – היא הגישה. ב-Kubernetes אם אני רוצה לבצע Deploy, לבצע Scale, רפליקציה, כתיבת שרותים ודברים רבים אחרים – אני צריך לכתוב קבצי YAML (או JSON) שאותם אני צריך להזין ל-Kubernetes ואני צריך גם לבדוק לוגים כדי לראות שכל רץ תקין, ולכן בחברות שמשתמשות ב-Kubernetes רוב העבודה הזו נופלת על איש ה-Devops. לעומת זאת, עם OpenShfit, הדברים בנויים יותר בכיוון שרת הלינוקס וה-JAVA. עם OpenShift אני מגדיר משתמשים (ומחבר את OpenShift ל-AD על מנת לשמור על סינכרון שם משתמש/סיסמא/הרשאות) ואותו מפתח יכול להריץ דברים ישירות דרך ה-CLI או ה-GUI ויש לו כלים מוכנים כדי שהוא לא יצטרך לשכתב קבצי YAML כדי לבנות קונטיינרים עם הקוד שלו בתוך ה-OpenShift. אם הוא רוצה לבצע לדוגמא Scale או Deploy, הוא פשוט יכול ללחוץ כמה קליקים ולהשתמש ב-Template מוכן, לתת שורת כתובת של ה-GIT שלו, ותוך דקות ספורות ה-POD עם הקונטייר/ים שלו ירוצו, הוא יכול לראות מתוך ה-GUI את הלוגים ואף לקבל גישת טרמינל מוגבלת לתוך הקונטיינר כדי לבדוק אם הכל תקין וכו' וכו' ואם הוא רוצה לשמר את מה שהוא עשה בתור קובץ YAML/JSON, המערכת תשמח ליצור עבורו את הקובץ הנ"ל.

לכן, מבחינת חברה, OpenShift עושה את החיים יותר קלים מבחינת הטמעה ושימוש בקונטיינרים, ניהול תשתית המכונות המריצות את OpenShift ואת הקונטיינרים עצמם, כלומר הצורך במישהו יעודי רק כדי להריץ דברים בקונטיינרים פוחת ואפשר להוציא זאת לשרות חיצוני או ללמד את צוות היוניקס/לינוקס את הדברים הדרושים, ובנוסף קל לראות אם ישנן בעיות בתשתית ה-OpenShift (מערכת Heapster נותנת גרפים עשירים פר Node, פר POD וכו' וכו', וגם ניתן לחבר את OpenShift ל-ELK, גרפאנה ושאר החברים). בנוסף, מכיוון ש-OpenShift מבוססת על Kubernetes, ניתן ליישם את מה שרץ על OpenShift על מערכת Kubernetes במקרים לדוגמא בהם הוחלט ש-OpenShift ירוץ בפיתוח ו-Kubernetes או פתרון תואם רץ בפרודקשן (אם כי זה קצת יותר מורכב).

ונקודה אחרונה לגבי מחיר: אני מכיר כמה מנהלי IT ששמעו את המחירים של רד-האט ולסתותיהם נשמטו. נכון, מחירים פר Node אינם בדיוק זולים, אולם המחיר יורד לחמישית אם מריצים את ה-Node כמכונת VM ומעוניינים להריץ את הגירסה המסחרית. חוץ מזה שאישית – אני ממש לא ממליץ להריץ את OpenShift על "הברזל" אלא אם יש שם למחלקת ה-IT ידע ממש עמוק ורציני בלינוקס, אחרת אפשר להפיל Node (ולא חשוב אם זה Node לעבודה או Master) די בקלות. בכל זאת, לא מדובר על הפעלת Cluster קונבנציונאלי עם HeartBeat, PaceMaker וכו'.

לסיכום: OpenShift היא לא מערכת קלה להקמה (יש צורך בידע ב-Ansible אם רוצים להקים אותה על מספר מכונות, אגב – אפשר להרים אותה על דסקטופ עם 16 ג'יגה זכרון בעזרת MiniShift) ויש צורך בידע רציני על מנת להקים ולהגדיר דברים, אבל אחרי שהכל מוקם, יש צורך בפחות ופחות "התעסקות" עם המערכת. זו מערכת שנבנתה עם מחשבה מראש על מפתחים שלא הולכים לעבור קורס קונטיינרים, יחד עם שמירת כל הרגולציות ו-Lifecycle שחברות דורשות.