על קונטיינרים ו-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]

Exit mobile version