היום בכל מקום חוזר המושג קונטיינרים לצוץ בתכיפות. אז לכל אלו שרוצים להבין על מה מדובר, גם אם הם אינם כרישי DevOps (או יותר נכון ליוויתן DevOps), המאמר הזה מוקדש לכם.
אז בואו נחזור לבסיס, בתחילת הדרך הכל היה פשוט, היה לנו שרת פיזי עליו התקנו את מערכת ההפעלה ואפליקציה אחת או יותר בהתאם לצורך, הכול היה טוב עד שגילינו שכוח המחשוב של השרת שלנו הפך להיות חזק בהרבה מדרישות התוכנה שהתקנו עליו עם ניצולת משאבים ממוצעת של כ-15% בלבד בכל שרת ובמקביל גם מחירו של השרת עלה באופן משמעותי מה שהפך את כל הנושא לבזבזני מאוד ולכן הפתרון שנבחר היה מעבר לווירטואליזציה.
אם נזכור שהמושג "וירטואלי" משמעותו היא מימוש של דבר פיזי בתוכנה נוכל להבין את היכולת להקים מספר שרתים וירטואליים על גבי שרת פיזי אחד, עשינו זאת על ידי כך שהוספנו לשרת הפיזי שלנו שכבה נוספת חדשה שנקראת Hypervisor שתפקידה לייצר סביבה בה כל שרת וירטואלי יכול לעבוד מבלי שהוא ידע שהוא וירטואלי ושהוא גם חולק את המשאבים הפיזיים של השרת המארח עם עוד עשרות שרתים אחרים ובכך ייעלנו בצורה דרמטית את כוח המחשוב שלנו בחדר המחשב על ידי הקמה של עשרות שרתים וירטואליים על גבי שרת פיזי אחד.
אחרי זמן מה נוצרה בעיה חדשה למרות פתרון הווירטואליזציה. עיקר הבעיה כאשר התחלנו לייצר ולצרוך הרבה מאוד סוגים של אפליקציות על גבי פלטפורמות השונות. לכל אפליקציה ארגונית כזו או אחרת ישנן דרישות מחשוב שונות, שדורשות מאתנו לייצר לכול אפליקציה כזו שרת ייעודי שיריץ על גבו מערכת הפעלה ייעודית וכוח מחשוב ייעודי. לא עבר הרבה זמן עד שהגענו למצב שבכל חדר מחשב ישנם אלפי שרתים וירטואליים שאנחנו צריכים לנהל, לתחזק ולא פחות חשוב לרכוש רישוי לכל אחד ואחד מהם, דבר שהפך להיות מצד אחד מאוד מסורבל ומצד שני מאוד יקר. הפתרון המוביל שנוצר כדי לתת מענה למצב זה הינו מעבר לשימוש בקונטיינרים.
?מה זה אומר? מה זה קונטיינרים
כדי לעזור לנו להבין את עולם הקונטיינרים עלינו להסתכל על עולם הספנות המודרני. הסיבה היחידה שעולם הספנות מצליח להעביר כ-20 מיליון קונטיינרים ברחבי העולם בכל יום ביעילות, בין אם זה בים או ביבשה, נעוצה בעובדה שלפני כמה שנים הסכימו כלל בעלי העניין על תקן מסודר וברור, שמגדיר את המידות והמאפיינים של קונטיינר סטנדרטי. תחשבו על זה, לפני שנוצר התקן הזה יצרנים שונים ברחבי העולם שרצו לשלוח את התוצרת שלהם מעבר לים, היו אורזים זאת בכל דרך שמצאו לנכון על גבי משטחים ייעודיים, שולחים אותם לדרכם במשאית ייעודית מתאימה לסוג המסוים של המשלוח שלהם. מיותר לציין כמה לא יעילה השיטה הזו בעולם המודרני, כאשר אנו נדרשים לשנע מיליוני טונות של סחורה ממקום למקום בעולם. היום היצרן מכניס את סחורתו לקונטיינר סטנדרטי, הדבר מאפשר לו לנוע בחופשיות, ללא תלות במוביל כזה או אחר.
?איך זה מתקשר לעולם שלנו
גם בעולם שלנו, במקום לשנע את האפליקציה שלנו בצורה מסורבלת, ארוזה עם עוד אפליקציה תומכת ומערכת הפעלה ייעודית, בתוך שרת וירטואלי ייעודי, אנחנו פשוט מקלפים ממנה את השכבות של מערכת ההפעלה, אפליקציות תומכות וכדומה ואורזים אותן בתוך קונטיינר סטנדרטי, שעכשיו יכול לרוץ בכל פלטפורמה, ללא תלות במערכת הפעלה, יותר מזה, מכיוון שכל קונטיינר הוא קטן יחסית במידות שלו ניתן להריץ רבים כאלו על שרת אחד בודד.
חשוב לדעת שאת הגדרת הגודל והמבנה של קונטיינרים הובילה חברת Docker© ובשנת 2013 הגדרה זו התקבלה בכל העולם כתקן ליצירת קונטיינרים.
ציר נוסף שיעזור לנו להבין טוב יותר מה זה קונטיינרים ואיך הם עובדים בחיי היום יום הינו הבנה של תהליך פיתוח התוכנה.
גם כאן נתחיל מהבסיס, על מנת לקיים תהליך של פיתוח אפליקציה ארגונית או אפליקציית רשת , נידרש להקים מערך גדול שיעסוק בפיתוח האפליקציה (תשתיות, תשתיות אפליקטיביות, מחלקות פיתוח, אינטגרציה וכמובן מחלקת בדיקות). אפליקציה במבנה הקלאסי שלה מורכבת ממספר רב של מודלים ושירותים אשר ארוזים כולם יחדיו על גבי שרת ייעודי אחד או יותר (הגישה המונוליטית). ניקח לדוגמא אפליקציית ERP ארגוני. על מנת להקים מערכת ERP בארגון אנו נדרשים להקים מספר שרתי WEB שישמשו כממשק המשתמש של המערכת, שרתי האפליקציה, שרתי בסיס הנתונים וכמובן מערך תקשורת תומך ומקשר בין כל השרתים הללו, כאשר כל שרת כזה ממוקם על שרת וירטואלי עם מערכת הפעלה, (WINDOWS או LINUX) ושורת אפליקציות תומכות וכך קיבלנו שאפליקציה ERP ארגונית אחת מורכבת כיום מעשרות שרתים, שפרוסים על פני הסביבות השונות.
?אז איפה הבעיה
הבעיה המרכזית מהתצורה לעיל היה שגם היא הפכה להיות מסורבלת, כל פיתוח של גרסה חדשה ארך חודשים רבים, בעיקר כיוון שמעבר לפיתוח התוכנה עצמה, אנו נדרשים להשקיע הרבה מאוד מאמצים בתיאום ואינטגרציה של כלל הרכיבים התומכים באפליקציה שלנו: מערכת הפעלה, גרסת JAVA, גרסת SQL ועוד, מסורבל כבר אמרנו? הקונטיינר נותן מענה לסירבול זה. הקונטיינר למעשה מסנתז את הקוד עצמו ללא כל אותן שכבות "מיותרות" של מערכת ההפעלה והאפליקציות התומכות, ואורז אותו בתוך קונטיינר קטן שיכול עכשיו לרוץ בכל פלטפורמה שנרצה, בין אם זה על גבי התשתית הווירטואלית הקיימת או בענן, או אפילו על אפילו ישירות על החומרה עצמה ישירות. כך בעצם ניתקנו את הקוד שלנו מכל המשקל העודף שהיה תלוי על צווארו (אין יותר מערכת הפעלה ואין אפליקציות תומכות). יצרנו עולם בו פיתוח של כל חלק באפליקציה שלנו הוא פשוט יותר, האינטגרציה בין המחלקות השונות, שמפתחות חלקים שונים במערכת שלנו, פשוטה יותר וקלה יותר., כל עוד אתה אורז את הקוד שלך בתוך קונטיינר סטנדרטי, האינטגרציה שלו עם הסביבה בה הוא אמור לעבוד, הופכת להיות משהו פשוט וקל יותר לתחזוקה ולבדיקות. אותו קונטיינר יכול עכשיו לרוץ בכל פלטפורמה קונטיינרים שנבחר.
חשוב שנבין שעולם הקונטיינרים אינו שייך רק לאפליקציות מהדור החדש (Cloud native/ cloudlike). כיום יש לנו את היכולת להפוך כמעט כל אפליקציה מונוליטית לאפליקציה מבוססת קונטיינרים בדרך פשוטה יחסית. ניתן להתחבר לאחד ממאגרי התבניות (Official Repositories) ולהוריד משם את כל אחת מהתבניות המוגדרות מראש, הדרושות לנו כדי להרכיב את השירות שלנו ולהתחיל לעבוד.
בעוד ש- Docker סיפק סטנדרט פתוח לאריזה והפצה של יישומים בקונטיינרים, התעוררה בעיה חדשה. איך מנהלים ומתאמים את כל הקונטיינרים? איך הקונטיינרים השונים באפליקציה שלך אמורים לתקשר אחד עם השני? כיצד ניתן לשנות קנה מידה (Scale up & Out) של קונטיינרים?
עד מהרה פותחו פתרונות לניהול קונטיינרים (Orchestrating) בסביבות השונות. מערכות כמו Kubernetes, Mesos, ו- Docker Swarm הם חלק מהאפשרויות הפופולרית יותר עבור מתן יכולת הניהול, הדרושה בכדי להפוך אשכול (Cluster) של מכונות להתנהג כמו מכונה אחת גדולה, שהיא חיונית בסביבת הייצור של ארגוני אנטרפרייז.
המערכת הנפוצה כיום בארגונים היא Kubernetes(K8s) שמספקת לארגון את פתרון Orchestrator אשר פותח ב- Google ונתרם לארגון CNCF (Cloud Native Computing Foundation) . Kubernetes מופץ כיום כקוד פתוח. K8s מנצלת באופן מיטבי את הניסיון הרב של Google בניהול קונטיינרים. זוהי מערכת מקיפה לאוטומציה של פריסה, תזמון ושינוי של אפליקציות הקונטיינרים, ותומכת בכלים רבים של קונטיינרים כגון Docker, ובכך מספקת ללקוחות שרוצים לשלב את עולם הקונטיינרים בארגון שלהם בסביבת פיתוח מלאה ויציבה ולכן רוב הארגונים מאמצים את המערכת הזו על פני המערכות המתחרות.
השימוש בכל המערכות שצויינו לעיל דורש ניהול ותכנון נכונים על מנת שבאמת תהליך השימוש בקונטיינרים ישיג את התוצאות הרצויות.
TeraSky ,מאת: אתגר פישל. מנהל צוות ניהול פרויקטים
אתגר פישל הינו ראש צוות ניהול פרוייקטים עם ניסיון של שנים רבות בעולמות הענן והוירטואליזציה. מומחי TeraSky ו- SkyWiz ביצעו ומבצעים פרוייקטים מבוססים קונטיינרים בסביבות מגוונות וישמחו לתת מענה לכל פניה.
היום בכל מקום חוזר המושג קונטיינרים לצוץ בתכיפות. אז לכל אלו שרוצים להבין על מה מדובר, גם אם הם אינם כרישי DevOps (או יותר נכון ליוויתן DevOps), המאמר הזה מוקדש לכם.
אז בואו נחזור לבסיס, בתחילת הדרך הכל היה פשוט, היה לנו שרת פיזי עליו התקנו את מערכת ההפעלה ואפליקציה אחת או יותר בהתאם לצורך, הכול היה טוב עד שגילינו שכוח המחשוב של השרת שלנו הפך להיות חזק בהרבה מדרישות התוכנה שהתקנו עליו עם ניצולת משאבים ממוצעת של כ-15% בלבד בכל שרת ובמקביל גם מחירו של השרת עלה באופן משמעותי מה שהפך את כל הנושא לבזבזני מאוד ולכן הפתרון שנבחר היה מעבר לווירטואליזציה.
אם נזכור שהמושג "וירטואלי" משמעותו היא מימוש של דבר פיזי בתוכנה נוכל להבין את היכולת להקים מספר שרתים וירטואליים על גבי שרת פיזי אחד, עשינו זאת על ידי כך שהוספנו לשרת הפיזי שלנו שכבה נוספת חדשה שנקראת Hypervisor שתפקידה לייצר סביבה בה כל שרת וירטואלי יכול לעבוד מבלי שהוא ידע שהוא וירטואלי ושהוא גם חולק את המשאבים הפיזיים של השרת המארח עם עוד עשרות שרתים אחרים ובכך ייעלנו בצורה דרמטית את כוח המחשוב שלנו בחדר המחשב על ידי הקמה של עשרות שרתים וירטואליים על גבי שרת פיזי אחד.
אחרי זמן מה נוצרה בעיה חדשה למרות פתרון הווירטואליזציה. עיקר הבעיה כאשר התחלנו לייצר ולצרוך הרבה מאוד סוגים של אפליקציות על גבי פלטפורמות השונות. לכל אפליקציה ארגונית כזו או אחרת ישנן דרישות מחשוב שונות, שדורשות מאתנו לייצר לכול אפליקציה כזו שרת ייעודי שיריץ על גבו מערכת הפעלה ייעודית וכוח מחשוב ייעודי. לא עבר הרבה זמן עד שהגענו למצב שבכל חדר מחשב ישנם אלפי שרתים וירטואליים שאנחנו צריכים לנהל, לתחזק ולא פחות חשוב לרכוש רישוי לכל אחד ואחד מהם, דבר שהפך להיות מצד אחד מאוד מסורבל ומצד שני מאוד יקר. הפתרון המוביל שנוצר כדי לתת מענה למצב זה הינו מעבר לשימוש בקונטיינרים.
?מה זה אומר? מה זה קונטיינרים
כדי לעזור לנו להבין את עולם הקונטיינרים עלינו להסתכל על עולם הספנות המודרני. הסיבה היחידה שעולם הספנות מצליח להעביר כ-20 מיליון קונטיינרים ברחבי העולם בכל יום ביעילות, בין אם זה בים או ביבשה, נעוצה בעובדה שלפני כמה שנים הסכימו כלל בעלי העניין על תקן מסודר וברור, שמגדיר את המידות והמאפיינים של קונטיינר סטנדרטי. תחשבו על זה, לפני שנוצר התקן הזה יצרנים שונים ברחבי העולם שרצו לשלוח את התוצרת שלהם מעבר לים, היו אורזים זאת בכל דרך שמצאו לנכון על גבי משטחים ייעודיים, שולחים אותם לדרכם במשאית ייעודית מתאימה לסוג המסוים של המשלוח שלהם. מיותר לציין כמה לא יעילה השיטה הזו בעולם המודרני, כאשר אנו נדרשים לשנע מיליוני טונות של סחורה ממקום למקום בעולם. היום היצרן מכניס את סחורתו לקונטיינר סטנדרטי, הדבר מאפשר לו לנוע בחופשיות, ללא תלות במוביל כזה או אחר.
?איך זה מתקשר לעולם שלנו
גם בעולם שלנו, במקום לשנע את האפליקציה שלנו בצורה מסורבלת, ארוזה עם עוד אפליקציה תומכת ומערכת הפעלה ייעודית, בתוך שרת וירטואלי ייעודי, אנחנו פשוט מקלפים ממנה את השכבות של מערכת ההפעלה, אפליקציות תומכות וכדומה ואורזים אותן בתוך קונטיינר סטנדרטי, שעכשיו יכול לרוץ בכל פלטפורמה, ללא תלות במערכת הפעלה, יותר מזה, מכיוון שכל קונטיינר הוא קטן יחסית במידות שלו ניתן להריץ רבים כאלו על שרת אחד בודד.
חשוב לדעת שאת הגדרת הגודל והמבנה של קונטיינרים הובילה חברת Docker© ובשנת 2013 הגדרה זו התקבלה בכל העולם כתקן ליצירת קונטיינרים.
ציר נוסף שיעזור לנו להבין טוב יותר מה זה קונטיינרים ואיך הם עובדים בחיי היום יום הינו הבנה של תהליך פיתוח התוכנה.
גם כאן נתחיל מהבסיס, על מנת לקיים תהליך של פיתוח אפליקציה ארגונית או אפליקציית רשת , נידרש להקים מערך גדול שיעסוק בפיתוח האפליקציה (תשתיות, תשתיות אפליקטיביות, מחלקות פיתוח, אינטגרציה וכמובן מחלקת בדיקות). אפליקציה במבנה הקלאסי שלה מורכבת ממספר רב של מודלים ושירותים אשר ארוזים כולם יחדיו על גבי שרת ייעודי אחד או יותר (הגישה המונוליטית). ניקח לדוגמא אפליקציית ERP ארגוני. על מנת להקים מערכת ERP בארגון אנו נדרשים להקים מספר שרתי WEB שישמשו כממשק המשתמש של המערכת, שרתי האפליקציה, שרתי בסיס הנתונים וכמובן מערך תקשורת תומך ומקשר בין כל השרתים הללו, כאשר כל שרת כזה ממוקם על שרת וירטואלי עם מערכת הפעלה, (WINDOWS או LINUX) ושורת אפליקציות תומכות וכך קיבלנו שאפליקציה ERP ארגונית אחת מורכבת כיום מעשרות שרתים, שפרוסים על פני הסביבות השונות.
?אז איפה הבעיה
הבעיה המרכזית מהתצורה לעיל היה שגם היא הפכה להיות מסורבלת, כל פיתוח של גרסה חדשה ארך חודשים רבים, בעיקר כיוון שמעבר לפיתוח התוכנה עצמה, אנו נדרשים להשקיע הרבה מאוד מאמצים בתיאום ואינטגרציה של כלל הרכיבים התומכים באפליקציה שלנו: מערכת הפעלה, גרסת JAVA, גרסת SQL ועוד, מסורבל כבר אמרנו? הקונטיינר נותן מענה לסירבול זה. הקונטיינר למעשה מסנתז את הקוד עצמו ללא כל אותן שכבות "מיותרות" של מערכת ההפעלה והאפליקציות התומכות, ואורז אותו בתוך קונטיינר קטן שיכול עכשיו לרוץ בכל פלטפורמה שנרצה, בין אם זה על גבי התשתית הווירטואלית הקיימת או בענן, או אפילו על אפילו ישירות על החומרה עצמה ישירות. כך בעצם ניתקנו את הקוד שלנו מכל המשקל העודף שהיה תלוי על צווארו (אין יותר מערכת הפעלה ואין אפליקציות תומכות). יצרנו עולם בו פיתוח של כל חלק באפליקציה שלנו הוא פשוט יותר, האינטגרציה בין המחלקות השונות, שמפתחות חלקים שונים במערכת שלנו, פשוטה יותר וקלה יותר., כל עוד אתה אורז את הקוד שלך בתוך קונטיינר סטנדרטי, האינטגרציה שלו עם הסביבה בה הוא אמור לעבוד, הופכת להיות משהו פשוט וקל יותר לתחזוקה ולבדיקות. אותו קונטיינר יכול עכשיו לרוץ בכל פלטפורמה קונטיינרים שנבחר.
חשוב שנבין שעולם הקונטיינרים אינו שייך רק לאפליקציות מהדור החדש (Cloud native/ cloudlike). כיום יש לנו את היכולת להפוך כמעט כל אפליקציה מונוליטית לאפליקציה מבוססת קונטיינרים בדרך פשוטה יחסית. ניתן להתחבר לאחד ממאגרי התבניות (Official Repositories) ולהוריד משם את כל אחת מהתבניות המוגדרות מראש, הדרושות לנו כדי להרכיב את השירות שלנו ולהתחיל לעבוד.
בעוד ש- Docker סיפק סטנדרט פתוח לאריזה והפצה של יישומים בקונטיינרים, התעוררה בעיה חדשה. איך מנהלים ומתאמים את כל הקונטיינרים? איך הקונטיינרים השונים באפליקציה שלך אמורים לתקשר אחד עם השני? כיצד ניתן לשנות קנה מידה (Scale up & Out) של קונטיינרים?
עד מהרה פותחו פתרונות לניהול קונטיינרים (Orchestrating) בסביבות השונות. מערכות כמו Kubernetes, Mesos, ו- Docker Swarm הם חלק מהאפשרויות הפופולרית יותר עבור מתן יכולת הניהול, הדרושה בכדי להפוך אשכול (Cluster) של מכונות להתנהג כמו מכונה אחת גדולה, שהיא חיונית בסביבת הייצור של ארגוני אנטרפרייז.
המערכת הנפוצה כיום בארגונים היא Kubernetes(K8s) שמספקת לארגון את פתרון Orchestrator אשר פותח ב- Google ונתרם לארגון CNCF (Cloud Native Computing Foundation) . Kubernetes מופץ כיום כקוד פתוח. K8s מנצלת באופן מיטבי את הניסיון הרב של Google בניהול קונטיינרים. זוהי מערכת מקיפה לאוטומציה של פריסה, תזמון ושינוי של אפליקציות הקונטיינרים, ותומכת בכלים רבים של קונטיינרים כגון Docker, ובכך מספקת ללקוחות שרוצים לשלב את עולם הקונטיינרים בארגון שלהם בסביבת פיתוח מלאה ויציבה ולכן רוב הארגונים מאמצים את המערכת הזו על פני המערכות המתחרות.
השימוש בכל המערכות שצויינו לעיל דורש ניהול ותכנון נכונים על מנת שבאמת תהליך השימוש בקונטיינרים ישיג את התוצאות הרצויות.
TeraSky ,מאת: אתגר פישל. מנהל צוות ניהול פרויקטים
אתגר פישל הינו ראש צוות ניהול פרוייקטים עם ניסיון של שנים רבות בעולמות הענן והוירטואליזציה. מומחי TeraSky ו- SkyWiz ביצעו ומבצעים פרוייקטים מבוססים קונטיינרים בסביבות מגוונות וישמחו לתת מענה לכל פניה.
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר