ניהול תוך אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים
מאת: אנדריאס ניב, 6.9.17, 07:10

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

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

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

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

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

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

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

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

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

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

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

2. ניהול מחזור חיים

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

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

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

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

3. אבטחה

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

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

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

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

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

• כל הרכיבים צריכים להיות ממקורות מהימנים.
• צריך להיות ברור, שסטטוס האבטחה שלהם עדכני ולא עבר שינוי ללא הרשאה.
• כשכבה נוספת יש להשתמש ב-SELInux במארחי הקונטיינרים, כדי להגן על קונטיינרים פעילים מהמחשב המארח (Host) ואחד מהאחר. SELinux מבודדת את הקונטיינרים ומאשרת גישה רק למשאבים הנחוצים.

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

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

4. גילוי שירות (Service Discovery)

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

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

5. הרחבת יישומים ותשתיות

כאשר מדובר בגידול (Scaling) – תהליך, שייתמך ע"י מערכת ניהול הקונטיינרים – יש 2 סוגים שונים:

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

6. אספקת אחסון Persistent

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

לדוגמא, בשימוש ב-Red Hat OpenShift Container Platrform, יכולים אדמיניסטרטורים לספק קונטיינרי יישומים ואחסון קונטיינר Persistent, שמנהל את מסגרת התיאום (Orchestration) Kubennetes. מסגרת Kubernetes Persistent Uolume (PV) מקצה מאגר של קונטיינרי יישומים, שרצים על שרתים מבוזרים, עם אחסון Persistent. בשימוש ב-Persitent Volume Claims (PVCs), מפתחים מסוגלים לבקש משאבי PV בלי צורך במידע נרחב על תשתית האחסון, שביסוד המערכת.

אחסון קונטיינר טבעי, שמנוהל בשימוש בפתרון ניהול קונטיינרים, צריך לתמוך בהקצאה הדינמית של סוגי אחסון שונים כבלוק, קובץ ואובייקט, ואחסון רב-שכבתי דרך תוויות איכות שירות (Qality-of-service labels).

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

7. פתרונות קוד פתוח מציעים פוטנציאל גדול יותר במונחי חדשנות

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

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

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

לפי Github, כ-1,000 מפתחים מחברות המספקות תוכנה ולקוחותיהם עובדים על פרויקט הקוד הפתוח Kubernetes, שיוצר את הבסיס לניהול קונטיינרים בפתרונות רבים. בעת אספקת מהדורות חדשות, חדשנות מתרחשת הרבה יותר מהר מאשר עם תוכנה קניינית, בה סבבי מהדורות של 12 עד 18 חודשים הם הנורמה, לעומת 3 חודשים ל-Kubernetes. לכן, לפתרונות ניהול קונטיינרים בקוד פתוח יש יתרונות ניכרים לעומת פתרונות של יצרנים ספציפיים במונחי חדשנות, זריזות וגמישות.
 
מאת: אנדריאס ניב, ספטמבר 2017.
 ארכיטקט ראשי לתחום השירותים הפיננסיים ברד האט