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

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

כמה מילים על המרה מערכת לניהול גרסאות קוד

בשנה האחרונה ביצעתי מספר פרויקטים הקשורים להמרת מערכת לניהול גרסאות קוד, ממערכות שונות למערכות מבוססות GIT (כמו GitLab, או Bit Bucket ואחרים), ורציתי לשתף עם הקוראים כמה תובנות בנושא.

אם יש סוג מסויים של עסקים בהם אין עבודה כזו, אלו הם הסטארטאפים. אני לא מכיר ולא שמעתי אפילו על סטארטאפ אחד שלא משתמש בפתרון מבוסס GIT (בין בשימוש שרת GIT, שימוש בשרותי GIT של ספקי הענן וכו’). בדרך כלל עניין ההמרה מתרחש אצל חברות ותיקות, ושם אצל אותן חברות ותיקות יש כל מיני פתרונות לניהול קוד, בין אם מדובר ב-TFS (או VSS), ב-Subversion או Mercurial, וכן .. יש גם חברות שמשתמשות ב-CVS. כמעט בכל חברה, מעבר למערכת ניהול קוד אחרת זה תהליך לא קל (בירוקרטית וניהולית, טכנית ניתן להמיר את הדברים ביום או יומיים, תלוי בכל מיני פרמטרים).

ככל שעובר הזמן, עניין המעבר ל-GIT נהיה פחות “אופציה” ויותר “צורך”. חברות שחושבות לעבור להשתמש במערכות מבוססות קונטיינרים (בין אם זה Kubernetes, OpenShift, CaaS, Rancher, Mesos ועוד) יצטרכו להבין עוד בהתחלה שמבחינה טכנית ניתן איכשהו לעבור עם מערכת ניהול קוד הנוכחית שיש להן, אבל אם מכניסים מערכת קונטיינרים ל-Enterprise, הצורך לעבור ל-GIT יהיה יותר דחוף.

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

  • המרת קוד ממערכת קיימת למערכת GIT חדשה (מקומית, מכונה בענן, שרות GIT של ספק הענן) כולל היסטוריה ורוויזיות.
  • התאמת הכלים המקומיים שלהם לעבוד מול מערכת ה-GIT.
  • ביצוע “פרישה” (Retire) של מערכת הקוד הנוכחית.
  • תמיכה שוטפת.

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

  • אם אתם חברה גדולה ומסודרת, ואני אוריד את מערכת הקוד הנוכחית ואמחק אותה, והמחלקה המשפטית שלכם תשמע את זה, הם ירדפו אחריי עם נבוטים. קוד ישן ומערכות ישנות צריכות להיות זמינות במקרה שהחברה נתבעת על העתקת קוד או הפרת פטנטים. ישנה חשיבות קריטית לזמנים (תאריכים, כולל שעה מדוייקת) של הכנסת קוד והדברים האלו יוצגו בבית משפט/דיונים מול התובעת כדי להראות סתירות בתביעה. לכן, מה שעושים לגבי מערכות ניהול קוד קיימות (לאחר מעבר לעבודה עם GIT) – הוא שמירת גיבוי, כיבוי המכונה אך לא למחוק אותן.
  • העברת היסטוריה מלאה של קוד קיים ממערכות ניהול קוד אחרות ל-GIT: זה אפשרי בחלק מהמקרים (לדוגמא: mercurial או TFS) אך בעייתי במקרים כמו CVS או Subversion, ולכן בדרך כלל ההמלצה היא להעביר קוד נוכחי ולשמור קוד/Branches ישנים במערכת הקודמת. מיקרוסופט בעבר הבטיחו ללקוחות כי הם יעבירו בקלות קוד מ-SVN ל-GIT כולל היסטוריה מלאה, ורק אחרי שהם התחילו את הפרויקט, הם ראו כמה זה לא ממש ריאלי (במיוחד אם יש קוד ענק של מספר שנים) ומאז הם ירדו מכך.
  • האם להשתמש בשרותי Code Repository של ספק הענן שאיתו אתם עובדים או להרים VM עם אפליקציית שרת GIT (כמו GitLab, BitBucket, GitHub Enterprise)? זה תלוי בכם. אם חתמתם עם ספק הענן על חבילת תמיכה רצינית, אז אולי כדאי להשתמש בשרות (שימו לב, שתצטרכו לשלם תשלום חודשי על כך. באמזון AWS ה-5 משתמשים ראשונים הם בחינם). לעומת זאת, אפשר להקים Instance ולהקים מערכת GIT כמו אלו שציינתי במחירים נוחים:
    • מערכת GitLab היא חינמית כל עוד אינכם צריכים תמיכה מסחרית מהחברה.
    • מערכת BitBucket היא חינמית ל-5 משתמשים ראשונים, 2$ לאחר מכן (מינימום 10 משתמשים) ואתם מקבלים גם אינטגרציה עם Jira.
      שימו לב: ב-2 המקרים אתם מקבלים גם תמיכת Pipelines כדי לבצע אוטומציה לקימפולים, קונטיינרים וכו’.
  • עבודה עם מערכת ניהול קוד נוכחית יחד עם GIT: אם יש לכם מערכת ניהול קוד ישן מבוססת Subversion, ניתן להקים מערכת (היא בתשלום אם יש יותר מ-10 משתמשים) המאפשרת לעבוד מול ה-Subversion והמערכת המסחרית תמיר מיידית את הקוד למערכת ה-GIT שלכם ולהיפך, כך שניתן להמיר את המפתחים לעבודה ב-GIT ואת האוטומציה (Jenkins, Team City וכו’) בהדרגה ולא במכה אחת.
  • תמיכה והדרכה – חשוב לסגור את העניין במסגרת חוזה הפרויקט. קל מאוד לעשות שטויות מצד אחד ובמקרים רבים גם לא מנצלים את היתרון של מערכות מבוססות GIT מצד שני – וחבל.

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

Exit mobile version