קטגוריה: קונטיינרים

על קונטיינרים ו-Appliance

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

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

נחשוב על סיטואציה שמתרחשת אצל כל חברה שמייצרת Appliance (בין כ-VM ובין כקופסא פיזית) – החברה החליטה שבמסגרת הגירסה הבאה של התוכנה, היא מחליפה בדרך גם את הפצת הלינוקס שלה, ולא חשוב אם מדובר בשדרוג לגירסה אחרת מאותה הפצה או במעבר מ-Ubuntu ל-CentOS. המימוש לתהליך הזה די מורכב הואיל ומדובר על דריסה של מערכת קיימת ואם זה נשבר באמצע, ללקוח יהיה Appliance במצב לא שמיש (נקרא גם Brick). מעבר לכך זה גם מאוד תלוי אם המערכת הוקמה עם Volume Management (תתפלאו כמה Appliances אין להם את זה) ושההגדרות והנתונים יושבים על Logical Volume אחד, ה-DB יושב על Logical Volume אחר וכו' וכו'. בלי זה – כתיבת השדרוג הולכת להיות מורכבת ומסובכת (מנסיון…)

וכאן בדיוק קונטיינרים יכולים מאוד לעזור בשילוב LVM (ר"צ של Logical Volume Manager). את ה-Appliance אפשר לבנות בתצורה הבאה לדוגמא (בניכוי כל הדברים הקשורים ל-Volume Groups וכו'):

  • מחיצת boot/ בגודל 1 ג'יגהבייט (זה הסטנדרט המומלץ בסנטוס 7, אגב) ללא LVM
  • LV לוגי שמכיל את ה-OS עצמו בלבד.
  • LV שמכיל את ספריות ה-DB וקבצי קונפיגורציה
  • LV שמכיל קונטיינרים
  • LV לגיבויים
  • LV שמיועד לקבצים זמניים, Cache וכו'
  • LV ספייר (ריק, לשימושים שונים במהלך חיי ה-Appliances כמו פריסת Plugins זמניים, קבצי התקנה זמניים ועוד ועוד)

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

מבחינת קונטיינרים, יהיו במערכת מינימום 2 קונטיינרים (או 3, תלוי בחברה, מה המוצר, מורכבות ועוד):

  • בקונטיינר הראשון תרוץ אפליקציית Web שמטרתה העיקרית היא ניהול ה-appliance עצמו ברמת סיסטם: עדכוני תוכנה, יצירת גיבוי ושחזור, הרצת בדיקות תקשורת, התחברות ל-AD (אם צריך) ו/או למערכות אחרות. לאותו קונטיינר אנחנו נמפה הן את ה-DB והן את תיקיית קבצי הקונפיגורציה כך ששינויים ישמרו, גם אם לקונטיינר יקרה נזק/יפול/ימחק. לקונטיינר הזה המשתמש יגש דרך כתובת ה-IP של ה-appliance אך דרך פורט אחר שאינו 80/443 ומומלץ שיהיו לו יוזרים שונים מהיוזרים שמשתמשים ב-appliance עצמו.
  • בקונטיינר השני תרוץ האפליקציה העיקרית שלנו וגם בקונטיינר זה אנו נמפה את התיקיות קונפיגורציה ואת תיקיית ה-DB. לכאן המשתמש יגיע דרך HTTP או דרך HTTPS לפי העדפותיכם כמובן (אגב, טיפ קטן לחברות שבונות appliances – תנו דרך קלה להכניס תעודות SSL).
  • אופציונאלי: קונטיינר שלישי יריץ את ה-DB וגם אליו נמפה את תיקיית ה-DB. הסיבה שאני ממליץ להפריד את ה-DB לקונטיינר אחר היא שבמקרים רבים ללקוח יש הרבה פעילות וה-Appliance מגיב באיטיות כשהוא בעומס, ולכן כדאי לחשוב על מתן אפשרות הקמת Appliance רק עם ה-DB.

היתרונות בעבודה בדרך זו:

  • יצרן ה-Appliance יכול להשתמש בכל גירסה באיזו הפצת לינוקס שירצה, מבחינת המערכת – זה בסך הכל Image שקונטיינר מריץ. האפליקציה בקונטיינר מתממשקת לתיקיה של ההגדרות וה-DB ויכולה לזהות אם ההגדרות ישנות (או הנתונים ב-DB ישנים) ולשדרגם בהתאם.
  • כשיש עדכון חרום או עדכון רגיל שאיננו החלפת גירסת Major, העדכון שירד יהיה די קטן והוא ירד בצורה מאובטחת מ-repository של היצרן דרך התשתית של docker, המערכת תעדכן את קבצי ה-image, תבנה קונטיינר חדש ותחליף את הקיים בצורה שקופה.
  • כשיש שדרוג לגירסת Major חדשה, קונטיינר אחר נותן חוויית שימוש הרבה יותר אינפורמטיבית ללקוח, הוא יכול לראות מה קורה מבחינת אחוזי הורדה, מה המערכת עושה.
  • עדכוני מערכת ההפעלה הראשית (שאינה נמצאת בקונטיינר) הם בטוחים וגם אם יש תקלה, המקסימום שיהיה צורך זה לעדכן את ה-OS המינימלי. זה לא נוגע בקונטיינרי (ההגדרות יושבות ב-LV אחר).
  • אם הלקוח גודל מחר וצריך DB עם רפליקציות וכו' – השינויים שיש צורך לבצע הם מינוריים.
  • הזמן שלוקח מגילוי תקלה בתוכנה ועד שחרור ללקוחות (לאחר בדיקה) – מתקצר משמעותית. מהרגע שהחברה שחררה עדכון, הלקוח יכול להיכנס לקונטיינר הניהול, ללחוץ על Update מבלי להוריד קבצים.
  • זמן הירידה והעליה של ה-Appliance לאחר שדרוג מתקצר משמעותית.
  • אפשר לפתוח לטובת הלקוחות ערוצים נוספים כמו testing, beta, stable והלקוח יוכל לבחור לעבור, מדובר בסופו של דבר רק בהחלפת קונטיינר (חשוב לזכור: האפליקציה של הלקוח תצטרך להתמודד עם קבצי הקונפיגורציה וה-DB מבחינת שינוי ושדרוגם)
  • הלקוח יוכל לבצע (או שהמערכת תבצע עבורה) גיבוי של הקונפיגורציה וה-DB במהירות (מדובר ב-LV snapshot שהוא חלק בסיסי בלינוקס) ו-rollback במקרה הצורך.

במקרים כמו עבודה של Offline עקב דרישות של ארגונים בטחוניים או אגף אבטחת המידע של החברה, יהיה צורך בשינויים- אבל את זה אני משאיר מחוץ למאמר זה 🙂

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

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

[stextbox id="alert" caption="גילוי נאות"]"חץ ביז" מעניק שרותי הקמה, תמיכה ואינטגרציה לקונטיינרים על לינוקס.[/stextbox]

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

[stextbox id="alert" caption="גילוי נאות"]"חץ ביז" מעניק שרותי הקמה, תמיכה ואינטגרציה ל-OpenStack בכל הגרסאות[/stextbox]

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

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

[stextbox id="info" caption="גילוי נאות"]מעבר לקונטיינרים הוא שרות שניתן ע"י חץ ביז[/stextbox]