המעבר מ-VM לקונטיינרים

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

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

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

אם אני מעוניין להציג דברים אחרים, אולי אתר מלא, אני אכנס לתיקיה שמוגדרת בשרת Web כ-DocumentRoot ואעביר לשם את הקבצים ואולי גם אתקין שם MySQL קטן כי האתר שלי מצריך Database. אני אוודא כי כניסות 80 ו-443 פתוחים לעולם. עכשיו הכל עובד, ואני אכנס אחת לתקופה כלשהי כדי לעדכן את התוכנה, ואת מערכת ההפעלה. אם תהיה לי הפסקת חשמל, ברגע שהחשמל יחזור אני אבצע Boot לפתרון הוירטואליזציה ואפעיל מחדש את ה-VM כדי שאנשים יוכלו לגלוש לאתר שלי.

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

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

כך בדיוק עולם הקונטיינרים בנוי.

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

כך שאם נחזור לדוגמא לעיל עם האתר, אנחנו בעצם נקים 2 קונטיינרים עם מיפוי לשרת הפיזי או ל-NFS/OCFS עם המידע הרלוונטי. זיכרו: בקונטיינרים – כל דבר שהולך להשתנות, מומלץ שיכתב/יקרא ממערכת מחוץ לקונטיינר, ודברים שהם קבועים – אנחנו נכלול אותם בעת בניית הקונטיינר בכתיבת קובץ DockerFile (שמהווה בעצם "סקריפט" לבניית הקונטיינר שלנו). יותר מכך – כשעובדים עם מספר קונטיינרים לא קטן, מאוד מומלץ להתחיל לעבוד עם מערכות כמו OpenShift, Kubernetes, Rancher ואחרים – ששם כבר ניתן "להזריק" לקונטיינר דברים רגישים כמו סיסמאות, מפתחות SSL – בעת הרצת הקונטיינר.

לכן, העברה של מערכת מ-VM לקונטיינרים בצורה של "1:1" לא רק שלא שווה, היא גם תעשה צרות (במיוחד שמריצים docker run והמערכת מקימה כל פעם מחדש קונטיינר חדש ולאיש צוות שלא מבין בקונטיינרים יש כאב ראש מדוע הקבצים לא נשמרים ומדוע כשהוא מתחבר לקונטיינר והוא מתנתק, הקונטיינר כבה). צריך לבדוק כל VM מה בעצם הוא עושה, מה האפליקציות שצריך ואז לבנות את הקונטיינרים השונים כדי שהדברים ירוצו, יחד עם מציאת פתרון NFS/OCFS2 ואחרים כדי למפות תיקיות לקונטיינר, דאגה ל-Scheduling ועוד.

קונטיינרים הם כלי מצוין במיוחד ל-2 פעולות:

  • בדיקות – מאוד קל להקים קונטיינרים במהלך תהליך CI/CD שיכלול את האפליקציות והספריות. כך אנחנו בעצם נחסוך יצירת קבצי הרצה שאותם נתקין על VM כדי לנסות. ברגע שהמערכת מסיימת לבצע בדיקות Unit testing לדוגמא או תהליכים אחרים – אפשר לקבוע שבסוף היא תקים קונטיינר המבוסס עם קובץ DockerFile (או שתשתמשו ב-Docker Compose שמבוסס פייתון אבל לא מחייב ידע בפייתון), וכך המערכת תקים קונטיינר עם הכל מוכן לשימוש ע"י צוות הפיתוח או צוותים אחרים.
  • שיווק – כמעט כל חברה שבונה היום מוצרים מבוססי Web ללקוח, בין אם זה שרת מייל, ניטור, אבטחה או 1001 דברים – החברות משתמשות ב-IMAGE כדי לשדרג, רק ש-IMG זה לא תמיד פתרון טוב או קליל, במיוחד אם צריכים לשלוח ללקוח שאין לו ל-Appliance חיבור אינטרנט וצריך לעדכן חבילה מסויימת ספציפית (נניח … openssl) ואז צריך לבנות לוגיקה שלמה שהמערכת תבין כל קובץ מהו ולאן הוא הולך ושלא ישבור כלום באמצע.
    עם קונטיינרים לעומת זאת – החיים הרבה יותר קלים. ה-Appliance יכול להכיל מערכת לינוקס מאוד מינימלית (כמו Atomic של רד-האט/סנטוס), והאפליקציה עצמה יכולה לשבת בקונטיינר כאשר כל קבצי ההגדרות וקבצים חשובים יושבים מחוץ לקונטיינר וממופים לקונטיינר. כך, במקרה של שדרוג, הלקוח יוריד קובץ חתום, המערכת תקבל את הקובץ החתום, תבדוק חתימה, ותפרוס אותו ל-file-system המקומי ואז בהרצה של מספר פקודות ניתן לכבות ולהפעיל את הקונטיינר החדש תוך מיפוי התיקיות החשובות – ועכשיו יש ללקוח Appliance מעודכן עם הגירסה החדשה של התוכנה (ובקשר לעדכון ה-VM עצמו או המכונה הפיזית שמריצה את הקונטיינר – אפשר להשתמש ב-ostree)

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

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

על OpenStack וחברות שרוצות לאמץ את הטכנולוגיה

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

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

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

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

גירסה יציבה עם פתרון ל-3 שנים (עם הרחבת תמיכה בתשלום ל-5 שנים) רק אצל יצרני הפצות לינוקס (או חברת Mirantis וחברות אחרות שמוכרות את OpenStack מיצרני הפצות כמו HPE וכו') והן אינן קיימות כגירסה חופשית, כלומר אם חברה גדולה רוצה OpenStack של יצרן הפצה עם תמיכה והכל – יהיה צורך לרכוש רשיונות ל-OpenStack (ולחלקים נוספים שלא אכנס לפירוט עליהם בפוסט זה). חשוב מאוד: לכו עם יצרן הפצה רציני (כמו רד-האט או SuSE). אני פחות ממליץ על OpenStack מהפצה כמו אובונטו הואיל וקנוניקל "דוחפת" בגירסתה דברים שיחודיים לה שאף אחד אינו יודע אם הם יתוחזקו בעתיד וגם שיטת האכסון בגירסת ה-OpenStack שלהם דורשת המון משאבים (שימוש ב-Ceph כאחסון ראשי).

בגירסת OpenStack של יצרן הפצה (שוב, במקרים של RedHat ו-SuSE) תקבלו גירסת OpenStack שהיא גירסה אחת פחות מהגירסה הרשמית (לדוגמא: OpenStack כרגע הוא בגירסת Ocata והגירסה שתקבלו גם מ-RedHat וגם מ-SuSE מבוססת על Newton) עם תיקונים שהוכנסו ל-Ocata. הסיבה לכך היא ש-OpenStack הוא פרויקט שמתפתח מאוד מהר וטכנולוגיות חדשות (אך לא תמיד יציבות) מוכנסות תדיר, וגירסת יצרן ההפצה היא הגירסה עם הבדיקות והתיקונים שלא קיימים בגירסאות החופשיות (ולא חשוב אם זו גירסה חופשית של רד-האט או אובונטו או אחרות).

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

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

האם OpenStack תומך בפתרונות שכוללים גם VM וגם קונטיינרים? בהחלט (החל מגירסת Newton), אבל כדאי לקחת בחשבון את הנקודות הבאות:

  • כדי לתזמן קונטיינרים, אינטגרציית רשת יותר טובה עם קונטיינרים, שימוש ב-Kubernetes או Docker Swarm – יש צורך בגירסת ocata שעדיין אינה קיימת כגירסה מסחרית
  • אם אתם משתמשים ב-vSphere ולא אכפת לכם להתנסות את Admiral (ומספר כלים נוספים) מבית VMWare. רשמית – רק ב-vSphere-7 תהיה תמיכה "out of the box" לקונטיינרים, אבל ה-Admiral (שנכתב ע"י המפתחים ב-VMWare יחד עם תרומות קוד מבחוץ) נותן פתרון לא רע.
  • אם אתם רוצים פתרון וירטואליזציה די "רזה" שמיועד בראש ובראשונה לתת פתרונות וירטואליזציה – כדאי לנסות את RHEV של RedHat (בגירסה הקרובה שלו הוא גם יריץ קונטיינרים באופן טבעי) ובגירסה החופשית – oVirt.
  • אם אתם מתעקשים להשתמש בגירסה החופשית של OpenStack – שדרוג מגירסה ישנה לחדשה לא בטוח שיהיה חלק (ראיתי מספיק מקרים שהשדרוג נשבר באמצע והיה צורך בידע בלינוקס וב-Python כדי להתגבר על התקלה).
  • OpenStack מצריך ידע עמוק בלינוקס. אם יש לכם צוות לינוקס עם ידע רציני במערכת הפעלה וב-Python – זה מעולה. אם לא – תתכוננו להחתים פרילאנסר (או עסק) לבנק שעות/ריטיינר.

לסיכום: OpenStack היא מערכת מעולה שיכולה לתת שרותי IAAS, PAAS, SAAS. רוצים להטמיע אצלכם בחברה כפרודקשן לאורך זמן? קנו את הגירסה המסחרית מיצרן הפצת לינוקס. קחו בחשבון שב-8 מתוך 10 מקרים, OpenStack זה פתרון של "להרוג זבוב עם תותח" ואם אין לכם בעיה עם פתרון הוירטואליזציה שלכם כיום ואתם לא מחפשים "לברוח" ממנו בגלל מחיר (תאמינו לי, גירסה מסחרית של OpenStack זה לא דבר זול) – אפשר לתפור גם פתרונות לקונטיינרים במערכת הקיימת שלכם.

גילוי נאות
"חץ ביז" מעניק שרותי הקמה, תמיכה ואינטגרציה ל-OpenStack בכל הגרסאות

כשהאתר דורש יותר ויותר משאבים בפתאומיות

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

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

  • הגדלת משאבי המכונה הוירטואלית (יותר זכרון, יותר ליבות)
  • אופטימיזציה של מערכת האתר – טיוב שאלות SQL, בניה יותר טובה של Cache, אולי מעבר ל-NGINX, שינוי PHP לעבודה כ-FPM ועוד ועוד..
  • שכפול והקמת מכונה זהה ומעל המכונות Load Balancer תוך מתן פתרון גם ל-SQL (שיטות Master/Slave, Multi Master ועוד)
  • אם אתם משתמשים בשרותי ענן כמו אמזון ושרותים כמו RDS, אולי תעברו ל-Instances יותר גדולים, אחסון יותר מהיר וכו'.

אם האתר שלכם נמצא בשרותי ענן ציבורי, בד"כ תהיה אופציה נוספת שנקראת Auto Scaling שתאפשר לכם להוסיף מכונות בהתאם לעומס (אתם יכולים לבדוק עומס על ה-CPU, עומס על הרשת, כמות זכרון פנויה וכו') ובד"כ זה פתרון טוב שעובד יפה והרבה חברות משתמשות בו. גם עניין הוספת VM לזה שקיים, ביצוע רפליקציה של SQL והוספת Load Balancer היא אפשרות טובה כשצריכים אותה.

אך לשיטות האלו יש מספר בעיות:

  • אם האתר עצמו מאוחסן ב-NFS או OCFS2 לדוגמא, תקלה בקוד או חדירה ע"י פורץ ושינוי הקוד (כמו במקרים של Defacement) – תשפיע על כל השרתים שלך. כנ"ל בעת שדרוג -אם השדרוג לא מצליח, שום אתר לא באוויר וכולם מקבלים את אותה שגיאה. בנוסף, אתם מייצרים צוואר בקבוק חדש מכיוון שכל פעם שהאתר צריך ולו את הקובץ הכי קטן – הוא צריך לבצע קריאה ל-Storage, ו-NFS לדוגמא פשוט לא מתאים לזה, אתם יוצרים צוואר בקבוק חדש.
  • מחיר – להוסיף עוד VM + Load Balancer זה לא כזה יקר (לעסק שמתפרנס [גם] מהאינטרנט לדוגמא), אבל כשאתה צריך להוסיף עוד 20 מכונות VM העסק מתחיל להיות קצת יקר וזה לא חשוב אם מדובר בספק אירוח ישראלי או בענן ציבורי.
  • תחזית: כמה הולכים להיכנס לאתר? אתה לא יודע. אתה יכול להעריך בהערכה גסה, אבל אתה לא תדע אם יכנסו פחות או יותר ואם אנשים לא עפו מהאתר או לא הצליחו להיכנס בגלל שהשרתים היו עמוסים, בגלל תקלה, ובקיצור – עניין הניחוש הזה קשה כמו לנחש כמה אנשים יגיעו לחתונה..

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

מכונות VM הם פתרון טוב, אבל יש כיום פתרון יותר טוב והוא כמובן קונטיינרים: אפשר להקים קונטיינרים שיריצו את הקוד PHP, קונטיינרים שיתנו את שרות ה-WEB עצמו, קונטיינרים ל-SQL, קונטיינרים ל-Cache וכו'. הקונטיינרים עצמם אינם דורשים משאבים גדולים – מכיוון שהקונטיינר לא צריך את כל מערכת ההפעלה מותקנת בו אלא אך ורק חלק שצריך להריץ אפליקציה ספציפית, אפשר להפעיל קונטיינרים עם כמות זכרון קטנה (נניח 512 מגהבייט זכרון) בהתאם לצרכים. בנוסף, קונטיינרים הם דבר שניתן לשכפל מאוד מהר (בניגוד ל-VM – קונטיינר משוכפל בשניות). כך בעצם ניתן "להמיר" את האתר שלך למספר קונטיינרים שישוכפלו בין מכונות VM (או Instances), תקבל Load Balancer בחינם, והמערכת תדע לגדול ולקטון בהתאם לצרכיך.

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

  • להקים מספר קונטיינרים שיתפזרו בין VM שונים, יאוחדו לקבוצות וכך המערכת תוכל "לדבר" בין החלקים
  • אם יש תקלה בקונטיינר מסוים, אפשר להרוג אותו והמערכת תקים מיד קונטיינר אחר זהה, כך שאם לדוגמא מישהו פרץ לקונטיינר מסוים, הפגיעה היא מקומית (תלוי כמובן בהגדרות היכן נמצאים הקבצים שנפגעו – בקונטיינר או על NFS/OCFS2 וכו'), ניתן להרוג את הקונטיינר ולהמשיך (כדאי כמובן לתקן את הקוד)
  • עם מערכת כמו Kubernetes ניתן לבצע תהליך הטמעה של גירסה חדשה כך שעדיין ישמרו גירסאות ישנות ולעבור לחדשות לפי קצב שיוחלט (לפי גילוי באגים ותיקונם וכו') וכך יחסך מצב של השבתת מערכת רק כי צריך להחליף גירסה.
  • אפשר להשתמש בהפצות לינוקס אחרות (או בקונטיינרים של Windows – אם אתם מריצים WIndows Server 2016) בתוך הקונטיינרים כך שאין זה משנה מה ההפצת לינוקס שמותקנת על ה-VM עצמו.
  • אין צורך בהגדרות זהות פר VM – ישנה מערכת ETCD שדואגת שההגדרות בין ה-Nodes יהיו זהות לחלוטין בין אחת לשניה באופן אוטומטי.
  • יעילות פר VM – הפצות כמו Atomic, CoreOS, RancherOS ואחרות – ניתן להתקין אותן על ה-VM ובכך לחסוך RAM שתפוס בד"כ על ידי הפצת הלינוקס ב-Node עצמו (אחרי התקנת הפצות כפי שציינתי לעיל – הזכרון התפוס נע בין 50-100 מגהבייט בלבד וה-Node גם עושה Boot מאוד מהר) ובאותו זכרון פנוי ניתן להשתמש לטובת הקונטיינרים.
  • על אותה מערכת Kubernetes ניתן גם להעלות קונטיינרים אחרים עם גרסאות שונות של האתר, לא צריך VM חדש לשם כך.
  • ויש עוד יתרונות.

במילים אחרות: מערכת Kubernetes מאפשרת לכם בעצם לעבוד בצורה יותר מאורגנת כאשר כל חלק הוא נפרד ורץ בקונטיינר משלו, כך שיותר קל לטפל בבעיות שצצות במקום "לנחש" היכן הן. בנוסף, מערכת Kubernetes כוללת כבר את כל עניין גדילה, High Availability, שרידות, Load-Balancing ללא צורך בתשלום על שרותים אלו בנפרד.

אפשר כמובן לעבוד על Kubernetes בלבד (ויש כמובן גם API – שהוא יותר "client") לשפות שונות כמו PHP, Python, דוט.נט ועוד, אולם אם בחברה יש מספר מפתחים לאתר, אני ממליץ להשתמש בכלי כמו OpenShift Origin כדי לבצע את כל הדברים ב-Kubernetes (כולל דברים ש-Kubernetes לא עושה כמו בניית קונטיינרים, עבודה כמשתמשים וקבוצות ועוד) או בכלי אוטומציה אחרים לבצע הן את הדברים דרך Kubernetes והן את ה"מסביב".

מבחינת עבודה עם Kubernetes – המערכת הזו כתובה ופועלת מעולה – כשזה נמצא על ספק ענן ציבורי כמו גוגל או אמזון. אם זה בתשתית של ספק אירוח מקומי, יש צורך לבצע "שמיניות באויר" בכדי להתחבר למכונות הללו מבחוץ כי היא פשוט בנויה לשימוש פנימי כאשר תקשורת מבחוץ מגיעה דרך תשתית ספק הענן. ב-OpenShift לעומת זאת, פתרו זאת עם HA-PROXY ועם ניתוב חכם כך שאין צורך להסתמך על שרות כמו Load Balancing של ספק ענן חכם ואפשר להשתמש בפתרון המובנה.

מבחינה טכנית, לאלו שיש כבר אתרים גדולים, אין היום שום כלי למיטב ידיעתי שיכול לעשות לאתר שלכם המרה ממצב שהוא רץ על Shared Hosting או VPS/VM או Instance למצב קונטיינר. את הדברים יש צורך לבצע ידנית ויכול להיות שיהיה צורך לבצע מספר שינויים קטנים בתהליך העבודה (שימוש ב-GIT, הפרדה בין תהליכים ועוד) וכמובן יש צורך במחשבה ובבניית תהליך כיצד להכניס את OpenShift לעבודה אצלכם (כך שלא מדובר במשהו שמבצעים בכמה שעות או ביום עבודה אחד).

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

גילוי נאות
מעבר לקונטיינרים הוא שרות שניתן ע"י חץ ביז

פרויקט נסיוני: קונטיינרים ו-Raspberry Pi-3

גילוי נאות / תודות
מכשירי ה-Raspberry Pi-3 ניתנו לי ע"י SuSE ישראל

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

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

כשזה מגיע לפיתוח, בין אם מדובר בפיתוח Low Level או בפיתוח בשפות אחרות, רוב הזמן המפתחים יכתבו את הקוד על ה-PC שלהם וישתמש ב-Cross Compile עם הקומפיילר החביב עליהם כדי ליצור קבצים בינאריים לציוד מבוסס ARM. אחרי הכל, לקמפל דברים על ARM זה לא כיף (זה איטי … אלא אם יש עליך איזה 500$ למערכת Jetson TX2 של nVidia ששם זה עובד יפה). הבעיה מתחילה בכל מה שקשור לבדיקות הרצה "על הברזל". פתרון של אמולציה זה לא רע (במיוחד אם האפליקציה לאנדרואיד וכתובה Native ב- ++C), אבל לפעמים צריך להריץ את האפליקציה "על הברזל" – במיוחד אם האפליקציה מתקשרת דרך ה-GPIO של הלוח (או דרך USB, יציאות סריאליות בלוח, JTAG וכו') – במקרים כאלו אמולציה לא תעזור ולחבר PC, להריץ אמולציה, למפות כתובות לתוך האמולציה בשביל להריץ את האפליקציה – זה סיבוך עם פוטנציאל להרבה נקודות כשל.

בקטע הזה – קונטיינרים על ARM יכולים להיות פתרון מעולה:

  • האפליקציות עצמם יכולות לרוץ אפליקציה פר קונטיינר על ה-Pi-3 ועוד קונטיינר יכול לשמש כ-DB קטן לדוגמא (SQLite) או אפליקציה קטנה שמקבלת תוצאות טסטים מהקונטיינר הראשון ואפשר להרחיב ולהרים קונטיינר נוסף שמקבל סדרות טסטים להריץ משרת כלשהו, כך שקונטיינר A (שמריץ את האפליקציה העיקרית) מתחבר לקונטיינר C (שמקבל משרת חיצוני את הטסטים שיש צורך להריץ), מבצע את הפעולות ומדווח את התוצאות לקונטיינר B (שמריץ DB או אפליקציה קטנה שאוספת לוגים ויוצרת סטטיסטיקות קטנות). שלושת הקונטיינרים רצים על מכשיר Pi-3 יחיד שמשמש בעצם כ-Node ומנוהל ע"י Master עם Kubernetes או OpenShift (שהם רצים על שרת רגיל).
  • לא צריך לכתוב גרסאות שונות של האפליקציה מחדש ל-eMMC, מערכת ה-Scheduling של הקונטיינר תעיף את הקונטיינר עם הגירסה הישנה ותפעיל על אותו מכשיר קונטיינר חדש. לא צריך Reboot, לא צריך להגדיר מחדש כלום. המפתח מוציא 20 גרסאות ביום עם תיקונים שונים? זמן ההקמה לבדיקה מתקצר בעשרות אחוזים.
  • לא חשוב מה המעבד ARM שיש, כל עוד יש לו גירסת לינוקס וחיבור רשת (ולא מדובר ב-MCU שעליו מבחינת חוסר משאבים לא ניתן להריץ קונטיינרים – כמו במקרים שיש לך כמה קילובייטים בודדים) – ניתן לעשות את הדברים הללו.
  • הקץ לאמולציות איטיות 🙂

ביצעתי בימים האחרונים טסט קטן שכולל 3 לוחות Raspberry Pi-3 ששימשו כ-Nodes ומכונת CentOS אחת שהריצה את OpenShift (שבתוכו יש את Kubernetes). מכיוון שהח"מ אינו חברת שמייצרת פתרונות חומרה, הקמתי מערכת שמריצה LAMP (שהתוכן מאוחסן ב-NFS) ו-2 מכונות וירטואליות שמריצות 20 קונטיינרים רזים (שמריצים ab כ"דפדפנים"). זה לא היה טסט לבדיקת ביצועים, אבל במחשבה שניה – כל Pi-3 הצליח להחזיק בערך כמה עשרות חיבורים סימולטניים. הפלתי כל פעם לוח (ניתוק חשמל) מתוך 3 לוחות ה-Pi-3 ולקח בממוצע כ-8 שניות עד שהמערכת זיהתה Node לא פעיל והזיזה את התקשורת ל-Nodes התקינים האחרים.

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