ניהול עם אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים – חלק א'

כתב: אנדריאס ניב, ארכיטקט ראשי לתחום השירותים הפיננסיים ברד-האט (Red Hat)

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

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

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

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

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

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

תיאום אופטימלי של משאבים ועומסי עבודה

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

תזמון קונטיינרים נדרש כדי לבצע את המעבר משלב הפיתוח לתפעול חי. בין השאר נבחן אופן ביזור קונטיינרים ברחבי תשתיות מטרה, ואיזה משאבים זמינים עבורם במערכות הקיימות. אלה יכולים להיות שרתים בדטה סנטר באתר הלקוח, אך גם שרתים בענן ציבורי או אפילו מספר עננים ציבוריים כמו AWS ,Google Cloud ו-Microsoft Azure. המטרה של תזמון קונטיינרים היא להבטיח ניצול אופטימלי של משאבי מחשוב זמינים, כגון עוצמת עיבוד, זיכרון, SSDs, ונפחי דיסק קשיח ורשת.

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

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

המשך הכתבה מחר.