על נקודות חשובות בעת מעבר לענן

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

בפוסט זה אני אעלה מספר נקודות ואתייחסן אליהן.

שרותי SAAS כחלק ממעבר לענן
SAAS (כלומר Software As A service) זה דבר מעולה, בתנאים ובדברים מסוימים. צריך לשלוח עשרות אלפי מיילים? יש כמה ספקי SAAS וסביר להניח שספק הענן שתבחר (טוב, למעט Azure לפחות ממה שידוע לי) שישמחו להציע לך שרות כזה. אם תיקח עצמאי שיקים לך דבר כזה, זה יעלה לך לא מעט, ובנוסף יש צורך לתחזק זאת ברמה שבועית או פחות (RBL, Black List ושאר צרות שמגיעים עם זה), כלומר במקרה כמו המקרה הנ"ל – השימוש ב-SAAS הרבה יותר זול מבחינת עלות ראשונית (ואולי גם בהמשך, תלוי בכל מיני פרמטרים) והוא שרות מוצדק.

לעומת זאת, אם לדוגמא אתה צריך שרות כמו MySQL או PostgreSQL בתצורה כמו Master ו-2 Slaves שיהיו מותקנים באזורים זמינים (Availability Zones במושגים של AWS), יהיה לכם יותר זול להקים זאת בעצמכם עם MariaDB (ו-Galera) לדוגמא, מכיוון שאתה יכול לבחור איזה גודל מכונה שתרצה (ולא רק מה שיש מבחינת SAAS), וגם התחזוקה עצמה אינה מסובכת. הבעיות הנפוצות ביותר שקיימות עם SQL (ולא חשוב איזה SQL) הם בד"כ השאילתות שנכתבות ע"י צוות הפיתוח וחוסר אופטימיזציה, וכאן שרותי SAAS לא יעזרו הרבה כי בסופו של יום – יותר קל וזול לתקן שאילתות מאשר להוסיף 20 שרתי רפליקציה ל-SQL.

מה שמוביל לנקודה הבאה..

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

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

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

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

מה שמוביל לנקודה הבאה..

סקריפטים, קוד ואוטומציה
כשיש לנו תשתית פנימית שנמצאת בחדר השרתים, סביר להניח שצוות ה-IT יכתוב במהלך הזמן עשרות או מאות סקריפטים (ב-PowerShell, Bash, Python, Ruby וכו') על מנת להריץ דברים מסויימים כמו תהליכים מתוזמנים (Cron), ניקוי ומחיקת קבצים ועוד עשרות דברים שונים.

בענן הציבורי לעומת זאת, לרשותכם עשרות או מאות שרותי SAAS שונים וכל אחד מהם צריך הגדרות שונות על מנת שיפעל ויבצע מה שהשרות צריך לבצע, ובמקרים רבים הדבר שנעשה ע"י הצוות הוא כתיבת סקריפטים שיעשו את הדברים או שמכניסים את הקוד לאפליקציה שכותבים שרצה לדוגמא ב-Back end, וכאן בד"כ ישנם 2 בעיות:

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

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

מה שמוביל לנקודה הבאה…

אימוץ טכנולוגיות חדשות
הנה אחד הדברים שאני שומע: "אנחנו מעוניינים שתקים לנו את הדברים בקונטיינרים, אנחנו רוצים גם לעבוד ב-CI/CD עם Jenkins ושהכל יהיה עם Auto Scaling".

לי אישית, אין לי שום בעיה לתת את השרות הזה, בין אם בעבודה עם ECS, עם Kubernetes, עם Swarm או Kubernetes ואין לי גם בעיה לעבוד עם Jenkins. זו לא הבעיה. הבעיה בד"כ היא מה קורה עם הצוות שלך. כל הכלים שציינתי לעיל מורכבים מאוד (ועוד לא דיברנו על שרותי ה-SAAS השונים שספק הענן מציע והחברה רוצה להשתמש בהם).

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

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

כשצריכים VPN טוב ובחינם

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

לכן, חיבור VPN הוא חשוב ורוב העסקים והחברות רוכשים קופסאות Appliance (או VM) של VPN מיצרניות מוכרות כמו Cisco, Fortinet, Juniper, Check Point, Palo Alto ועוד רבים אחרים. לאלו שמעוניינים בחיבורים בודדים, יש את ה-OpenVPN שמאפשר עד 2 חיבורים סימולטנית ללא תשלום, וניתן כמובן לרכוש רשיונות נוספים. אפשרות נוספת בקוד פתוח היא StrongSwan שמאפשר חיבוריות בין שרת VPN לכל מכונת לינוקס/מק/Windows.

אפשרות פופולרית חדשה שקיימת נקראת Wir eGuard ולמרות ש-Wire Guard אינו מתאים להחליף VPN כ-Client/Server עדיין (אין עדיין Clients ל-Windows ומק אם כי הוא יכול לשמש כ-Client/Server בין מערכות לינוקס), הוא יכול לסייע במקום אחר שהוא מאוד חשוב.

נניח ויש לנו מספר שרתים בחוות שרתים ביפו, וישנה קבוצה של עובדים שיושבים בחיפה שצריכים להתחבר לאותם שרתים. חיבור בשיטת ה-Client/Server לכל מחשב שיושב בחיפה למחשבים שיושבים ביפו אינו פתרון יעיל מכיוון שעדיף חיבור שיוצר מעין "LAN" (או ליתר דיוק: WAN) שרץ בעצם על ה-VPN, ואז בעצם אנחנו מחברים בשיטה שנקראת Site to Site VPN. כך לדוגמא עובדות חברות שיווק רבות שיש ברשותן סניפים, כאשר בכל סניף יש מספר מחשבים מקומיים.

כל היצרנים המסחריים מציעים כמובן במסגרת חבילת ה-VPN גם שרות Site to Site (או בקיצור S2S, יש כאלו שמחליפים זאת ב-StS), אך במקרים רבים השרות הנ"ל כרוך בתשלום נוסף, וכאן ל-WireGuard יש יתרון גדול.

תוכנת ה-WireGuard נכתבה בצורה כזו שהיא מפיקה לקחים מפתרונות VPN ישנים יותר (ה-WireGuard זמין בצורה יציבה בערך שנה וחצי) והיא תומכת ב-cryptographic primitives ידועים כגון: Curve25519, HKDF, ChaCha20, Poly1305, BLAKE2s, SipHash24 (אפשר לראות מה כל אחד משמש כאן). בנוסף התוכנה כתובה בצורה יעילה וכל הקובץ הבינארי שוקל … 4 קילובייט כך שטווח התקיפה הוא מאוד קטן (נסו להשוות לכל תוכנת VPN אחרת), הוא רץ ברמת Kernel והביצועים שהוא נותן עוקפים פתרונות אחרים בקוד פתוח (כפי שאפשר לראות כאן), להלן גרפים לדוגמא:

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

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

קונים/מטמיעים שרתים? כדאי שתקראו

ברוב החברות, עד שהם רוכשים שרתים אפשר לפתוח בקבוק שמפניה. רוב החברות רוכשות שרתים אחת לכמה שנים ועם כניסת טכנולוגיות הוירטואליזציה השונות, כמות השרתים הנרכשת – קטנה. אחרי הכל, הרבה יותר קל וזול לדחוף עוד כמה עשרות ג'יגהבייט זכרון לשרת ואולי להוסיף/לשדרג מעבדים מאשר לרכוש ברזל חדש (האמת שיש לי בנושא ויכוח עם כמה אנשי IT. אחרי הכל, שרתים בסיסיים שכוללים 2 מעבדים 4 או 8 ליבות ו-16 ג'יגה זכרון + 2 דיסקים SATA – לעיתים יותר זולים משדרוג שרת קיים, תלוי בגודל השדרוג) – בתחום הזה כל חברה מחליטה לעצמה איך ולאן מתקדמים.

תחום השרתים עצמו די מתפתח. היו לנו שרתי Blade (זוכרים?) וכיום יש מחברות כמו SuperMicro שרתים שהם Twin שהם 2 או 4 שרתים במארז 2U או 4U (בהתאמה) וחברות אחרות גם העתיקו את הטכנולוגיה. היום גם ניתן להכניס דיסקים SSD PCI שעברו דיאטה רצחנית והם בעובי 7 מ"מ וניתן להכניס בין 10-15 דיסקים כאלו במארז 1U (תלוי ביצרן). מבחינה פנימית – כל יצרן בנה לעצמו פתרונות (שחלקם הגדול די קנייני) על מנת לבדל את מוצריו מהמתחרים. חלק מהפתרונות לדעתי תמוהים, חלק מעניינים – אבל ברוב המקרים הטכנולוגיה סגורה. קחו לדוגמא את HP – תכניסו דיסקים שאינם של HP (שבעצמם כלל לא מייצרים דיסקים) ותקבלו הודעה מעצבנת שהדיסקים אמנם יעבדו אבל אם תהיה תקלה – לא תקבלו LED אדום על אותו דיסק. בשבילי כאחד שעוקב כמעט מדי יום לגבי טכנולוגיות חדשות כמעט בכל סוג חומרה – זה מעצבן, כי תמיד יש פתרונות חדשים במחירים מעניינים. בשביל חברות – זה כלל אינו ISSUE, הם פשוט יקנו את הדיסקים מיצרן השרת וישלמו עוד כמה אלפי דולרים. בגלל זה אני מעדיף שרתים "לבנים" מיצרנים כמו TYAN, SuperMicro, ASRockRack, Gigabyte ו-ASUS (האחרונים יותר מייצרים לוחות אם מאשר שרתים מוכנים ללקוח).

ישנה נקודה חשובה שלצערי אינה ידועה רבות כשרוכשים שרתים חדשים: לא מומלץ להכניס אותם ל-DMZ שלכם. מדוע? אסביר.

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

  • החברה אינה מודעת לכך שיש עדכונים, במיוחד כשמותקנת מערכת כמו ESXI או לינוקס. אחרי הכל, למערכות הפעלה אלו יש מערכת עדכונים שמעדכנת את ה-OS, אך לא ממש מעדכנות UEFI/BIOS או עדכוני קושחה אחרים לשרת.
  • שרתים חדשים לא מקבלים בדיקות אבטחה מספיקות. מה לעשות, יצרניות לא פעם מתקמצנות להשאיל/לשכור חברות אבטחה חיצוניות ש"יקרעו" את השרת מבחינת התקפות ונסיונות התקפה על הכניסות/יציאות ועל תוכנות פנימיות שרצות על שבבים פנימיים. התוצאה – עובר זמן עד שמתגלים חורי אבטחה, עוד זמן עד שמתוקן החור אבטחה, והרבה יותר זמן עד שהלקוח מתקין זאת.

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

ישנם לעיתים חורי אבטחה ממש גדולים. קחו לדוגמא את ה-Management Engine של אינטל שנמצא בכל שרת ובכל תחנת עבודה (שכוללים את הדרייברים של אינטל). משנת 2010 ישנו חור אבטחה רציני שתוקף יכול להגיע אל ה-Management Engine (שנמצא כחומרה בתוך המכונה), להשתלט עליו ולעקוב אחרי מה שקורה במכונה במקרה הקל או להזיק לדברים שרצים במכונה במקרה היותר גרוע. שום פירמוט או החלפת דיסקים לא יעזרו. תצטרכו להשתלט על ה-Management Engine מחדש על מנת לפתור את הבעיה. לאינטל לקח 7 שנים עד שבחודש מאי הם שחררו עדכון. החור קיים ב- Intel's Active Management Technology (AMT), Standard Manageability (ISM) ,Small Business Technology (SBT) מגירסאות 6 עד 11.6. האם עדכנתם אצלכם את השרתים לחסום את הפירצה הזו? (אפשר לקרוא עוד על כך כאן)

לכן, ההמלצה שלי בנושא DMZ לדוגמא, היא הכנסת שרתים ישנים יותר (נניח דור אחד אחורה או יותר) מאשר הכנסת שרתים שיצאו זה עתה לשוק. שרתים אלו נבחנו ע"י גופים רבים, עדכונים רבים יצאו וסביר להניח שהם יהיו יותר מוגנים מבחינת קושחות ו-UEFI/BIOS (לא לשכוח לעדכן את ה-UEFI/BIOS לגירסה האחרונה לפני שמכניסים את השרתים ל-DMZ).

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

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

הפריצה ב-Equifax והבעיות ב-Enterprise

כל מי שנמצא בעולם אבטחת המידע שמע בוודאי על אירוע הסייבר הכי גדול שהיה בארה"ב עד היום: פריצה לחברת בדיקת קרדיט עם גניבת פרטים של 143 מיליון איש (ועוד 400,000 בבריטניה, ועוד מגה-פדיחות לגבי הסניף שלהם באוסטרליה מבחינת אבטחת מידע).

מקור הפריצה גם ידוע: בחברה השתמשו בפלטפורמת פיתוח Apache Struts המאפשרת פיתוח אפליקציות WEB ב-JAVA בקלות. חור האבטחה התגלה וטלאי תיקון שוחרר במרץ, אבל ב-Equifax לא ממש טרחו להטמיע את הטלאי, מה שנוצל בחודש מאי כדי לפרוץ ולגנוב את הררי המידע.

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

וכאן בדיוק מתחילה הבעיה..

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

אבל ישנם 2 בעיות בסיסיות ששום טכנולוגיה כמו FW/IPS/WAF וכו' לא ממש יכולות לפתור.

נתחיל בבעיה היותר קלה לפתרון שרובם כלל לא מיישמים. אני קורא לה "סימוכין עיוור" – שורת שרתי אפליקציה פנימיים מתחברים ל-SQL כלשהו ושולפים מידע. בד"כ אתר מבוסס Web או אפליקצייה וובית או אפליקציית מובייל – יעבירו בקשות מהאפליקציה או מהשרתי Front End לשרתי Back End, שרתי ה-Back End יתשאלו את ה-SQL, יבצעו סינון/סידור פלט ויעבירו את הנתונים בחזרה לשרתי Front End או אפליקציה. עד פה הכל טוב ויפה, וכאן יש לנו "סימוכין עיוור" – מכיוון שכל השרתי Back End ושרת ה-SQL נמצאים בכתובות פנימיות, אין שום מגבלה לכמות השאילתות (ובמקרים מסויימים גם אין סינון שאילתות) ששרתי ה-Back End יכולים לשלוח אל ה-SQL ולהעביר הלאה את המידע. שאילתה אחת או מיליון – זה אותו דבר. ה-IPS או ה-WAF יכולים להגן נגד שאילתות רחבות (ה-*), וכך בדיוק נגנב המידע מ-Equifax (מבלי להיכנס לכל הפרטים הטכניים של הפריצה).

הבה נדגים זאת: חברת תקשורת סלולרית מפעילה מוקד שרות לקוחות. מחשבי פקידי השרות לקוחות מריצים אפליקציות ווביות שמתשאלים ה-SQL נון סטופ לגבי פרטים על הלקוחות והפקידים גם מבצעים שינויים בפרטים (שינוי חבילה, חסימת מספר, שינוי פרטי לקוח ועוד ועוד). האם יש איזו מגבלה של כמות שאילתות פר PC? סביר מאוד להניח שלא וסביר להניח שגם לא נמצא מגבלה כזו גם באפליקציה הסלולרית או באתר החברה, וכך יוצא מצב שאם מאן דהוא פורץ ואני מוצא פריצה בספריה שהחברה משתמשת כדי לבנות את האפליקציית Web – אני יכול להקים מספר מכונות VM אצל ספקי ענן שונים (או יותר גרוע – כמה עשרות קונטיינרים פר VM) – הפורץ יכול לתשאל דרך החור שהוא מוצא את ה-SQL שאלות ובעזרת סקריפט שהוא יכול לבנות – הוא יכול לשאוב את המידע מה-SQL, ועד שהחברה תעלה על כך – הפורץ כבר יעלם לו (אחרי הכל, כשפתוחים חשבון אצל ספקי ענן, ספק הענן אינו מחטט בציציות הלקוח – כל עוד יש ללקוח כרטיס אשראי כלשהו [גם אם מדובר בכרטיס חד פעמי או אפילו קרדיט שהתקבל מביקור בכנס]), אף אחד לא יעצור את אותו פורץ לעשות כרצונו, ואם הוא רוצה – הוא יכול לעשות את הכל דרך VPN או הקמת VPN על ספק הוסטינג נידח כלשהו. בהצלחה במציאת הפורץ.

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

כיום רוב העולם כבר למד לעבוד עם תוכנות/ספריות/פלטפורמות חיצוניות שמדיניות עדכוני האבטחה שלהם לא תמיד ברורה והם אינם כלולים באיזה Repository של הפצת לינוקס. יש כיום את Github שבמקרים רבים יכול להציל מפתחים ואנשי IT עם פרויקטים שאנשים כתבו והעלו ורבים משתמשים בכך כדי לפתור בעיות וכדי לממש דברים שונים, אולם כלי ה-IPS לדוגמא לא ממש מגלים חורי אבטחה וכלי סריקה לא ימצאו את החורים כי לפעמים אין CVE לחור אבטחה לכלי שמישהו פיתח, העלה ל-github ושכח בכלל מהפרויקט לאחר זמן מה. יותר מכך – במקרים רבים ההטמעה עצמה מוטמעת עם הרשאות שגויות (ברמת Administrator או root), עם הרשאות קבצים שגויות, או שפתחו יוזר ב-SQL ברמת "הכל כלול" (רוצים דוגמא? לכו תבדקו בחברה אלו הרשאות ה-Jenkins מותקן ורץ. הוא לא אמור לרוץ כ-root).

אני מתאר לעצמי שעתה יבואו אנשים ויאמרו "מה זה משנה, זה רץ רק פנימית, לאיש אין גישה מבחוץ" וכאן הטעות הגדולה ביותר שיש שבגינה עדיין חברות מריצות פנימית (או חיצונית) שרתי FTP לדוגמא: לא חשוב כמה תסגרו דברים ותשימו רק דברים מסויימים ב-DMZ לשרות מוגבל החוצה ללקוחות, תהיה דרך לגשת לדברים שרצים פנימה שאינם ב-DMZ. כל מה שפורץ מתוחכם צריך היום בשביל לגשת למשאבים הפנימיים שלכם זה לשתול תוכנת שליטה (פרי פיתוח עצמי או משהו מתקדם) על אחד מהלאפטופים של המפתחים או אנשי IT (לדוגמא) וברגע שאותו עובד חברה מתחבר לחברה פנימית (בעבודה) או VPN – לפורץ יש גישה למשאבים הפנימיים ואם אתם סומכים על האנטי וירוס/אנטי Malware שלכם, דעו שאת אותו טריק אפשר לבצע על הסמארטפון, הפורץ פשוט צריך לעשות שיעורי בית ואם אתם חברה גדולה מאוד עם מתחרים מעבר לים – יש סיכוי לא רע שהמתחרים יעשו זאת לכם.

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

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

התהליך המומלץ בעת ביצוע פרויקט ע"י יועץ

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

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

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

לעניות דעתי, דברים צריכים להתבצע בדיוק ההיפך.

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

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

משם עוברים לשאר החלקים – אחסון (Storage), רשת (Network) ומחשוב (Compute). היכן מומלץ לחשוב על פתרון NFS והיכן מומלץ על פתרון בלוק כמו iSCSI? האם ללקוח יש תשתית תקשורת מתקדמת (10/25/50 ג'יגהביט) או שצריך לעבוד ב-Teaming? האם חיבור הסטורג' "יחנק" עקב עבודה מאומצת של הפתרון שהלקוח רוצה שירימו לו? האם הלקוח צריך לעבוד ב-HA או DR או שאם נופל הפתרון ויש השבתה זמנית זה לא יהיה קריטי בשבילו? ועוד לא דיברנו על שילוב אוטומציה, Workflow ועוד דברים אחרים.

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

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

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

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

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

  • אנשים מסתכלים על המאמרים של מיקרוסופט וחושבים שעניין האבטחה זה כמו שמיקרוסופט מפרסמת – 3-5 עמודים בלינקים שונים ואפשר לסמן ✔ על הנושא. זהו, שזה לא. אבטחת מידע רצינית בין אם זה על דסקטופ או שרת היא הרבה יותר מורכבת ואתם מוזמנים להעיף מבט על ה-CIS Benchmark שנחשב ה-דבר בהקשחה. על Windows 10 בלבד מדובר על 942 עמודים. Windows Server 2012 R2? זה 732 עמודים. (ועם CIS זה הולך לפי ניקוד לגבי השינויים שעושים, כל דבר מקבל ניקוד שונה)
  • אין "הקשחה אחידה". איש אבטחת המידע רוצה את מקסימום האבטחה, איש ה-IT רוצה פחות כדי שהוא אשכרה יוכל לעבוד בצורה נוחה, ולכן זה יקח לא מעט זמן לעבור על הנקודות ולבצע את הדברים.
  • "חיתוך פינות" – הנה משהו שאני שומע שוב ושוב מלקוחות פוטנציאליים: "כבר עשית את רוב העבודה ללקוחות קודמים, תביא את זה, נעשה תיאומים ונגמור עניין". הבעיה – עדיין לא פגשתי לקוח שמוכן שקוד או סקריפטים שכתבתי עבורו – יעברו הלאה ללקוחות אחרים, גם אם מדובר בדברים שכתבתי בביתי עם ה-LAB שלי. לקוחות רוצים משהו פשוט: שילמנו? זה נשאר אצלנו וזה לא עובר לאף לקוח, אז צריך לכתוב מחדש דברים שוב ושוב.
  • אוטומציה – האם אפשר לעשות את הדברים בצורה אוטומטית פחות או יותר? (להריץ אוטומציה בלי הגדרות פר שרת ששונים מאחד לשני יוביל להשבתה של המערכות שלכם. ראיתי כבר מישהו שניסה זאת פעם) – בהחלט, אבל זה דורש עבודה של 2-3 חודשים של כתיבה ומימוש כל הסעיפים והגדרת קובץ שבו יהיה אפשר לבחור מה יהיה enabled ומה יהיה Disabled, וכן, אני מדבר על אוטומציה ל-Windows עם דברים כמו Ansible.זו עבודה שאינה קלה שמצריכה המון snapshots הואיל וכל מימוש סעיף ובחינתו מצריך snapshot ו-rollback לאחר הבדיקה.
  • תחנות עבודה / דסקטופ – אפשר גם לעשות שם אוטומציה בנוגע להקשחה אולם עדיף לעשות Image מאסטר ולשכפל בין התחנות, תוך יצירת שינויים בהתאם לתפקיד התחנה/דסקטופ.
  • רגולציה / Conformance tests – יש הבדל ענק בין חברה לייבוא שימורים לבין חברת ביטוח או בנק שרוצים הקשחות. במקרים של הגופים הגדולים, חוץ ממחלקת אבטחת מידע צריך לערב את המחלקה שאחרית על מימוש רגולציות ו-Conformance tests (ראיתי מקרה שעבודה ענקית של הקשחה בוטלה ברגע האחרון לפני מימוש רק כי לא עירבו את המחלקה הזו. עבודה עבורי של חצי שנה נעלמה במחי מייל אחד מאותה מחלקה).
  • שילוב הקשחה של Windows ו-Linux. רעיון נחמד, לא ניתן לביצוע מכיוון שמדובר במערכות לגמרי שונות שמצריכות סקריפטים שונים לחלוטין.

לסיכום: כאחד שעשה עבודות כאלו לסטארטאפים ולחברות גדולות (ו-NDA מונע ממני פרסום שמות חברות, אפילו לא לספר לחבר'ה שקיבלת הצעה לבצע עבודה לאחת מהחברות הכי מסקרנות בעולם) אני יכול לאמר מנסיון שהדברים אפשריים, אפשר גם בדרך לשלב פתרונות לחסימות Ransomware וכו' – אבל זו חתיכת עבודה. לא משהו שמתחילים ב-9 בבוקר ומסיימים ב-6 בערב ביום אחד. בסופו של דבר זה נותן לא רק אבטחה, אלא גם פחות תקלות במערכות. יחד עם זאת, צריך לבצע זאת ממש בזהירות ולא ב"טורבו" – מספיק תקלה בשרתי ה-DC עקב מימוש לא נכון והעובדים מגיעים במבט עצבני אליך.

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

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

חג שבועות שמח לכולם 🙂

על קונטיינרים ואבטחה

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

טכנית, אלו שמכירים יוניקס ולינוקס משנים קודמות, מכירים בוודאי את chroot ובמקרים רבים אנשים נוטים לחשוב שקונטיינרים הם בדיוק כמו להריץ chroot (כלומר ביצוע הקמת file-system ועליו להריץ את פקודת chroot על מנת לתת כביכול "מערכת הפעלה" נוספת), אך למען האמת, docker משתמש בהרבה יותר מזה כדי להריץ קונטיינר שיכול להיות מאובטח (יש צורך בעבודה נוספת על מנת לאבטח, אפשר לקרוא על כך כאן).

העניין הוא – שברוב המקרים בחברה לא יריצו קונטיינר יחיד (ראו פוסט זה שכתבתי לגבי מעבר מ-VM לקונטיינרים ברמת הקונספט). אם יש לדוגמא אפליקציה וובית, ברוב המקרים היא תהיה מחוברת ל-DB שירוץ על קונטיינר אחר, וההרצה בעצם תבוצע ע"י Container Scheduler כמו Mesos, OpenShift, Kubernetes, Docker-Swarm ועוד – הם ירימו את הקונטיינרים וינהלו את הכל.

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

  • אינטל מציעה את Clear Container (בגירסה 2.1.4 ששוחררה לאחרונה). היתרון של Clear Container בהשוואה לקונטיינרים של Docker הוא בכך שכל קונטיינר של Clear Container הוא בעצם מכונה וירטואלית (VM) שבתוכה מותקנת ורצה האפליקציה, משמע – בשביל להריץ Clear Container, תצטרכו להריץ זאת על Bare Metal (כלומר על "ברזלים") בלבד ולא על VM (כן, יש כמובן Nested Virtualization לכל תוכנת וירטואליזציה, אבל אף חברה לא תשתמש בזה באופן רציני בפרודקשן לדוגמא), כך שבעיה ראשונה שאני רואה – היא ששום חברה לא תסכים שמערכת תקים מכונות VM "על הברזל" בלי מערכת שתנהל את אותם VM מבחינת משאבים, ניטור ובכלל – ללא פתרון כמו vCenter שיש מ-VMWare למכונות VM – אף אחד רציני לא יכנס לזה.
    האם הפתרון של אינטל יכול להשתמש ב-Kubernetes? כן אבל זה ממש לא מוכן לפרודקשן.
  • Kubernetes בעקרון נוקט שיטת אבטחה של "הכל סגור". בברירת המחדל, כאשר אתה מקים קונטיינרים או POD, אינך יכול לגלוש אל האפליקציה שרצה בקונטיינרים או ב-POD ועליך "לחשוף" פורטים מסויימים או להשתמש ב"שרות חשיפה" כמו LoadBalancer או NodePort (שמאפשר לפתוח פורטים מסויימים שיתחברו אל ה-Load Balancer החיצוני שלכם) או ClusterIP, אך החסרון ב-Kubernetes הוא שזו מערכת Multi Platform שאינה מכירה בחלק מתכונות אבטחה שה-Kernel והמערכת יכולים לתת (כמו SELinux – גם בגירסה הנוכחית Kubernetes עדיין לא ניתן לעבוד עם זה). Kubernetes מכיר כמובן ב-namespaces ו-cgroups כדבר שנותן אבטחה, אבל לחברות רבות – זה לא מספיק.
  • OpenShift מכיל את Kubernetes ומערכת Openshift בעצם "עוטפת" את Kubernetes ומוסיפה לו בדיוק את הדברים שחברות מחפשות מבחינת אבטחה. כך לדוגמא אין אפשרות להריץ התקנת Openshift על שרתים מבלי להפעיל SELinux ו-NetworkManager כך שמראש המערכת מקימה קונטיינרים ושאר דברים בצורה מאובטחת כברירת מחדל.
  • מה עם Mesos? אני לא מומחה ב-Mesos אבל לפחות לפי כמה שהכרתי אותו, ישנה אבטחה ברמה של הקמת ותקשורת בין קונטיינרים (עם Auth), אבל אינני רואה שם שום דבר שיכול בעצם למנוע מפורץ שנמצא בקונטיינר – "לצאת החוצה", כלומר הכל תלוי בבנייה ידנית שלך לקונפיגורציות של הקונטיינר, שימוש בתכונות אבטחה של ה-Kernel (ראו לינק ראשון בפוסט זה) וכו'. אין SELinux, AppArmor שיכולים למנוע דברים גם אם המשתמש השיג root מקומי בתוך הקונטיינר.
  • לגבי Docker-Swarm: אנשים לא אוהבים שאני אומר את זה, אבל מבחינת אבטחה ב-Docker Swarm, אין ממש הרבה. כן, אתה יכול לבנות רשת מוצפנת (IPSEC), אבל מה זה עוזר אם מישהו נכנס לקונטיינר ויש לו עכשיו גישה לקונטיינר עם ה-DB? זה נחמד שיש הצפנה אבל הפורץ נכנס אחרי שיש הצפנה והרשת בין הקונטיינרים פועלת באופן שקוף (כבר בוצע Authentication). אז נכון, הוא לא יוכל לפתוח כניסות חדשות, אבל הוא בהחלט יכול להשתמש בכניסות קיימות (פורטים) ואולי לא לגרום לנזק לכל המערכת אלא רק לקונטיינרים שאליהם הקונטיינר שהוא נכנס מחובר. בקיצור, לדעתי האישית לגבי Docker-Swarm, הוא נחמד, אבל אין לו מספיק עבודה רצינית על אבטחה.

לסיכום: האם Docker עצמו יכול להיות מאובטח? בהחלט, אם אתה מתכנן להריץ מספר קונטיינרים קטן ללא Scheduler ואתה מוכן לעשות את העבודה הנוספת להגן על הקונטיינרים (הם לא מספיק מאובטחים בברירת מחדל! אם אתה מחפש להריץ קונטיינר עם פורט 80 החוצה, אתה ממש לא חייב להריץ את הקונטיינר כ-root). אם אתה משתמש ב-Kubernetes, אז יש לך Best Practice כיצד להגן על הקונטיינרים/POD וכו' ברמת התקשורת ואותנטיקציה, אבל Kubernetes עדיין לא יודע איך להגן בתוך הקונטיינר נגד פורץ. הפתרון של אינטל הוא נחמד אבל עד שיהיה פתרון לאינטל ברמה שזה רץ על VM או בשילוב עם מערכת Management ל-VM (כמו vcenter ואחרים) אף חברה רצינית לא תיקח זאת.

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

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

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

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

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

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