מעבר לענן שאלות ותשובות (חלק 1)

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

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

ש: האם יש הבדל גדול בין ספקי ענן בארץ לבין ספקים כמו אמזון/גוגל/מיקרוסופט?
ת: קודם כל – כמובן, עניין הגודל 🙂
וברצינות – ספקים כמו השלישיה שצוינה לעיל עובדים באופן שונה לחלוטין מכל מה שמכירים בישראל. גוגל/אמזון/מיקרוסופט בונים את הארכיטקטורה שלהם באופן שונה לחלוטין. כשמדברים על Storage לדוגמא, לא תמצאו אצלם NetApp או EMC או כל סטורג' (גדול ככל שיהיה) שקיים ללקוחות בשוק הרחב. מדובר על "פתרון סטורג'" שאותו ספק ענן תכנן, בנה ופיתח בעצמו. אין דיסקים SAS ואין RAID ואין LUN או כל המושגים שאנחנו מכירים מעולם ה-IT הרגיל שלנו. המערכות שלהם יודעות להתמודד באופן שגרתי גם עם נפילות של 8 או 10 דיסקים, גם אם זה קרה בעת ובעונה אחת (נדיר ביותר) והנתונים שלך תמיד זמינים. לדוגמא: אחסון ב-S3 של אמזון מגיע עם SLA מדהים של 99.999999999%. לכו תמצאו ספק אחד בארץ שיתן לכם את אותו SLA.

גם אשכול (Cluster) שאנחנו מכירים הוא די שונה אצל אותם ספקי ענן. תסתכל לדוגמא אצלכם בחברה על Cluster שהקמת. 2 המכונות באשכול (נניח) נמצאים ב-2 שרתים כאשר שתיהם נמצאים אחד מעל השני, אולי בארונות נפרדים ואולי אפילו בקומות נפרדים. אצל השלישיה – Cluster זה אומר ש-2 המכונות עבורך יושבים ב-DC שונים גיאוגרפית באותה מדינה (לאמזון לדוגמא בוירג'יניה יש לא פחות מ-5 DC. בשפה של אמזון הם נקראים Zones), כך שאם מתרחש אסון, האשכול ממשיך לעבוד וברקע מוקמת מכונה אחרת אך עדיין השרות יעבוד.

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

כאן בישראל לעומת זאת, ספקי הענן עובדים בדיוק כמו שעובדים ב-Corporate. הסטורג' הוא סטורג' מסחרי סגור, האשכול מוקם באותו DC, ואם מתרחשת תקלה (אהממ.. מזגנים, קבלן אידיוט שלחץ עם הגב על הכפתור האדום והשבית חשמל, דברים שהתרחשו בארץ) – המערכת שלך מושבתת והרעיון להקים אשכול בין 2 DC יהיה קצת בעייתי (במיוחד אם אתה צריך אחסון משותף ל-2 השרתים). בגלל זה בד"כ בארץ עובדים בשיטה של DR (כלומר Disaster Recovery) כאשר אם המערכות שלך בארץ נופלות, המערכות שלך אצל ספק חיצוני "תופסות שליטה" אבל זה כמובן שונה לחלוטין מאשכול שעובד בברירת המחדל אצל השלישיה כ-Active/Active.

יחד עם זאת, לספקים בארץ (ורוב חברות ה-Hosting הגדולות בחו"ל) יש יתרון על פני השלישיה בכל הקשור להתרחבות תשתית קיימת. אם אתה משתמש לדוגמא ב-vSphere של VMWare ואתה מעוניין להתרחב מעבר ל-DC הקיים שלך, מוצר כמו vCloud Air (או כל פתרון Hybrid Cloud אחר בהתאם לתשתית הוירטואליזציה שלך) יכול בקלות לעזור לך להתרחב, כל מה שתצטרך לעשות זה למצוא שותפים לפלטפורמת ה-vCloud במדינה שאתה מעוניין לבצע את ההרחבה אליה, להיכנס למו"מ לגבי מחירים ולאחר החתימה להתקין את ה-vCloud Air, לבצע הגדרות – ואתה מוכן להתרחבות. האם ניתן יהיה לעשות זאת עם השלישיה? עוד לא (עם אמזון זה נמצא בשלב ה-Technology Preview ואני בספק אם יהיה ניתן לעשות זאת עם Azure של מיקרוסופט) אבל גם אם זה אפשרי – לא תמצאו שם חסכון (זיכרו: אצל ספק רגיל בחבילה אתם מקבלים X טרהבייט תעבורה החוצה, באמזון כל ביט שיוצא החוצה מעבר לג'יגהבייט הראשון – אתם משלמים).

מה שמוביל לשאלה הבאה:

ש: מה ההבדל בין העננים של השלישיה לבין Hybrid Cloud?
ת: כפי שתיארתי לעיל, הרעיון של Hybrid Cloud הוא בעצם הרחבה של ה"ענן" הפרטי שיש לכם בחברה, כאשר הכל בעצם מבוסס על מכונות VM שרצות. לדוגמא: ב-Hybrid Cloud אם אתה צריך שרות כמו SQL, אז אתה מרים VM שמריץ SQL Server, Oracle או MySQL לדוגמא וה-VM הנ"ל מספק שרות SQL לאחרים. אין לך ספק חיצוני שמספק לך שרות SQL בהתאם לדברים שאתה צריך. סטורג' – כמעט אותו סיפור: או שיש לך סטורג' חיצוני שממנו תשתף תכנים (CIFS/NFS) או תשתמש ב-iSCSI אבל הכל בסופו של דבר כרוך בסטורג' החיצוני שלך, או שתרים VM עם דיסקים גדולים וממנו תייצא את אותם שרותים, כך ש-Hybrid Cloud מאפשר לך בעצם להתרחב בדיוק עם אותה תשתית ושימוש ב-VM וסטורג' חיצוני (או דיסקים פנימיים בחלק מהמקרים, תלוי בגודל חברה, תקציב וכו')

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

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

ש: האם השלישיה מציעה שרותי SSO? (ר"ת Single Sign On)
ת: תלוי לאיזה ספק ענן אתה פונה.

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

ש: כיצד ניתן לבצע חיבור קבוע לשרתים שלנו בענן?
ת: שלושת ספקי הענן מציעים חיבורי VPN Site to Site, באמזון יש עוד אפשרויות. להלן האפשרויות של אמזון:

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

אפשרות יותר זולה היא להשתמש בשרותי ה-VPC/VPN של אמזון. באופן עקרוני, כשאתה פותח חשבון באמזון, המערכת של אמזון בונה עבורך VPC (ר"ת Virtual Private Cloud) ולזה אתה יכול לחבר VPN חומרה ולהתחבר בחיבור מאובטח VPN Site to Site ויש גם אפשרויות אחרות. פרטים ניתן לראות כאן.

לגבי מי ששאל על SD-WAN: זה תלוי בספק SDN שלכם. רובם מציעים כבר פתרון חיבור מאובטח לשלישיה (לפחות ל-Azure ולאמזון כיום)

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

כל ספק מציע ערימות שרותים, אולם כדי לתכנת את השרותים, הספק מציע API שאיתו אתם עובדים. ב-Azure לדוגמא יש צורך בידע טוב של PowerShell ובמקרים מסויימים #C. באמזון לדוגמא כדאי שיהיה לך ידע של Python, Java ולפעמים גם JS וקצת BASH. בגוגל – אותו דבר כמו במקרה של אמזון.

משהו נוסף שדי חשוב שיהיה לכם במקרים של אמזון וגוגל: ידע די טוב בלינוקס (אם המכונות שלכם מבוססות לינוקס) ובמקרה של אוטומציה – עדיף שתדעו Chef או Puppet וכמובן שידע כלשהו ב-Ruby זה לא יזיק. אם אתם חובבי Ansible (הח"מ חובב זאת) אז יש תמיכה ישירות ב-AWS כולל עבודה יותר קלה בהשוואה ל-CloudFormation של אמזון.

על יעילות IT בחברות

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

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

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

בפוסט זה אני רוצה לדבר על 3 נקודות:

  • על Image ועל נחיצות Image להתקנה על מחשב
  • אוטומציה
  • תיעוד

נתחיל בעניין Images:

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

אך כשזה מגיע למחשבים ניידים לדוגמא, הרעיון של Image בניגוד למה שחושבים הוא אינו יעיל. קודם כל, תסתכלו בכל חברה ותראו מספר דגמים של מחשבים ניידים (מה לעשות, ההנהלה מקבלת דגמים הרבה יותר יקרים מהעובדים), כך שגם אם ניצור Image והמחשב יהיה מוכן להתחברות ל-AD, אנחנו נצטרך להריץ עדכונים של מיקרוסופט, עדכוני דרייבים ותוכנות של יצרן המחשב, עדכוני תוכנות צד ג' (פלאש, JAVA וכו') כך שהזמן מרגע הפעלת המחשב עד שהוא מוכן לשימוש אינו קצר, ואגב – אם תבדקו לדוגמא את השחזור מערכת הפעלה שהיצרן מספק ב-Partition נפרד, תראו שהוא אינו מזריק Image ל-Partition המרכזי אלא יש שם מספר קבצי BAT שמתקינים WIM בסיסי ועל זה הם מתקינים אפליקציה אפליקציה והגדרות עד למצב קבלת מערכת מוכנה (במפעלים המצב שונה כמובן כי שם יש שכפול מכני של הדיסקים באלפים, אם כי גם שם בחלק מהתהליך יש "הזרקה" של נתונים כמו מספר סידורי של Windows ל-UEFI ועוד).

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

אפשרות אחת פשוטה היא שימוש ב-PXE (לדוגמא iPXE) כך שהמחשב הנייד יהיה עם דיסק קשיח ריק והמחשב יבצע Boot מהרשת, וב-Boot הזה ניתן יהיה להתקין WIM בסיסי לחלוטין ללא הדרייברים החיצוניים שהספק נותן (הדרייברים הללו במקרים רבים מוסיפים זבל רב – "מנהל תקשורת", "מנהל סוללה" למרות ש-Windows מספק את שניהם בצורה טובה כולל דרייברים שמספיקים להתחבר ל-LAN ולתת תצוגה) ועם NET. ו-PowerShell.

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

  • לחבר את המחשב ל-AD
  • לבקש שם משתמש של הבחור/ה שהולך להשתמש במחשב
  • לבדוק לאיזו מחלקה הוא שייך
  • להתקין לו את האפליקציות שהוא צריך ואפליקציות שהארגון מצריך
  • לבדוק PCI ID של ציוד שאין לו עדיין דרייברים ולהתקין אותם דרך SCCM (או OneGet או NuGet) עם ה-MSI שהיצרן נותן (כאן לדוגמא – של לנובו).
  • במידה ויש הגדרות מיוחדותת, הסקריפט יריץ סקריפט אחר שיבצע את ההגדרות
  • התקנת עדכוני Windows אחרונים, אנטי וירוס וכו'
  • חלק ידני – בקשת הכנסת סיסמא חדשה מהמשתמש הסופי.

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

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

לשם השוואה בעולם הלינוקס (כמו הפצת CentOS) כל הדבר הזה נעשה בקובץ kickstart די פשוט שהמערכת בעצמה יוצרת עבורך אותו בעת התקנת הפצת הלינוקס ומשם משנים את הקובץ ומריצים קבצי BASH אחרים במידה וצריך מתוך ה-kickstart.

נעבור לאוטומציה:

אם יש משהו שכל איש Devops מתחיל צריך ללמוד ומהר – זה לעשות לכל פיפס תהליך אוטומציה דרך כלי אוטומציה (Ansible, Chef, Puppet וכו') כך שהוא לא יצטרך לחזור על התהליכים – וזהו בדיוק אחד הדברים שלדעתי כל חברה צריכה לא רק בשרתים – אלא גם בדסקטופים.

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

ומכאן – לתיעוד/דוקומנטציה.

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

מדוע בעצם זה קורה?

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

וזו בדיוק הבעיה של ה-wiki הפנימי או ה-Sharepoint של החברה או כל מערכת תיעוד אחרת: היא מסובכת למשתמש, וברוב המקרים היא טקסטואלית ואינה מושכת. חושבים שמישהו ממחלקת השיווק ישב לקרוא מסמך שתומך כתב איך לתקן בעיה XYZ? תשכחו מזה – והנה עוד טיקט נוסף לרשימה הבלתי סופית של טיקטים שהתומכים יצטרכו לטפל ועוד זמן שנשרף.

מה ניתן לעשות? כמה דברים:

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

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

להלן הוידאו מכנס JAMF:

המעבר לעננים

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

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

האם המעבר לאופיס 365 תגרום ל-Corporates השונים בארץ לעבור לגמרי לענן? לעניות דעתי – לא כל כך מהר. בשביל Mail, השהיה (Latency) של 100 מילישניות לערך אינה כזה עניין גדול, לא מרגישים את זה, אך כשמדובר ב-RDP או פרוטוקולים אחרים כמו HTTP ואחרים – העניין הופך לבעייתי ובכלל בארץ, בניגוד לסטארטאפים שמתחילים מהדקה הראשונה עבודה על ענן, ה-Corporates מאוד שמרנים ויקח זמן עד שהם יעברו לענן. גוגל, אמזון ומיקרוסופט מודעות בהחלט לעניין, ומיקרוסופט לדוגמא מכינה את ה-Azure Stack – הנה לך אדוני המנמ"ר/CTO "מיני Azure" שכולו יושב ב-Data Center שלך. כל ה-DATA שלך יושב בחווה שלכם ושום דבר לא זז החוצה אם לא תרצה, ואם תרצה – תוכל לחבר את ה-Stack הזה בקלות ל-Azure הענן. גם אמזון התכוננו לרגע הזה והם חתמו עם VMWare על פרויקט חדש שנקרא VMWare Cloud on AWS שנותן לך גם פתרון שמשלב את ה-Data Center שלך עם AWS כך שתוכל להתרחב מה-DC שלך החוצה ל-AWS (והפוך). גם לגוגל יש פתרון שהוא בפיתוח ובשלב זה אין עליו מידע פתוח.

המעבר לענן, לעניות דעתי, לא יהיה שאלה של "אם" אלא "מתי". אני לא צופה שבשנה הקרובה חטיבות ה-Hosting בסלקום/בזק בינלאומי/אורנג'/טריפל C יודיעו בקרוב שהן עוברות להפסדים כי הלקוחות העיפו את השרתים מהן (לזה יקח זמן רב, אם בכלל) – אבל המחשבה והדיבור על מעבר של לפחות חלק מהתשתית לענן ציבורי תעלה שוב ושוב בכל "צומת" שהחברה תצטרך להשקיע סכומים נכבדים ב-IT: רכישת רשיונות למערכות הפעלה, מעבר לסטורג' גדול אחר, הקמת ענן פרטי (כמו OpenStack) וכו'. כמובן שיהיו גם מקרים רבים שגם בעוד 10 שנים השרתים יהיו פה ב-DC בגלל רגולציה במקרים שונים.

ובכל זאת, חברות רבות "מסתקרנות" לגבי מעבר לענן. הסיפורים של כל מיני סטארטאפים איך הם נותנים שרות למליוני אנשים ומשלמים רק כמה אלפי דולרים בודדים בחודש לספק הענן גורם לסקרנות ולרצון להתנסות, המחירים בסנטים גם קורצים לחברה שמסתקרנת רצון לטבול אצבעות, ואז הן הולכות למחשבונים של ספקי הענן ואחרי מספר חישובים הן נרתעות. סתם דוגמא: באמזון, שרת Windows יחיד עם 8 ליבות ו-32 ג'יגה זכרון עם דיסק (EBS) של 200 ג'יגה יעלה לחברה $733 בחודש וזה כמובן לא כולל תעבורה החוצה וגם התמיכה של אמזון היא ברמת הבסיס. זול – זה לא. (אגב, גם בגוגל וגם במיקרוסופט המחיר יהיה פחות או יותר זהה) – אז הרעיון לנסות מעבר כלשהו נכנס בחזרה למגירה.

הרווח הגדול של ספקי הענן הגדולים מגיע מהשכרת שרתים ובמיוחד מהליבות (cores). הם מוכרים כל ליבה במחיר מוערך של 30-50$ לחודש וגם הזכרון אינו זול (בערך 10-20$ לחודש, תלוי בקונפיגורציה, מערכת הפעלה, סוג תקשורת וכו'). מדוע? כי כמות הליבות שניתנת למכירה בשרת אינה כה גדולה. שרת עם 16 ליבות אפשר למכור לדוגמא ל-20 לקוחות שכל אחד מקבל ליבה, אבל לא ל-30 לקוחות – כי הלקוחות רוצים ביצועים (בניגוד לספקי VPS שדוחפים עשרות לקוחות על מכונה עם 8 ליבות). ספקי הענן יכולים לרכוש שרתים עם 8 מעבדים כשכל אחד מהם כולל 16 ליבות לדוגמא, אבל העלות של שרת כזה גבוהה מדי בשבילם ולכן ברוב המקרים אם תבדקו מה המעבד שנמצא במכונה שלקחתם מספק הענן, תמצאו שהמכונה מכילה מעבדים כמו Xeon E5 26XX (כלומר מקסימום 2 מעבדים ועד 8 ליבות פר מעבד, ברוב הזמן זה יהיה דגם של 4 ליבות). יש לספקי הענן גם מכונות עם מספר מעבדים וליבות גדולים, אך המחיר – גבוה בהרבה מהמחיר שציינתי.

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

אז איך לדוגמא חברת X תוכל להתנסות בענן ציבורי מבלי לשרוף אלפי דולרים בחודש על PoC?

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

אחרי שפתחנו חשבון אצל ספק הענן, נצטרך לבחור מה הפרויקט שאנחנו הולכים להעביר ואלו VM הולכים לעשות מעבר, והכי חשוב – כמה ג'יגהבייט/טרהבייט אתם הולכים להעביר לספק ענן. אם מדובר לדוגמא בג'יגהבייטים בודדים או עשרות בודדות של ג'יגהבייט, אפשר להעלות את קבצי ה-VM דרך האינטנט, אך אם מדובר בעשרות או מאות ג'יגהבייט או יותר – כדאי להשתמש בשרותי ה-import/export Disk של ספק הענן, כלומר תצטרכו להכין דיסק קשיח (או פתרון אחר בהתאם לספק הענן) ולשלוח אותו לפי הוראות ספק הענן. המחיר – דווקא די זול, בסביבות ה-80$ ועוד 2.50 דולר פר שעת עבודה להעלאת הנתונים (אמזון לדוגמא).

לאחר שהנתונים יועלו לספק הענן, נצטרך להתחיל לבנות את התשתית המאובטחת שלנו מבחינת כתובות IP פנימיות, Subnet, Internet Gateway וכו' וכו' ולהחיל אותם על ה-VM שלנו שבענן (אצל חלק מהספקים יש צורך בהקמת ה-VM מהגיבוי שהעלתם/שלחתם, אצל חלק זה אוטומטי). אחרי שיש לנו את ה-VM למעלה, יכול להיות שנצטרך לשנות כתובות IP בהתאם לתשתית שהגדרנו. המטרה הסופית היא שבסוף כל ה-VM ששלחתם יעלו ותהיה לכם תקשורת אליהם בדיוק כמו שיש אצלכם ב-DC (אם כי ישנם שינויים שתצטרכו לעשות, כמו לא לתת כתובת IP חיצונית לכל שרת אלא לעבוד בצורה מסודרת מול Gateway או עם Bastion אם אתם עובדים עם מכונות לינוקס). הכל עובד? מצוין. בשלב זה תתחילו לעבוד עם המערכת כמו שהיא בימים או שבועות הקרובים. קיבלתם קרדיט, זה לא עולה לכם שקל, נצלו את זה 🙂

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

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

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

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

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

ולמי שמעוניין לעבור את התהליך או לקבל יעוץ – אשמח לסייע 🙂

על CI/CD ועל Jenkins

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

נתחיל בהסתכלות על המצב ה"קלאסי" של פיתוח, אצל חברות שמפתחות תוכנה המשווקת לציבור. בחברת הפיתוח יושבים כמה מפתחים וכל אחד (או קבוצה) אחראים לפיתוח חלק כלשהו. GUI, לוגיקה, ועוד ועוד. כל קבוצה (או יחידים) מפתחים בנפרד ובסוף יום (או כמה פעמים ביום) כל אחד מעלה את הקוד שלו למערכת SCM (ר"ת Source Code Management) ואחת לזמן מה מגיע החלק הקשה – איחוד הקוד של כל האינדיבידואלים או הקבוצות השונות לקוד אחיד למה שיהיה בהמשך גירסה חדשה של התוכנה. באיחוד כזה מתרחשים הרבה קונפליקטים מבחינת קוד – אחד שבר (בטעות) קוד ישן, השני הגדיר דברים בצורה שונה והקוד שלו בעייתי לאיחוד, ויש עוד שלל בעיות באיחוד קוד (שלא לדבר על ההערות שנזרקות…) שנכתב לאורך תקופה ללא איחוד. אלו כמובן בעיות שיש להן פתרון (במיוחד עם GIT..) ולכן עולה השאלה "בשביל מה אנחנו צריכים CI/CD אם אנחנו לא סטארט-אפ?"

ל-CI/CD (ר"ת של Continuous Integration ו-Continuous Deployment בהתאמה) יש (די בצדק) שם שמתאים לפיתוח בדרכים של ASD (ר"ת Agile Software Development) או בשם יותר ידוע – XP (ר"ת Extreme Programming), מה שדי מרתיע חברות פיתוח "קלאסיות" מאימוץ CI/CD, אבל יש יתרונות גדולים ל-CI/CD:

  • זמן פיתוח קצר בהרבה
  • שמירת תאימות לאורך זמן
  • תיקון באגים בזמן קצר בהרבה בהשוואה למצב הקלאסי
  • ה-Time To Market מתקצר משנים לימים או שבועות.
  • לקוחות מקבלים יותר פונקציונאליות ושרותים נוספים מבלי להמתין זמן רב עד שהחברה תכתוב את הקוד הכרוך בפונקציונאליות הנוספת.
  • קל למצוא באגים בקוד ולתקן במהירות.
  • כל המערכת רצה בצורה הרבה יותר יציבה
  • זמן ה-Downtime מתקצר לאחוזים בודדים

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

Image result for jenkins logoנכיר בקצרה את Jenkins. מערכת Jenkins נוצרה ב-2005 ע"י מפתח שעבד ב-Sun ו-Sun שחררה את הקוד לקהילה והמוצר עבר שינויים שונים במהלך חייו והיה נקרא Hudson. ב-2011 חברת אורקל (שרכשה את SUN) הצליחה להסתכסך עם קהילת המפתחים בקוד פתוח ולפיכך המפתחים החליטו לקחת את הקוד ולפצל (Fork) את המוצר ולתת לו שם חדש: Jenkins.

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

אחרי שהקמנו מערכת Jenkins, אנחנו מתחילים להשתמש בה והעבודה ב-CI/CD מתחילה עם המפתחים. אחרי שהמפתחים דחפו את השינויים מגיע תור ה-CI Server או במקרה שלנו – Jenkins לעשות את העבודה. ניצור JOB שבו בעצם אנחנו מגדירים ל-Jenkins מה לעשות. מהיכן לקחת את הקוד, מה לקמפל, ומה לעשות עם הקבצים (כמו לדוגמא האם להעביר אותם בדיקת סגנון קוד עם SonarQube לדוגמא) להעלות אותם ל-Artifactory, לשרת אחר וכו'.

מבחינת המפתחים, כשעובדים ב-Continuous Integration כל מפתח כותב את הקוד שלו, מוריד את הקוד של האחרים מה-SCM, משנה את הקוד שלו בהתאם על מנת לאחד אותו עם השאר, מריץ קוד בדיקות (Unite Testing), ולאחר שהקוד עבר בהצלחה בדיקות מקומיות, הוא מבצע Push ל-SCM. את התהליך עושים מספר פעמים ביום בכל פעם שכותבים חלק, לדוגמא – כותבים פונקציה חדשה, משפרים משהו קיים, מתקנים באגים וכו'. משם Jenkins ימשיך את תהליך ה-CI אם נגדיר לו מתי (אם לבדוק את ה-SCM אם מישהו ביצע commit לדוגמא, או לפי שעון).

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

מכאן אנו עוברים לחלק של ה-CD או ה-Continuous Deployment: קימפול והכנת קבצים בינאריים וחבילות זה טוב – אבל צריך לעשות עם זה משהו…

ב-Jenkins יש לנו "צינורות" (Pipelines) ועם הפונקציונאליות הזו אנחנו נגדיר ל-Jenkins מה אנחנו הולכים לעשות עם הקבצים הבינאריים. אנחנו יכולים לדוגמא להגדיר בצינורות לזרוק את הקבצים הבינאריים בשרת טסטים, להריץ טסטים שונים (Unit tests, Selenium ועשרות סוגים שונים של בדיקות, תלוי בקוד, פלטפורמה וכו'). לאחר שהקבצים עברו בהצלחה בחינה, אנחנו יכולים להורות בצינור לבצע Deploy של החבילות בשרת "מראה" של פרודקשן להתקין את החבילות ולהריץ בדיקות שונות נוספות. לאחר שגם כאן הבחינות עוברות, אפשר להורות בצינור להטמיע את החבילות החדשות בשרתי הפרודקשן באופן אוטומטי או לפי הוראה של המפתחים/מנהלים.

ci-cd-jenkins
כך נראית החלוקה בין CI ל-CD

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

בסופו של יום, לקוחות דורשים מיצרניות התוכנה והשירותים דברים רבים והם מעוניינים במענה מהיר ואם הם לא מקבלים, הם לא מתביישים להתחיל לבדוק את הפתרונות של המתחרים (תשאלו את Pay pal) ואף לעבור למתחרים, מה שעלול לגרום הפסדים כספיים. עבודה ב-CI/CD יכולה לעזור בקיצוץ הזמנים באופן ניכר.

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

מבחינת תאימות פלטפורמות – Jenkins הוא קוד פתוח מ-א' ועד ת' והוא רץ יפה מאוד על Windows (לא צריכים Windows Server), מק וכמובן לינוקס. הוא תומך בכל שפה, ויש לו יותר מ-1200 תוספים שונים שכוללים תמיכה בכל SCM, בכל קומפיילר, אותנטיקציה, אחסון וכו'. יחד עם זאת, כדאי לקחת בחשבון שלא כדאי "לערבב" – אם לדוגמא הקוד שלכם כתוב ב- #C, הקימו את Jenkins על Windows, אך אם אתם כותבים בשפות אחרות שרצות על לינוקס, עדיף להרים את ה-Jenkins על לינוקס הואיל ותחזוקת האבטחה הרבה יותר קלה.

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

הערת מפרסם
הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.

השינוי המהותי שצריך במערכות הפעלה

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

אנחנו עובדים בשיטות האלו זמן רב, 22 שנה ליתר דיוק אם מסתכלים על השוק האינטלי לדוגמא, עוד מאז שאינטל הכניסה את Protected Mode למעבדי i386. אמנם Windows בזמנו לא נתנה ריבוי משימות אמיתי (היא נתנה "החלפת משימות" – Task Switching) אך מערכות יוניקס אחרות (SCO וכו') דווקא נתנו.

אבל הבעיה המרכזית במערכות הללו, היא עניין ההפרדה המוחלטת שאינה ממש קיימת. כן, אפליקציות שונות מופרדות זו מזו, כמעט כל אחת גם כותבת למקום אחר בדיסק הקשיח, אך עדיין בדיקה ב-Task Manager (או TOP/PS בלינוקס/מק/יוניקס) יראו את כל הפרוססים של אותן אפליקציות. נכון, המשתמש שאינו בעל הרשאות כ-root/Administrator לא יוכל לגשת אליהן ו"להרוג" אותן, אבל הוא יכול לראות אותן וכנ"ל לגבי דיסק קשיח – כל אפליקציה יכולה לגשת לכל הדיסקים הקשיחים ולכל קובץ.

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

בעולם הלינוקס/יוניקס היו פתרונות שונים – ל-Solaris החל מגירסה 10 היתה תת מערכת של קונטיינרים שנקראה Zones שבה היה אפשר להרים מעין VM מבוסס סולאריס (בלבד, מאוחר יותר זה השתנה במעט) ובלינוקס היה בהתחלה את chroot ומאוחר יותר את LXC ובשנים האחרונות את Docker והמתחרה שלו – RKT. כל הפתרונות הנ"ל הציעו ברמת המאקרו סביבות נפרדות ללא צורך באמולציה של חומרה תוך הסתמכות על שרותי Kernel שרץ על השרת הפיזי. בעולם ה-Windows מערכת Docker הגיעה קצת יותר מאוחר בהשוואה ללינוקס, וכיום ב-Windows 2016 יש מערכת Containers מבוססת Docker.

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

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

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

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

שינויים כאלו אינם ניתנים לביצוע ביום או יומיים (אם כי בלינוקס יש לדוגמא את CentOS Atomic Host שמיועד בדיוק לדברים אלו), אולם לעניות דעתי שינויים אלו הכרחיים אם אנחנו מעוניינים באבטחה רצינית וביציבות יותר גבוהה לשם הרצת אפליקציות. עברנו מזמן את הימים בהם מערכת דסקטופ לדוגמא הכילה 1 ג'יגהבייט זכרון ו-20 ג'יגהבייט דיסק קשיח, כך שכל מערכת מודרנית לא אמורה לסבול מהאטה בביצועים בגלל הטמעת פתרון כזה.

הערת מפרסם
הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.