כמה מילים על WSL 2

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

מיקרוסופט בשנים האחרונות ביצעה כמה שינויים על מנת לכלול תאימות למערכות אחרות. כך לדוגמא ה-command prompt הישן קיבל מתיחת פנים הן ב-Power Shell ומאוחר יותר גם בתאימות להצגת טרמינלים מרחוק (בחיבור SSH או Telnet). זה לא היה מושלם – אבל זה היה צעד חשוב, במיוחד כשמיקרוסופט החלו לשלב גם SSH Client בתוך Windows 10 לגרסאותיו השונות.

בכנס Build האחרון מיקרוסופט הציגה את ה-Windows Terminal שלה – שיפור משמעותי לעומת ה-CMD הישן והקונסולה של PowerShell. הפעם יש טאבים, תמיכה ב-Emoji, קאסטומיזציה ועוד ועוד. בקצרה זה נראה כך:

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

מכאן נעבור לנושא הפוסט: WSL 2.

למי שאינו מכיר, WSL (ראשי תיבות Windows Subsystem for Linux) זו מערכת שמיקרוסופט פיתחה שמשתלבת עם ה-NT Kernel (כן, Windows 10 מבוסס על NT, כמו רוב גרסאות ה-Windows בשנות ה-2000). המערכת הזו משמשת כ"מתרגם" מה-API של ה-Linux Kernel (גירסה 4.4 של ה-Linux Kernel) ל-NT API. בנוסף, המערכת גם דאגה להרשאות מיוחדות של קבצים ותיקיות כך שלא היה צורך ליצור Partition של לינוקס מצד אחד, ומצד שני קבצים בינאריים של לינוקס לא יכלו לרוץ על Windows שלא מותקנת בה WSL. כל הקונסטרוקציה הזו נועדה לתת מספר דברים:

  • לאפשר לבנות הפצות לינוקס ידועות שירוצו ישירות עם ה-WSL ללא צורך במערכת לינוקס ב-VM
  • לאפשר להריץ אפליקציות לינוקס בהתאם להעדפות שלכם.
  • אין צורך בלשלב קוד GPL כמו ה-Kernel לתוך המערכת.

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

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

התוצאה: WSL 2.

השינוי המהותי עם WSL 2 שהפעם יש מעין "מיני VM" קטן שעושה Boot ומטעין גירסה מאוד מקוצרת של ה-Kernel, אך ללא ה-1001 דרייברים שמגיעים עם ה-Linux Kernel וכל הדרייברים הנחוצים שלינוקס צריך – הוא מקבל אותם דרך דרייברים Paravirtualized (קצת מזכיר את ה-VMWare Tools שמתקינים). כך, מצד אחד ה-Kernel רץ בצורה מבודדת כ-VM קטנטן, ומצד שני מיקרוסופט לא צריכה להסתבך עם ה-GPL: הם ישחררו את שינויי הקוד שהם צריכים לשחרר ואין נגיעה ישירה לקוד של Windows.

בשיטה הזו, ה-WSL 2 מקבל מספר דברים:

  • אפשרות להשתמש בגירסת Kernel מודרנית (אני מאמין שמיקרוסופט תוציא מסמך איך לקמפל קרנלים משלך לשימוש ב-WSL 2)
  • אפשר להשתמש בדברים כמו cgroups, להריץ קונטיינרים (docker, cri-o וכו')
  • כל גישת ה-File/Directory תעבור דרך דרייבר שמיקרוסופט תשחרר ש"ידבר" עם NTFS, ומיקרוסופט טוענים כי בדיקות שלהם מראות כי הביצועים משתפרים פי 20 בהשוואה ל-WSL 1.
  • יותר אפליקציות יוכלו לרוץ.

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

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

קצת על Guacamole, כניסה מורשית ואבטחה

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

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

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

הנה שיטה שאני משתמש בה ואולי היא יכולה להיות ישימה גם אצלכם.

קצת רקע: עבדכם הנאמן נותן שרותי יעוץ ואינטגרציה למגוון פלטפורמות. חלקן פופולריות ומוכרות (כמו vSphere) וחלקן קצת פחות – כמו oVirt, OpenShift, OpenStack, Ceph, Gluster, Kubernetes (ויש עוד לא מעט תוכנות) וכמובן מערכות לינוקס שונות. כל המערכות הללו רצות נון סטופ אצלי ב-LAB מסיבות שונות:

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

וכאן אולי אפתיע אתכם: אני לא משתמש ב-VPN או תוכנות שליטה מרחוק מבחוץ. זה לא בעיה של רשיונות או בעיה של התקנת VPN.

אני משתמש ב-Guacamole.

למי שלא מכיר, Guacamole היא אפליקציית Java שרצה תחת Appplication Server כמו Tomcat או Wildfly (או JBOSS) המאפשרת חיבור מכשירים, תחנות ושרתים לממשק Web מאוחד, הגדרת משתמשים והרשאות וכניסה דרך הדפדפן לתוך כל חיבור. יש כמובן מספר תוכנות כאלו שנמצאות בכל חברה המאפשרות להתחבר ב-SSH/Telnet/RDP/VNC, רק שאת Guacamole לא צריך להתקין על כל מכונה. מספיק שיש דפדפן סטנדרטי ומודרני.

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

  • הראשון הוא עניין TOTP (כלומר Time-based One-time Password) – כך שמי שמתחבר מבחוץ יצטרך להשתמש ב-MFA בכל פעם שהוא מתחבר (בנוסף לשם משתמש וסיסמא)
  • הגישה שהוא מקבל – היא למכשיר/מכונה אחת או יותר שהוא צריך. אם הוא ינסה להיכנס למכונות אחרות – אני יוכל לראות זאת.
  • המכונה שהוא ניגש אליה – שמורה ב-snapshot ב-ZFS כך שאם הוא יגרום נזק, אפשר תוך שניות ספורות לחזור אחורה.
  • וכמובן הכל מוקלט – ל-Guacamole יש אפשרות "הקלטת session" שמקליט כל מקש שהמשתמש מבחוץ מקיש ומה הוא רואה על המסך, כך שאני יכול לראות בזמן אמת מה הוא מקיש ומאוחר יותר אני יכול להמיר את ההקלטה לקובץ MP4 כדי לראות בבירור מה בוצע במכונה.
  • מכונות קריטיות ב-LAB – אינן זמינות דרך ה-session.
  • הגישה מבחוץ זמינה רק לאחר שהפעלתי זאת. כברירת מחדל, אין גישה מבחוץ לשום דבר.

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

על מנת לממש את הדברים ב-LAN של חברה, מבצעים את הצעדים הבאים:

    • מקימים מכונת VM עם לינוקס ועליה מתקינים את Guacamole ומוסיפים את תוסף ה-TOTP (לחובבי אובונטו, יש בלינק הזה סקריפט מוכן להתקנת האפליקציה באופן אוטומטי)
    • מגדירים משתמשים (אפשר לחבר את זה ל-Active Directory לפי ההוראות בקובץ PDF זה. זה קצת מורכב) ומגדירים סשנים למכונות או ציוד שיש צורך בגישה אליהם. שימו לב – כל סשן למעט עם חיבור VNC מתנתק ברגע שסוגרים את ה-TAB, כך שאם רוצים להשאיר דברים רצים בלינוקס לדוגמא, אפשר להשתמש ב-nohup או להשתמש ב-screen או TMUX.
    • מגדירים אלו סשנים יהיו זמינים לאלו משתמשים
    • על מנת שסשן יוקלט, בכל הגדרת חיבור יש בסוף הדף הגדרות להקלטה. בד"כ יספיק path ושם כלשהו כדי להפעיל את ההקלטה (ההקלטה תישמר בתוך שרת ה-Guacamole, לא במכונה שמתחברים אליה דרך ה-Guacamole). חשוב לזכור, ההקלטה היא בפורמט דחוס שיש צורך בהמרה, ואותו כדאי לשמור בסטורג' או ב-NAS כך שמומלץ לחבר את שרת ה-Guacamole לאיזה NFS share על מנת לשמור הקלטות לעתיד לצרכי אבטחת מידע. כל הקלטה כזו ניתן מאוחר יותר להמיר לקובץ MP4 על מנת שלא לתפוס יותר מדי מקום באחסון.
    • ב-Firewall מגדירים Static NAT בין IP חיצוני ל-IP פנימי שמריץ את ה-Guacamole. את החוק הזה מכבים ומפעילים לפי צורך. (למתוחכמים – אפשר לכתוב סקריפט פשוט שמשתמש ב-CURL ומתחבר ל-API של ה-Firewall על מנת להפעיל/לכבות את החוק הספציפי).

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

נקודות למחשבה לגבי מעבר לענן (2019)

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

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

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

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

נניח וירון בוחר את השיטה להחליף "ברזלים" – נניח R710/R720 ב-R740 – העלות שלו תהיה Fixed ומשולמת מראש. נניח לשם הדוגמא ש-R740 עולה 10,000$ ויש לו 3 שרתים ישנים והוא מעוניין להחליף את כולם, אז העלות תהיה בעצם 30,000$. במחיר הזה ירון מקבל את האפשרות להביר מכונות VM לתשתית החדשה תוך שימוש ברשיונות קיימים (בדרך כלל, קיימות גם חריגות) והוא יכול בהמשך להוסיף עוד מכונות VM ללא עלות נוספת (שוב, למעט מקרים של רשיונות ל-OS וכו').

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

אז בואו נחשב מחיר: יש לנו 50 מכונות VM שפרוסים על 3 שרתים והם יתנו שרות לפחות ל-3 שנים הקרובות. מחיר פר VM יצא 600$. אפשר כמובן לקצץ ולרדת ל-2 שרתים עם מעבדים חזקים מרובי ליבות וכמות זכרון משמעותית (נניח 256 ג'יגה פר שרת פיזי). חושבים שזה יעזור? מהרגע שעוברים ממעבדים כמו Xeon SP Silver למשהו יותר רציני – המחיר יטפס בכמה אלפי דולרים, כך שלא בטוח שאם נרד בכמות השרתים (אך נשדרג במעמד ההזמנה את אלו שאנחנו רוצים לרכוש במפרט יותר "כבד") זה יעזור. אנחנו יכולים לרדת במחיר VM מ-600$ נניח ל-500$ ואפילו $400. המחיר ירד יותר אם אותן מכונות VM יעבדו יותר שנים, כמו לדוגמא 5 שנים – אז אנחנו יכולים לרדת ל-$133 פר VM.

נניח עתה שירון רוצה להסתכל על הפתרונות בענן. שיהיה מה להשוות.

אז בואו נאמר שב-AWS ניקח מכונה צנועה, 2 ליבות, 8 ג'יגה זכרון, תעבורת תקשורת נמוכה ו-80 ג'יגה דיסק (EBS). המחיר לחודש – 80$. את המחיר הזה ניתן "לחתוך" אם ירון מוכן לשלם לשנה מראש או 3 שנים מראש על אותו VM. אם זה לשנה, הוא יצטרך לשלם $1740 ואם זה ל-3 שנים, אז הוא יצטרך לשלם $1159 (כלומר אפקטיבית הוא כביכול ישלם 32.20$ לחודש) – אז בתכל'ס ניתן להגיע למחירים טובים פר VM (זה קיים אצל כל ספקי הענן הגדולים, אגב). יש,אגב, מסלולים שונים, תלוי בספק הענן.

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

  • רוצים קו יעודי (MPLS) של 100 מגה נניח מחברתכם אל אמזון? זה יעלה כמה אלפי דולרים, לאמזון ולספק התשתיות שלכם.
  • לא רוצים פתרון MPLS אלא VPN? אין בעיה. התשלום יהיה על ה-Instance שיריץ את פתרון ה-VPN ועל התעבורה היוצאת מאמזון אליכם (משלמים על הכיוון מאמזון החוצה, לא להיפך)
  • יציאה לאינטרנט – אתם משלמים על כל ביט שיוצא החוצה לאינטרנט מהתשתית שלכם בענן, ותלוי גם לאן התקשורת יוצאת – כל אזור והמחיר שלו (המחיר הולך פר ג'יגהבייט)
  • רוצים לגבות את התכנים? רעיון מעולה! כל ספקי הענן מציעים שרותי אחסון שונים (כמו S3 ועוד) ויש עלויות של כמה סנטים פר ג'יגהבייט (תלוי בענן, ובסוג שרידות שאתם מחפשים עבור הגיבוי).
  • כתובות IP אמיתיות – כל כתובת עולה כסף ואם ביקשתם הקצאת כתובות ולא השתמשתם – המחיר פר IP קופץ פי 3-4 (המחיר הוא בדרך כלל ל-IP אמיתי בשימוש בסביבות 1-2$ לחודש)
  • החלטתם להשתמש בשירותים שונים כדי לחסוך הקמה ותחזוקה של שרות דומה? יש מחירים Pay as you go ויש מקרים שאפשר לשלם מראש ולחסוך. ככל שיש יותר שימוש, המחיר עולה.

(עכשיו אתם מבינים מדוע אני מתייחס לעננים המקומיים שמציעות חברות תקשורת מקומיות שונות שמריצות תשתית של VMWare או Hyper-V כבדיחה?)

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

  • ב-On Prem אתה משלם על הציוד פעם אחת ואם אתה רוצה להוסיף נניח עוד מכונות VM, העלות תהיה אפסית (למעט במקרים שצריך שדרוג ציוד).
  • ב-On Prem כשיש תקלה, אפשר לטפל בה מקומית 24X7 ולא תלוים בספק הענן (אם משתמשים בשרותים של ספק הענן לדוגמא) עד שיתקנו את התקלה.
  • בענן אפשר תוך דקות ספורות להתחבר לשרותים שונים שחוסכים הקמת שרתים/הגדרות/תחזוקה ואפשר להשתמש ישירות בשירות. כך לדוגמא, במקום להחזיק Cluster של SQL, אפשר להשתמש בשרותי RDS.
  • בענן מחירי ה-VM יותר זולים – אם מוכנים לשלם מראש.
  • בענן אתה תמיד רץ על תשתית חזקה ואף אחד לא מכניס את ה-Instances שלך למכונות שכבר עמוסות. במקרים רבים ה-Instances רצים על מעבדים יחודיים חזקים שלא זמינים לשוק הרחב.
  • שרותי תמיכה בענן ישירות מספק הענן – אינם זולים.
  • נקודה חשובה: ב-On Prem אין לך הפתעות במחיר או בחשבונית חודשית.
  • כשזה מגיע לתשלום – בענן אין "שוטף/שוטף פלוס". התשלום הוא בתחילת החודש הבא.

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

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

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

המלצות וטיפים לגבי רכישת ציוד ל-AI/Deep learning

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

אז אני קודם כל רוצות להודות לחברת CRG שהשאילה לי ציודים (כרטיסי GPU ומכונות) כדי לבדוק פה ב-LAB את הדברים לפני שאני כותב את הפוסט הזה.

נתחיל במקרים פשוטים ונמשיך ביותר מורכבים.

תחנות עבודה
בלא מעט מקרים יש צורך בתחנות עבודה למפתחים ואחד הדברים שצריך להחליט הוא כמובן סוג ה-GPU וכמה כרטיסי GPU. במידה ומדובר בכרטיס אחד ולא ממש מחפשים ביצועים אלא יותר לנסיונות – מומלץ לרכוש כרטיס כמו RTX 2080 או RTX 2080TI, אך לא מומלץ לרכוש RTX 2070 ומטה. הסיבה לכך שכרטיסים כמו RTX 2070 ומטה אינם כוללים חיבור NVLINK (שהוא חיבור מהיר בין הכרטיסים – 100 ג'יגהביט לשניה) כך ש-2 כרטיסי RTX 2070 יעבדו יותר לאט בהשוואה לכרטיסים כמו RTX 2080 או RTX 2080TI עם חיבור NVLINK ביניהם (ניתן לחבר מקסימום 2 כרטיסים). אם מעוניינים בכרטיסים יותר מהירים אך עדיין לא להיכנס לתחומי ה-Quadro וה-Tesla, ניתן לרכוש את ה-Titan RTX.

כמות ה-GPU המקסימלית המומלצת בתחנת עבודה היא עד 3 ויש לכך מספר סיבות:

  1. אם רוצים לעבוד מקומית על התחנה (הכוונה לחבר אליה מסך מקלדת ועכבר), יש צורך ב-GPU כמו RTX כדי לחבר אליו מסך. בחלק מתחנות העבודה יש חיבור VGA אולם זהו חיבור שמיועד לניהול התחנה מבחינת סיסטם ולא לעבודה רציפה (העבודה כדסקטופ לינוקס גרפי תהיה איטית, ויש פה ושם מספר באגים בקוד התצוגה של שבבי הניהול).
  2. הכרטיסים הללו מפיקים המון חום וצריכת החשמל גבוהה – עם 4 כרטיסי GPU ו-2 מעבדים מגיעים בקלות ל-1400 וואט ומעלה.
  3. זה מרעיש.
  4. לפעמים צריכים את התושבת להכנסת ציוד אחר – כרטיסי רשת 10 ג'יגה, חיבור לסטורג' ועוד.

בקיצור – צריכים להכניס מעל 3 כרטיסים לצורך AI/DL? תחשבו על שרתים.

לרכוש כרטיסי TESLA?
כרטיסי ה-Tesla הם כרטיסים מאוד יקרים. החסרון שלהם בהשוואה לכרטיסי RTX היא המהירות שהם עובדים (בערך חצי ממהירות השעון בהשוואה לכרטיס RTX 2080TI), אבל היתרון שלהם הוא בכך שיש להם זכרון בדרגה גבוהה יותר (ECC), אחריות יותר ארוכה, ויותר זכרון מכרטיסי RTX (למעט RTX TITAN שמכיל 24 ג'יגה זכרון בהשוואה ל-11 ב-RTX 2080TI) וניתן לשרשר אותם כדי לקבל מהירות תעבורת נתונים מאוד גבוהה (למעט כרטיס Tesla T4 שאינו כולל NVLink).

שרתים לצרכי AI/DL
כל יצרן שמייצר שרתים (כולל כאלו שפחות ידועים כמו ASUS ו-PNY) מייצר שרתים מיוחדים למטרה זו. המפרטים מגוונים ומבחינת גדלים – מתחיל ב-1U ונגמר גם ב-20U. הפופולריים בד"כ הם 2U או 4U. בדרך כלל ב-2U תוכלו להכניס עד 4 כרטיסים וב-4U תוכלו להכניס (תלוי בדגם וביצרן) עד 16 כרטיסי GPU Dual Slot. בשרתי 1U-2U לא מומלץ להכניס כרטיסי GTX/RTX מכיוון שבעת עבודה רצינית, האיוורור שמגיע דרך המפוח אינו מספיק חזק ולפיכך ה-GPU מאט את פעילותו ומהירות השעון יורדת. כרטיסים כמו Quadro (שאגב, הוא פחות מתאים ל-AI/DL, הוא יותר לתלת מימד ווידאו) ו-RTX לפיכך יותר מתאימים לתחנות עבודה ואילו הכרטיסים לשרתים אינם כוללים מאוורר.

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

לינוקס וכרטיסים ל-AI/DL
באופן עקרוני, הורדת גירסת ה-CUDA מאתר nVidia (בגירסת הקובץ run) מכילה בתוכה כבר את הדרייבר היציב שתומך בכל הכרטיסים, כך שאין צורך להתקין בנוסף דרייבר של nvidia. יחד עם זאת, שימוש במעבד הגרפי הפנימי של אינטל או בממשק הניהול של המכונה בתצורה גרפית והתקנת ה-CUDA יכולים ליצור קונפליקטים שלא יאפשרו למכונה יותר להיכנס למצב גרפי. ניתן בהתקנת ה-CUDA לבטל התקנת OpenGL, אך לפעמים גם זה אינו עוזר (במיוחד כשיש שבב ניהול במכונה של ASpeed) ולכן חשוב להתקין את הפצת הלינוקס ללא סביבה גרפית אלא טרמינל בלבד. אם מעוניינים לעבוד עם שרת מרחוק ובכל זאת רוצים להשתמש בסביבה גרפית, עדיף להתקין תוכנה כמו NX Server של חברת NoMachine או להתקין VNC. אם אתם צריכים גם סביבה גרפית וגם להשתמש בדברים כמו TensorFlow עם OpenGL, מומלץ לרכוש את Nomachine Workstation שכוללת קידוד חומרה של H.264 כך שהדסקטופ הגרפי המרוחק יהיה מהיר מאוד עם תצוגה מעולה.

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

בניה עצמית
בלא מעט מקרים רוצים להשמיש ציוד קיים ופשוט רוצים לרכוש את הכרטיסים ולהכניס אותם פנימה לשרת או תחנת עבודה שקיימת בחברה. אחרי הכל – תושבות פנויות יש, אז פשוט נרכוש ונגמור עניין.
וכאן צצה בעיה: לא כל תושבת PCIe X16 היא באמת כזו. בחלק מהמקרים החיבור הפיזי הוא X16 אולם אם יש כרטיס נוסף במחשב, החיבור ירד מבחינה אלקטרונית ל-X8, ואם מכניסים GPU נוסף (שלישי) אותו חיבור ירד ל-X4. בניקוד למשחקים ועריכת וידאו, ב-AI/DL מהירות ה-PCIe חשובה (גם אם אתם משתמשים ב-NVLink – החומר צריך לעבור דרך ה-CPU) ולכן רק לוחות מסויימים או תחנות עבודה מסויימות שכוללות במפרט נתיבי X16 אלקטרוניים (ויותר מתושבת אחת, ובלי "תנאים") יכולים להתאים לכך.

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

עדכון ליבה בשרתי לינוקס – ללא Reboot

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

בלינוקס – ברוב המקרים אינך צריך לעשות Reboot לשרת גם לאחר שביצעת עדכונים. במקרה הכי גרוע אתה פשוט יכול להפעיל מחדש את השרותים שרצים על השרות – לאחר התקנת העדכונים. חברות כמו רד-האט ו-SuSE עושות את הכל כדי לשמור תאימות בינארית של 100% כך שקונפיגורציות ודברים אחרים פשוט אינם משתנים (ב-2 ההפצות, כשמתקינים גירסה חדשה של תוכנה על הגירסה הישנה, המערכת תייצר קבצי rpmsave באותה תיקיה שנשמרות בה ההגדרות של האפליקציה, כך שתוכל לראות מה השתנה).

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

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

לאחר זמן מה יצאה רד-האט עם kpatch וחברת SuSE יצאה עם Live patching. קנוניקל לא נשארה מאחור והם הכריזו על שרות שנקרא livepatch.

כל השרותים לעיל – הם בתשלום בלבד, כלומר העדכונים צריכים לעבור דרך מערכת עדכונים מורשית של ההפצה בלבד. לא מדובר באיזו חבילת RPM או DEB שאפשר להוריד ולהתקין חופשי על כל השרתים בחברה. ב-רד האט יש צורך לעשות זאת דרך שרות Satellite וב-SuSE דרך SuSE Manager. באובונטו נותנים בונוס למשתמשים – מי שנרשם, יכול לעדכן דרך שרות livepatch עד כ-3 מכונות דסקטופ בלבד (לא שרתים, זה כבר בתשלום).

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

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

לסיכום: אם יש לכם שרתי לינוקס בפרודקשן והם שרתים מבוססים על Red Hat או SuSE או אובונטו בתשלום – כדאי להשתמש בשרות ה-Live Patching ותחסכו לעצמכם דאגות על אבטחה וענייני Reboot.

פרילאנסרים: תמצאו את החתול

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

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

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

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

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

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

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

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

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

בהצלחה.

להתקדם בתחום

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

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

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

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

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

אם אתה רוצה להישאר בתחום ה-IT הקלאסי (לפני כניסת הענן) אז מה שמומלץ לך זה ללמוד את התחומים "השכנים": אתה איש סיסטם מיקרוסופט? תכיר יותר את תחום הסטורג' הרגיל, תכיר יותר נטוורק לעומק (אתה יכול להשתמש בכלי כמו GNS3 לבצע סימולציות), והכי חשוב – להכיר את מערכת ההפעלה ה"מתחרה" לינוקס במובן הטרמינל (לא במובן הגרפי. ברוב המקרים אתה לא תעבוד מול תצוגה גרפית במכונות לינוקס) – מה זה לינוקס, איך הוא בנוי, פקודות לינוקס בסיסיות, כתיבת סקריפטים בסיסיים ב-BASH, הגדרות ציודים שונים, ניתובים, ניהול חבילות תוכנה, ועוד. אם אתה רוצה, יש אתר בשם Linux Academy שמלמד את הדברים (יש מנוי חודשים שעולה 50$ לחודש, שבוע ראשון בחינם). אם אתה יותר טיפוס של ספרים – יש לא מעט ספרים שמלמדים על לינוקס ויש כמובן גם קורסים בבתי הספר המקצועיים השונים שמלמדים לינוקס. לגבי סטורג' ונטוורקינג – אני ממליץ ללמוד לבד.

במקומות גדולים החל לצוץ לו תפקיד חדש לאחרונה (לא באופן רשמי, לפחות ממה שאני יודע) והוא "Cloud Admin" – מה שאתה עושה מקומית, עכשיו בענן, רק שבענן לא יחכה לך איזה סטורג' של Netapp/EMC, אין לך סוויצ'ים, אין לך פיירוול (את זה אפשר להוסיף, כ-Appliance) והכל בעצם נעשה בתוכנה, בין אם דרך ממשק ווב, אבל יותר דרך ממשק CLI וכאן כבר צריך ללמוד איך להגדיר דברים, החל ממכונות VM, נטוורקינג, דיסקים קשיחים וירטואליים ועוד ועוד. בלינק שפירסמתי לעיל יש גם קורסים לכל ספקי הענן הגדולים, כך שאפשר ללמוד שם גם איך להשתמש בענן ואיך לנהל משאבים. העננים הפופולריים ביותר הם של אמזון (AWS) ו-Azure של מיקרוסופט. קצת פחות פופולרי (והרבה יותר טכני) הוא הענן של גוגל, לכן מומלץ ללמוד לפחות את הענן שבו החברה משתמשת ואולי את הענן השני הפופולרי.

ויש את "איש ה-Devops" (זה לא תפקיד, Devops אלו מתודות עבודה, אבל בגלל כל מיני מחלקות כ"א, קוראים לאחד שמתעסק בזה – "איש Devops").

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

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

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

בהצלחה.

קונטיינרים וגדילה, צרכים מול מציאות

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס Kubernetes), תמיכה ב-CI/CD וכו', אך אחד הדברים שקשה להעביר להנהלות השונות, הוא עניין ה-Scaling הרוחבי, שהוא אחד ההבדלים המהותיים בין עבודה עם מכונות VM ו-Scale קבוע, לבין קונטיינרים עם Scale דינמי.

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

סקירה: מיקרו שרת של HPE דור 10

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

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

נתחיל במפרט הטכני:

  • מעבדים – AMD Opteron (קיימים 3 דגמים: X3216, X3418, X3421). הדגם שמיובא לארץ הוא הדגם הנמוך עם מעבד X3216 עם 2 ליבות, 1 מגה זכרון מטמון, APU מובנה, ומבחינת כח – הוא הכי נמוך עם הספק של 12-15 וואט). שאר הדגמים הם עם 4 ליבות, 2 מגה זכרון מטמון, כח גרפי מעט יותר חזק, והספק של 12-35 וואט.
  • זכרון – עד 32 ג'יגהבייט (ECC).
  • אחסון: 4 דיסקים קשיחים בגודל 3.5 אינטש ללא תמיכה להחלפה חמה, ואפשרות להוסיף דיסק 2.5 אינטש בחיבור SATA (לצרכים של Boot או Cache עם SSD).
  • חיבור PCIe: ישנם 2 תושבות, הראשונה היא PCIe X8 והשניה היא PCIe X1 בחיבור של PCIe X4.
  • חיבורי רשת – 2 חיבורים של 1 ג'יגה עם LOM
  • חיבורי תצוגה – 2 חיבורי Display Port כולל תמיכה ברזולוציית 4K.
  • חיבורי USB – כ-2 חיבורי USB 2.0 ו-2 חיבורי USB 3.0.

נתחיל בקהל היעד: קהל היעד למכונה זו (בשימוש כ-NAS) הם אלו שמעוניינים ליצור לעצמם גיבויים – הן מבחינת תכנים שקיימים להם, גיבוי מכונות Windows או לינוקס. HPE רשמית ממליצה על מערכת הפעלה ClearOS שמתאימה ל-SMB/SOHO אבל כמובן כל מערכת הפעלה מודרנית תרוץ ללא בעיות על מכונה כזו. (שימו לב: המערכות שנמכרות בארץ עם X3216 יהיו איטיות בהרבה מ-2 האופציות האחרות ש-HPE מוכרת ולכן לא כדאי "להשתולל" עם התקנת שרותים רבים על המכונה).

למי שמעוניין להקים LAB קטן לעצמו ורוצה את המכונה הזו כשרת NFS או iSCSI או SMB/CIFS – כדאי שיקח בחשבון שהביצועים שהמערכת שנמכרת בארץ, מנפיקה ביצועים די איטיים, כך שאם אתה רוצה להרים מספר דו ספרתי של VM, אולי עדיף שתחפש פתרון אחר או … תצטייד בסבלנות (או שתכניס כרטיסי 10 ג'יגהביט ו-SSD ל-NAS וכרטיסי 10 ג'יגה לשרתים האחרים שלך).

מבחינת המעבד עצמו, HPE ו-AMD עשו בסופו של דבר עיסקה לא רעה בכלל: ל-AMD יש מלאי רציני של מעבדי Opteron ישנים שהם רוצים להיפטר מהם (לטובת ה-Ryzen V1000 ו-EPYC Embedded), ו-HP חיפשו מעבדים לשרתים בקצה הנמוך מאוד ובמחיר זול מאוד. AMD, לפי השמועות, מוכרים את המעבדים בכחמישית מהמחיר שאינטל מבקשת על אותו מפרט וה-Opteron (לפחות ה-X3421) נותן פייט די רציני למעבדי ה-Atom C3000 של אינטל. התוצאה: הלקוח מקבל מכונה עם ביצועים די מכובדים כ-NAS (שוב, לא הגירסה שנמכרת בארץ) במחיר מאוד נמוך של כמה מאות דולרים. אגב, אחד השימושים הכי מעניינים שיצא לי לשמוע עליו בשימוש מכונות כאלו, אגב, הם מקומות עם תקציב די קטן שמריצים קונטיינרים. לפחות מ-2 מקומות (בחו"ל) שמעתי שהם מרוצים מהתוצאות.

מבחינתי, הבעיה המרכזית במכונות הללו היא התכנון שלהם. ב-HPE יכלו לדוגמא לוותר על יציאת Display Port אחת ולהחליף את חיבורי הרשת הקבועים בחיבור של מודול, כך שהלקוח היה יכול להחליף בין 2 חיבורי 1 ג'יגה ל-2 חיבורי 10 ג'יגה, ובנוסף הם יכלו להוסיף ללוח האם כניסת M.2 PCIe X4. הוספת 2 הדברים הללו היו יכולים לשדרג מכונה כזו לביצועי NAS מכובדים מאוד, לשמש כ-Storage למספר קטן של מכונות פיזיות המריצות וירטואליזציה ועוד, אבל כנראה ש-HPE מעדיפים שאם אתה רוצה משהו עם ביצועים קצת יותר גבוהים – תכיר את המכונות שלנו שמבוססות Xeon SP או AMD EPYC – שהן כמובן הרבה הרבה יותר יקרות.

לסיכום: האם הייתי ממליץ לאחרים לרכוש את המכונה הזו? כן, אם הצרכים שלהם הם מה שציינתי לעיל. אם הם צריכים משהו יותר חזק, אז עדיף שיחפשו את הגירסה עם מעבד X3421 או שיחפש פתרון NAS אחר או שיבנה לעצמו NAS. אישית, אני מקווה בזמן הקרוב לבחון לוח אם חדש (שעדיין לא יצא – מחברת ASRock Rack) המבוסס על מעבד EPYC Embedded ושתומך בהרבה יותר דיסקים קשיחים, יש בו כניסת M.2, תושבת PCIe X16 ו-2 כניסות 10 ג'יגהביט מובנות – ואת זה להכניס למארז 2U.

על קונטיינרים ו-Windows Server 2019

מיקרוסופט שחררה לפני זמן מה את Windows Server 2019 ואחד החידושים הגדולים שלו קשור לקונטיינרים. בעבר היית יכול להריץ עם Windows Server 2016 קונטיינרים, אולם המשאבים שכל קונטיינר היה תופס היו נכבדים (אין פלא, זה היה בעצם VM "מינימלי"), והיו מספר בעיות תאימות בהשוואה לקונטיינרים ללינוקס. כעת מיקרוסופט מכריזה שקונטיינרים ב-Windows Server 2019 הם הרבה יותר קרובים למה שניתן כיום להריץ על לינוקס, ואכן, כיום קונטיינר אינו VM אלא תהליך (Process) נפרד וכל הקונטיינרים רצים תחת אותו Kernel באותה מכונה.

ב-Windows Server 2019 ניתן להריץ קונטיינרים בדיוק כמו בלינוקס, כשאנחנו מדברים על קונטיינרים בודדים שאנחנו משתמשים ב-Docker, ואם אנחנו מעוניינים להריץ מספר קונטיינרים שמקושרים ביניהם – נשתמש ב-Docker Swarm.

הבעיה: כל העולם ואחותו (כולל הכלב והחתול העצבני) נטש בהמוניו את Docker Swarm לטובת מערכת הרבה הרבה יותר פופולרית – Kubernetes. מערכת Kubernetes נותנת הרבה יותר ממה ש-Docker Swarm נותן, היא תומכת באין ספור תוספים ופרוטוקולים, והיא גם יודעת לדבר עם סוגים שונים של Storage לאחסן דברים. בקיצור – אם תשאל כל חברה שמריצה קונטיינרים על לינוקס, התשובה תהיה פשוטה: תשתמש ב-Kubernetes.

אז .. איך Windows Server 2019 עם Kubernetes? התשובה: זה עובד. להכניס לפרודקשן? שלא תעיזו!. מיקרוסופט עדיין עובדים על זה.

ניסיתי בימים האחרונים את Windows Server 2019 עם Kubernetes (גירסה 1.13) והלן הערותיי:

  • תצטרכו לעבוד Multi OS, הווה אומר – ה-Master Node צריך לרוץ על מכונת לינוקס. אם אתם רוצים להשתמש בטריקים כמו HAProxy כדי לחשוף שרות (או NGINX) – תצטרכו גם Node מבוסס לינוקס, בנוסף למכונות Windows שישומשו כ-Nodes כדי להריץ אפליקציות מבוססות Windows.
  • בלינוקס Kubernetes משתמש ב-iptables כדי לנהל את התעבורה הפנימית. ב-Windows זה VFP כך שעדיין יש שימוש ב-Hyper-V. זה לא הולך לרדת.
  • מבחינת משאבים – Windows זה לא לינוקס, וכל קונטיינר מצריך פי 3 משאבים (במינימום!) בהשוואה לקונטיינר שרץ על לינוקס – גם בשביל קונטיינר שיציג Hello World, כך שאם אתם רוצים להריץ הרבה קונטיינרים מבוססי Windows – תצטרכו להקצות לא מעט משאבים לכך מבחינת מחשוב.
  • אין תאימות. בניתם דברים על Windows 10 או על Windows 2016 מבחינת קונטיינרים? תצטרכו לבנות אותם מחדש על Windows Server 2019.
  • וכן .. הכל עדיין דרך CLI (דרך PowerShell).

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

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

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

לסיכום: כן, ניתן להריץ Kubernetes על Windows, אך עדיין תצטרכו לפחות מכונת לינוקס אחת שתהיה ה-Master (ואם זה פרודקשן, זוג מכונות לינוקס שיעבדו כ-HA). מיקרוסופט עדיין עובדת על זה. תהליך ההתקנה עדיין מורכב (אם כי בגירסה האחרונה יותר קל להוסיף מכונות Windows לאשכול Kubernetes, וחשוב לשנות את קובץ ה-YAML לביצוע Deploy כדי שקונטיינר Windows ירוץ על מכונת Windows. ברגע שיש לכם אשכול כזה רץ, אפשר להגדיר את כלי ה-CI/CD שלכם להשתמש גם ב-Nodes מבוססי Windows ואפשר כמובן להשתמש ב-Draft, Helm לעשות את החיים קצת יותר קלים. לחברות שחושבות לעבור ל-OpenShift – בקרוב תצא גירסה שתומכת גם במכונות Windows. כמובן שאפשר לחסוך את כל הכאב ראש – עם תעברו ל-Net Core.

למעוניינים – להלן וידאו הדגמה משבוע שעבר איך Kubernetes רץ על Windows. (הוידאו ארוך: שעה וחצי!)