על "ספריות" וריבוי עננים

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

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

הבעיה הכי גדולה בד"כ כשמנסים להתממשק במקביל לענן פרטי וענן ציבורי, זה שכל ענן מצריך סקריפטים ו/או אפליקציות שונות להתחבר אליהם. ה-vSphere Client שלך לדוגמא לא יכול לדבר עם Azure או GCE, ולמרות שניתן לחבר אותו ל-AWS, לא ניתן לבצע דברים מרובים שקשורים בסטורג' בענן כמו S3 או דברים אחרים (כמו EFS לדוגמא). חמור מכך – כשיש לך תשתית מורכבת בענן הפרטי ובענן ציבורי, שתיהם יצטרכו תחזוקה אחרת. אחרי הכל, אם אתה משתמש לדוגמא ב-CloudFormation של אמזון, זה לא יעזור לך ממש מול כל ענן אחר, פרטי או ציבורי.

ישנם מספר פתרונות לכך, כולם מבוססים על ספריית libcloud של Apache והם:

פתרונות אלו יכולים לתת לחברה חופש לעבוד כמעט עם כל פתרונות וירטואליזציה מקומית (למעט Hyper-V – זה יותר באשמת מיקרוסופט שעדיין לא מתקנת את התמיכה שלה ב-libvirt) ובמקביל מאפשרת לעבוד עם כל ענן ציבורי, מהגדולים ועד הקטנים (הרשימה המלאה כאן). כך לדוגמא, אם אתה רוצה להרים מספר מכונות עם תשתית רשת פשוטה לצורך ביצוע עבודות שונות, אתה יכול לבחור לדוגמא ב-Digital Ocean או Linode ששם המחירים יותר זולים מהמחירים של ספקי הענן הגדולים ובנוסף אתה לא משלם על התעבורה החוצה (עד 3 או 5 טרהבייט כל חודש). אינך צריך לבנות את הסקריפטים מאפס אלא פשוט להשתמש בספריית libcloud ובפתרון שמתאים לשפה שאתם עובדים איתה כדי להרים את התשתית, לבצע שינויים וכו' ובכך תוכל בשימוש בספריה הזו לשלוט בכל תשתיות הענן שאתם משתמשים ללא צורך בכתיבה מיותרת של ערימות סקריפטים.

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

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

על אחסון ווידאו בחברות מדיה

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

בעולם ה-Corporate, סטורג' הינו חלק קריטי מהתשתית. מכונות VM מאוחסנות על סטורג' ולא על דיסקים מקומיים, אפליקציות כמו SQL/Oracle DB דורשות סטורג' (במיוחד אם מריצים כתצורת אשכול [cluster]), כל קבצי העבודה של העובדים (מסמכים, קוד וכו') מאוחסנים בסטורג', גיבויים זמניים מאוחסנים בסטורג' ובקיצור – הסטורג' "נוגע" כמעט בכל תחום. אחרי הכל, כולם מכירים: כשסטורג' נופל – ההיסטריה בשיאה.

בשנים האחרונות, עם חדירת העננים הציבוריים ל-Corporate – השימוש ב-Storage פוחת במעט (ככל שמעבירים VM ושרותים לענן), אך עדיין לסטורג' יש מקום מאוד שוב. יחד עם זאת, כמות השדרוגים או רכישות סטורג' חדש – מתמעטת. אחרי הכל, אם "העפתי" 50 VM ל-AWS לדוגמא, והם יעבדו ב-AWS באופן קבוע, אני אשמור מקומית גיבוי, אבל אני לא אצטרך להשאיר אותם ב-Datastore היקר המקומי, אני אמחק אותם ואז יתפנה לי מקום בסטורג', מה שאומר שרכישת עוד מדף סטורג' תיהפך למיותרת. בנוסף, בעולם ה-Corporate הגדילה היא איטית. לא כל יום מרימים עוד 100 VM (וגם אם מרימים, משתמשים ב-Template כך שרק השינויים נשמרים ולא כל VM שוקל 10 ג'יגה ומעלה).

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

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

מדוע? כי חברות הוידאו דורשות צילום איכותי וגבוה. פעם היו מסתפקים ברזולוציית SD ולאחר מכן העולם קפץ ל-HD ול-Full HD וכיום הרוב מצולם ב-4K או 5K ו-6K וחלק (שמשתמשים ב-RED לדוגמא) מצולם בכלל ב-8K. בניגוד לצילום באייפון (או גוגל פיקסל) – מצלמות מקצועיות מצלמות ב-Bitrate החל מ-20 מגהביט ועד 80-130 מגהביט (ומעלה במקרה של RED אם לא משתמשים ב-REDCODE) ועוד לא דיברנו על ביטים פר ערוץ צבע (8,10,12 וכו') ועוד. במקרים רבים מצלמים ב-2 מצלמות (או יותר), נוסיף אודיו שמוקלט בנפרד, צילומי סטילס (בחלק מהמקרים). את כל הערימה הזו צריך להעלות לאיזה סטורג' כלשהו ובחלק מהמקרים צריך גם לתרגם (Transcode) ל-Codec אחר (מה שנקרא Mezzanine Codec) בכדי לאפשר עבודה רציפה על התכנים בהתאם לתוכנת העריכה המועדפת על החברה. אחרי זה יש צורך בעריכה של הקובץ, הוספת תכנים שונים (אפקטים, תלת מימד, אנימציות, אודיו וכו'), ולבסוף יש צורך שוב בהמרה של התכנים לפורמטים שונים (הוצאה לאולפנים שונים בהתאם לדרישות שלהם, יוטיוב, סטרימינג וכו').

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

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

הבה נאמר שלחברה יש סטורג' כיום זמין שאליו מתחברים עורכי הוידאו ומשתמשים בתכנים. אחרי שהתוכן עבר עריכה והמרה – יש צורך לאחסן את התכנים על מנת שיהיו זמינים מיידית. כאן פתרון Scale Up פתוח (כמו ZFS) יכול להוות פתרון מעולה תוך שימוש בשרת יחיד שאליו משורשרים מספר JBOD ובתוך אותה מערכת יש מספר קטן של דיסקים SSD מהירים והשאר – דיסקים SATA פשוטים (או SAS או NL-SAS, בהתאם לתקציב) וגדולים מאוד (8,10,12 טרהבייט) עם תצורת RAIDZ שמאפשרת מצב שגם אם 2 דיסקים קשיחים נדפקים, התוכן נשאר תקין בצורה זמינה. זיכרו – סטורג' זה משמש רק לאחסון ולא לעבודה ישירות, כך שעורך שצריך תוכן כלשהו, רואה את הקבצים כ-Read Only ללא אפשרות שינוי. נגמר המקום? מוסיפים JBOD גדול עם 36 דיסקים (לדוגמא) וכל דיסק הוא בגודל 10 טרהבייט, ב-RAIDZ2, הרי שנטו נקבל תוספת של 309 טרהבייט, ואם חברה רוצה ממש אחסון של 1 פטהבייט, אז 4 JBOD כאלו מלאים יתנו 1.2 פטהבייט עם שרידות טובה.

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

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

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

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

לעומת זאת, חברות לא מעטות בארץ ובחו"ל מעדיפות את הענן של מיקרוסופט, וכאן איש ה-Devops יצטרך יודע ידע בטכנולוגיות של מיקרוסופט (PowerShell ואחרים) כדי לעבוד. מיקרוסופט נותנים SDK לשפות אחרות ו-CLI למערכות הפעלה פופולריות, אך מי שעובד לדוגמא הרבה עם AWS ויעבור להשתמש ב-Azure, יגלה לאחר זמן מה שמיקרוסופט יותר משקיעה בטכנולוגיות שלה מאשר בטכנולוגיות האחרות. כך לדוגמא אם תרצה לבצע אוטומציה עם הכלים הפופולריים בלינוקס, החיים שלך לא יהיו כל כך קלים.

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

סיכום שנת 2016 – אחסון מבוסס קוד פתוח

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

מבחינת מוצרים מסחריים, ScaleIO של EMC יצא השנה בגירסה 2.0 עם שיפורים ניכרים הן בטכנולוגיה והן מבחינת ביצועים (לתשומת ScaleIO – אכפת לכם לרדת משמות ציודים כמו dev/sda/? היום הכל הולך ב-UUID, כך שמי שמזיז דיסקים, לא יקבל שמות שונים ומערכת שנופלת!). עוד ועוד חברות מוציאות Appliances שמשתמשים במוצרי קוד פתוח קיימים (Gluster, Ceph, ZFS) כדי למכור פתרונות Scale Out המאפשרים הרחבה לגדלים של פטהבייטים ומעלה. קשה לפרט כי יש המון כאלו.

מבחינת פתרונות Scale Up, עדיין ZFS שולט בראש, ומוצרים הכוללים אותו (QuantaStor, FreeNAS ואחרים) הולכים ומשתפרים "מסביב" – כלומר הטכנולוגיה נשארת אותה טכנולוגיה, רק שנוספים דברים כמו תמיכה יותר טובה ל-Active Directory, מכונות וירטואליות קטנות שניתן להרים על הקופסא הפיזית של ה-Storage (במקרה של FreeNAS) ועוד. השנה גם אינטל החלה להיכנס בזהירות לתוך ZFS (במיוחד ללינוקס) עם תרומות קוד בכל הקשור לטסטים ונסיונות על מכונות עם דיסקים מרובים (מה לעשות, אין הרבה חברות שמרימות מכונות עם 40+ דיסקים מכניים + SSD רק לשם טסטים). השנה גם עניין ההצפנה נכלל באופן טבעי ב-ZFS עם מספר אפשרויות להצפנה הן ברמת קובץ או Volume וכו'.

מבחינת Scale Out – פתרונות CEPH שולטים כפתרונות קוד פתוח וחינמי/זול. השנה סוף סוף הגיעה היציבות ל-CephFS כך שניתן לבצע ישירות mount ל-CephFS לשרתי לינוקס שונים ללא צורך בהגדרות מיוחדות. השנה החלה גם להיכנס (עדיין לא בצורה יציבה אלא כ-Technology Preview) ה-BlueStore – טכנולוגיה שכותבת את המידע שמגיע ל-Ceph בצורה שונה ויותר אופטימלית כך ששימוש ב-SSD ב-Ceph יכול לתת ביצועים פי 2 ומעלה. עוד דבר חשוב – טכנולוגיות דיסקים חדשות (PMR, SMR וכו') נתמכות ב-BlueStore עוד הרבה לפני הפתרונות הסגורים המסחריים (לא מומלץ להכניס דיסקים SMR לפתרונות סטורג' ל-VM או דברים כאלו, אלו דיסקים שמיועדים לגיבוי וארכיבאות בלבד)

וכמובן, 2 שאלות שאני תמיד נשאל היא "האם שווה לנו לרכוש פתרון כזה? זה נותן מענה?"

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

למי שמחפש את הגירסה הארוכה:

אם נסתכל מבחינת ביצועים נטו, הן ZFS והן Ceph יכולים להוציא מיליוני IOPS בלי יותר מדי בעיות ולשרת משתמשים מרובים בצורה חלקה. כמובן שיש צורך בלהגדיר דברים רבים בשביל להגיע לתוצאות אלו – אך זה בהחלט דבר אפשרי, הן לעבודה מול שרתי וירטואליזציה, עיבוד תמונה, עיבוד וידאו, הזרמת וידאו וכו' וכו'. יחד עם זאת – אני לא ממהר להמליץ לזרוק את ה-Netapp/EMC/3PAR שלכם לטובת מערכות כאלו מהסיבה הפשוטה שיש הרבה דברים שהמערכות הסגורות נותנות וזה כולל ממשק נוח, הרחבות שונות קנייניות שעוזרות בעבודה של הסטורג' ועוד.

ב-2 הפתרונות, ניתן לייצא החוצה קבצים ב-CIFS ו-NFS וכמו כן Block Devices (כמו iSCSI).

בד"כ הסיטואציות שאני ממליץ להשתמש בפתרונות קוד פתוח הן:

  • בתוך LAB
  • בשימוש בוירטואליזציות קוד פתוח (Open Stack, KVM, Xen, Oracle VM, VirtualBox)
  • שרת אחסון נתונים הן כגיבוי והן כהזרמה (Streaming – לגיבוי אני יותר ממליץ את ZFS)
  • צוותי פיתוח (לזה אני ממליץ יותר את ZFS)
  • מקומות עריכה גדולים של וידאו (4K), אודיו וסטילס (פוטושופ)

מבחינת בחירת פתרון – Ceph ו-ZFS דורשים פתרונות חומרה שונים לחלוטין. ב-Ceph מתחילים עם 3 שרתים יעודיים (שלא יריצו כלום חוץ מ-Ceph) ומתג רציני (10 או 40 ג'יגה) וזה הפתרון שמאוד מתאים לחברות שרוצות להגדיל את הנפחים ומהר או להתחיל מההתחלה במאות טרה בייט ולגדול לפטהבייטים ומעלה. לעומת זאת, ZFS שאמנם יכול לגדול ל-Zettabyte עם תוספת בקרים שונים וקופסאות JBOD נוספות, אך הגדילה שלו מעבר לפטהבייטים מצריכה הרמת אשכולות ZFS ושימוש בפתרונות כמו Lustre וזהו עניין שבהחלט אפשרי – אך מורכב.

מבחינת חסכון: פתרון קוד פתוח לא מבטיח עלות אפס גם אם אתם מיישמים לבד הכל. כן, זה יהיה יותר זול מפתרון קנייני, אבל דיסקים, דיסקים SSD ל-Enterprise, המכונות עצמן, מתגים וכו' – עולים לא מעט ותחזוקת החומרה היא עליכם. בנוסף, יש לא מעט מקרים שאני ממליץ (במיוחד ב-Ceph) לרכוש את הגירסה המסחרית של תוכנת הקוד הפתוח על מנת לקבל עדכוני תוכנה ותיקוני תוכנה וכדאי לקחת זאת בחשבון (במקרה של Ceph ישנו הפתרון בישראל של SuSE SES 4 ו-RedHat Storage 2.1 – שתיהן מבוססות על Ceph בגירסת Jewel).

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

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

"מאחורי הקלעים" של אבטחת שרתים

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

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

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

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

אז זהו, שזה הפוך.

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

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

אחרי שעוברים את המשוכה הזו, צריכים להחליט את מה מקשיחים. התשובה לשאלה כזו בד"כ תיענה ב-"את הכל", וכאן מתחילה בעיה. בחברה קטנה עם 4-5 מכונות לינוקס העניין פשוט וקל, אותו דבר בייצור Appliance, אבל כשיש לחברה מאות או אלפי מכונות VM שמריצות לינוקס, הבעיה הרבה יותר מורכבת: לכל גירסת הפצת לינוקס יש לממש את סטנדרט ה-CIS שלה ברובו מחדש, כך שמדובר פה על השקעה שיכולה לקחת מספר חודשים. הסטנדרט שונה בין CentOS לבין SuSE לבין אובונטו ורק חלק קטן מהסטנדרטים חופף בין ההפצות. כמובן שאם כל המכונות שלכם מריצים את אותה הפצת לינוקס ואותה גירסה – אז חייכם דבש 🙂

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

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

זהו, שלא ממש..

אחת הבעיות המרכזיות כשזה מגיע לאבטחת שרתים, היא בעיית חורי אבטחה שמתגלים כמעט כל יום. העדכונים לחורי האבטחה מגיעים רק לאחר מספר ימים (במקרה הטוב) או כמה שבועות (במקרה הפחות טוב) או אפילו חודשים (אהלן מיקרוסופט!). מה עושים עד אז? בד"כ יצרניות ההפצה יתנו הוראות מניעה זמניות כיצד לפתור לבינתיים את הבעיה. העניין הוא שההוראות מגיעות באנגלית ואולי עם דוגמא לסקריפט BASH או Python. איך בדיוק תפיץ את זה למאות שרתים? אתה כמובן יכול לבנות חבילה (RPM או DEB), להוסיף ל-REPO מקומי ולהפיץ זאת דרך תוכנת העדכונים שלכם, אבל תצטרכו איכשהו לעשות לתיקון הזמני Roll Back וזה לא ממש קל, במיוחד אם חור האבטחה נוגע לאפליקציה שיש לה המון תלויות ואז מדובר במתכון בטוח לכאב ראש פר שרת.

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

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

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

מעבר לענן שאלות ותשובות (חלק 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, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.