הפתרון למעבר מ-VM לקונטיינר: Kubevirt

(הערה: לפני כשנתיים כתבתי את הפוסט הזה על Kubevirt. מאז דברים רבים השתנו ופוסט זה הוא פוסט עדכון לכלי).

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

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

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

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

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

על בניית אתרים ואחסונם – דברים שחשוב לדעת

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

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

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

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

לכן, אם מקימים לך אתר, כדאי לחשוב/לבצע את הדברים הבאים:

  • אם אין לך שרת וירטואלי, תשכור אחד, לא צריך בישראל ולא צריך לשלם הרבה. אמזון Lightsail מציעים מכונות החל במחיר של 3.5$ (אני ממליץ לקחת את החבילה של ה-20$ אם זה לא אתר נשכח שנכנסים אליו 2 גולשים בשבוע), ואם אתם לא מעוניינים בהצעות של אמזון, יש גם את Digital Ocean (המחירים די זהים)
  • קחו איש לינוקס מקצועי שיבצע את הדברים הבאים:
    • יקים את המכונה, יעדכן ויגדיר אותה בהתאם לצרכים
    • שיקבל את האתר ב-ZIP מבוני האתר (חברות רבות שבונים אתרים מבקשים גישת FTP. לא לפתוח את זה, שילמדו לעבוד עם GIT!), כולל DB DUMP אם צריך.
    • שיגדיר את כל הדברים הנחוצים כולל הרשאות קבצים, גישה לשרת, מפתחות, SSL וכו'
    • אם האתר הוא מסחרי, אנליטיקות וכו' – בקשו מאיש הלינוקס להריץ בדיקת עומסים. אם השרת לא מצליח לעמוד בעומס נורמלי שאתם צריכים, פנו לחברה שבנתה אותו, בדרך כלל מדובר בקוד SQL גרוע, או במקרים רבים – חוסר אופטימיזציה של קוד, אי שימוש ב-Cache וכו'.
    • במידה ומדובר באתר גדול עם אלפי גולשים, דאגו ליידע מראש הן את איש הלינוקס והן את בוני האתרים. יתכן שיתווספו דרישות לבניית האתר מאיש הלינוקס.
    • בכל ויכוח מקצועי לגבי מכונת הלינוקס – דעתו של איש הלינוקס קובעת, לא הדעה של חברת בוני האתרים (אין לי מספיק שערות בראש מכמות הויכוחים שעברתי בנושא הזה, שחברת בוני האתרים מילאה את ראשו של הלקוח בשטויות!)
  • במסגרת ההסכמים שלכם עם איש הלינוקס וחברת בניית האתרים, דאגו ש:
    • בתמחור לאיש הלינוקס תהיה חובת עדכון השרת אחת לחודש במשך שנה
    • חברת בוני האתרים יחויבו לעדכן את הקוד שלהם לגבי באגים וגרסאות תיקון של השפה בה הם מפתחים (NodeJS, PHP, Python וכו') – למשך שנה
  • כשאתם רוכשים את החבילה, בקשו מאיש הלינוקס גיבוי אוטומטי של השרת בהתאם לצורך (אחת ליום, אחת לשבוע וכו') כך שיאפשר שיחזור נתונים מיידי במקרה של תקלה/פריצה.
  • אם יש לכם את הכסף – העבירו את הקוד של חברת בניית האתר למישהו שיודע לבצע Code Auditing לקוד.
  • והכי חשוב: לא לתת גישת sudo/root לחברת בוני האתרים בשרת, בשום מקרה!

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

כשצריך תשתית של עננים ציבוריים – מקומית

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

לפני כחודשיים כתבתי פוסט על Azure Stack (ועל "אחיו" – Azure Stack HCI), הפתרון של מיקרוסופט לחברות שדורשות ענן ציבורי בתשתית שנמצאת מקומית או ב-DC של אותן חברות. מאז אותו פוסט גם אמזון עדכנה את הפרטים לגבי המוצר המתחרה שלה: Outpost. לפי ה-FAQ העדכני והפוסט הזה שפורסם לפני מספר ימים מתאר אלו שרותים יהיו זמינים ב-Outpost. גם כאן, כמו עם Azure Stack, אתה לא יכול להשתמש בשרתים או סטורג' משלך, והשרות בעצם כולל השכרה/רכישה של ברזלים יחודיים של ספק הענן, וכמו בכל ההצעות – אתה חייב חיבור אינטרנט לאותה תשתית מכיוון שמי שמנהל את אותה תשתית ענן ציבורי שנמצאת מקומית ב-DC שלך – זה ספק הענן הציבורי בלבד.

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

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

לגבי שאר ספקי הענן הציבורי:

  • ל-IBM יש Cloud Private שנותן לך בעצם Kubernetes עם שרותים נוספים של IBM שירוצו מקומית.
  • ל-Alibaba, Huawei, Baidu יש גם פתרונות מקומיים אבל אני בספק אם הלקוח הישראלי החשדן יסכים לשכור מהם שרותים שישבו מקומית.
  • Oracle מציעים את Oracle Cloud at customer – שכוללים את "רוב" השרותים שהם מציעים בענן (אחרי שנברתי בערימת מסמכים רוויי Buzzwords – קשה להבין מה הם בדיוק נותנים, מה עוד שהתיעוד שלהם לגבי ספקי ענן מתחרים לוקה בחסר ולכן לא מומלץ לסמוך על התיעוד שלהם).
  • VMware – נכון, VMWare היא אינה ספק ענן ציבורי, אבל עם מוצר כמו Tanzu אתה יכול להרים תשתית קונטיינרים/Kubernetes מקומית (PKS) ובעננים ציבוריים גדולים.

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

קצת על גניבות קוד, קניין רוחני ועוד

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

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

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

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

חברות רבות נותנות לעובדיהם מחשבים ניידים כדי שיוכלו לעבוד מרחוק (בד"כ דרך VPN) על קוד או על תשתית של החברה (אני אתרכז יותר במפתחים). עובדים שעובדים מהבית בד"כ או שעובדים בצורה גמישה (משרד/בית) משתמשים במחשב הנייד כדי לקבל גישה לקוד (נניח דרך GIT), להוריד שינויים, לבצע שינויים קוד ולבצע Commit ו-Push. עד פה לאף אחד אין בעיה עם זה.

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

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

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

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

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

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

לגטימי? כן.

וכאן יש נקודות שכל סטארטאפ צריך לעשות:

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

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

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

קצת על שדרוג מכונות תעשיתיות

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

אבל כשזה מגיע למכונות יצור, לא מומלץ ממש לבצע את הדברים לעיל.

בין אם מדובר במחשב שנמצא במפעל שמפעיל רובוט/ים, בין אם מדובר בכספומט ובין אם מדובר בכל מערכת סגורה ללקוח שרכש את המערכת – אותו מחשב לא נבנה עבור שדרוג. אני לא מכיר שום יצרן מכונות שיענה לך במייל "סבבה, שדרג ל-Windows 10, אין בעיה" וזאת מהסיבה הפשוטה שברוב מוחלט של המקרים, מותקנות במערכת ההפעלה שבמחשב מספר אפליקציות ומספר דרייברים (תלוי בציוד שאליו מחובר המחשב) שניבנו עבור אותה מערכת הפעלה ישנה ומה שהותקן כלל לא נוסה על מערכת הפעלה חדשה. יותר מכך, במקרים רבים הדרייברים של הציודים המחוברים במחשב לא יעבדו ב-Windows 10 (תצורת הדרייברים שונה מהותית בין Windows XP/7 לבין WIndows 8/10).

ליצרנים הסיטואציה הזו היא דווקא דבר מבורך, עוד דרך להרוויח מהלקוח. רוצה שהמחשב של מכונת היצור ירוץ עם Windows 10? בשמחה! שלם כך וכך עשרות אלפי שקלים ותקבל מחשב חדש עם ציוד/כרטיסים חדשים שמריץ Windows 10 ואת התוכנה הקניינית.

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

  • הרצה של המערכת הישנה כ-VM בתוך המחשב התעשייתי שיריץ Windows 10: רעיון נחמד אבל בעייתי במיוחד אם המחשב מחובר עם כרטיסים שונים לרובוטים. מה לעשות, Windows לא מאפשר מיפוי של כרטיסים אל מערכת הפעלה וירטואלית (תאשימו את מיקרוסופט, בלינוקס זה דווקא עובד) וגם אם תנסו להתקין לינוקס עם VM של מערכת ההפעלה החדשה, זה לא אומר שזה יעבוד כי מעבדים ישנים אינם כוללים תמיכה של VT-D, מה שאומר שברגע שתפעילו את ה-VM, המכונה הפיזית תאפס את עצמה (אין תקשורת DMA טובה).
  • התקנה של Windows 10 והרצה במצב Compatibility: גם זה רעיון נחמד, אבל לא בטוח שהציוד במחשב נתמך בכלל ב-Windows 10 (נסו את זה עם כרטיסי MOXA ישנים לדוגמא או עם כרטיסי FPGA מלפני 2005, ותקללו כל רגע שהחלטתם להכניס את הראש לצרה הזו), מה גם שבאותו רגע שתעשו זאת – יש מצב שאתם מבטלים את חוזה האחריות והתמיכה מצד היצרן.
  • העברת כרטיסים מהמחשב שהוא חלק ממכונת היצור לשרת והרצת VM תחת ESXI: גם זה רעיון נחמד, אבל ברגע שתפעילו את ה-VM, יש מצב שהשרת או יתקע או יתאפס לגמרי (הכרטיסים לא יודעים לתמוך ב-IOMMU ומכיוון ש-VM מנסה לאפס את הכרטיס ב-Boot, הכרטיס או יסרב ואז יכול להתבצע Reset או פשוט להתקע).

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

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

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

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

כמה מילים בעניין חוק המחשבים

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

קצת רקע לגביי: אינני מבצע בדיקות באתרים חיצוניים כביזנס וברוב המקרים הדיווחים שלי ל-SoC של בנקים מגיעים לאחר שאני או חבריי מקבלים הודעת Phishing, אני מבקש להעביר את ההודעה אליי, אני מנתח את האתר, כתובות IP, ספק ועוד דברים – ומעביר במייל ממני אל ה-SoC את כל הפרטים ללא בקשת תמורה כלשהי. השרות המסחרי שהעסק שלי מציע לחברות בכל הקשור לאבטחת מידע קשור להקשחת שרתים, כחלק משרותים אחרים שהעסק שלי מציע.

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

כשזה מגיע לאבטחת מידע, רוב החברות שבטוחות שהן מוגנות ב-95%+ הן טועות, מכיוון שברוב החברות רוכשים כל מיני פתרון כמו חומות אש, WAF, IPS/IDS וכו' ולפיכך הן סוברות שהן מוגנות. ההגנה שהציודים הללו נותנים היא חלקית בלבד. פורץ מתוחכם לא יחפש איך לתחמן את חומת האש או ה-WAF שלך, אלא יכנס לקוד שהדפדפן מוריד למחשב המקומי ולפרמטרים בשורת ה-URL. בחלקים הללו הוא ינסה למצוא את הכשלים והחורים. אחד הטיעונים המגוחכים ששמעתי ש"אין למשתמש שמריץ את ה-web service אפשרות shell". מדוע מגוכך? כי אפשר ליצור shell בכל שפה דרך הדפדפן. להלן דוגמא של shell ב-PHP שכל מה שהפורץ צריך לעשות זה למצוא מקום שההרשאות יותר מדי פתוחות כדי להעלות את הקובץ ומשם לחגוג (אם בשרת יש תמיכת PHP).

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

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

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

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

בשביל לדווח על פריצה, יש צורך ב-3 דברים:

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

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

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

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

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

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

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

אשמח לשמוע את דעתכם.

עמדה: מחשבי מק ושימושיות בחברות

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

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

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

כשזה מגיע למחשבי דסקטופ, יש לאפל מחשב 2 מחשבים (ה-iMac ו-iMac Pro) שניתנים לשדרוג הן מבחינת זכרון, מעבד, ואחסון. במחשבים אלו האחסון שליף כך שבמקרה ומחשב צריך החלפה של לוח אם לדוגמא, אין שום בעיה להוציא את זוג ה-SSD הקנייני שבמחשב ולהחליף לוח אם, ומחשבים אלו לעניות דעתי מומלצים יותר לרכישה מאשר אחיהם הלאפטופים הואיל וניתן בכל זמן לשדרג אותם. לאפל יש גם את ה-Mac Mini אך למעט הזכרון לא ניתן לשדרג מאומה, כך שכמו אחיו הלאפטופים, אם ישנה בעיה באחסון, יש צורך בהחלפה של כל לוח האם כולל הבעיה של המידע שקיים במחשב. אפל בחורף תוציא את ה-Mac Pro שיהיה אחד המחשבים היחידים של אפל שבו ניתן יהיה לשדרג סוף סוף הכל, כולל הכנסת כרטיסי PCIe של חברות שונות.

אחת התהיות שעולות עקב "לחץ מלמטה" היא התהיה האם כדאי להחליף את שלל המחשבים הניידים בחברה למחשבי Macbook Air או Macbook Pro. מבחינת ניהול מרכזי, קיימים מספר כלים לנהל מחשבים אלו יחד עם מחשבי PC אחרים בצורה מרוכזת, ומבחינת מערכת הפעלה Mac OS היא מערכת הפעלה מעולה ויציבה (לא רק עבור גרפיקאים ואנשי מדיה אלא גם למפתחים), אולם חשוב לזכור כי הבעיה המרכזית היא שכל מחשב נייד ל-Enterprise שתעמיד למבחן מול כל מחשב נייד של אפל – המחשב הנייד שאינו מחברת אפל יוכל להיות משודרג הן מבחינת זכרון והן מבחינת אחסון, וזהו יתרון ענק כאשר מסתכלים לטווח של שנה שנתיים לאחר רכישה שבהן עולות דרישות של יותר זכרון ויותר שטח אחסון. אחרי הכל, אף אחד לא רוצה לגרור את עצמו עם מחשב נייד ועם SSD חיצוני לכל מקום כי נגמר המקום בדיסק SSD הפנימי..

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

ההשמצות והלכלוך נגד Huawei

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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