IT News פורטל המחשוב העסקי וההייטק של ישראל
הגביע הקדוש של מפתחי הקוד: מה בין CICD– Continues Integration Continues Deployment לבין דוקרים, מכלים (Containers) וקוברנטיס? ואיך ממקסמים את ההשקעה בתהליכים אלו?
מאת: בני פיטוסי, מנהל מוצר Talend ב- aQurate
בתהליכי פיתוח של מוצרים הדבר החשוב ביותר למפתחים הוא ההמשכיות, חשוב שתהליך הפיתוח ישמר לכל אורך ההרצה שלו והפעלת תהליך הבדיקות המוודא את תקינותו.
האידיאל הוא הפעלת מנגנון אוטומטי שידע לקחת את הקוד שפותח , יקמפל אותו ויפעיל מנגנוני בדיקות אוטומטים שיוודאו שאכן הקוד נכתב בצורה תקינה וגם נשמר כך. רק לאחר מכן ניתן יהיה להטמיע אותו במקום אליו הוא יועד. ברגע שהתהליך יהיה אוטומטי, ירד אחוז השגיאות בצורה דרמטית.
מתודולוגית CI/CD – Continuous Integration, Continuous Delivery, Continuous Deployment , או בעברית: 'אינטגרציה רציפה, אספקה רציפה, פריסה רציפה', קובעת כללי מפתח ושלבים ברורים בתהליך הפיתוח, המאפשרים לאנשים שונים בתכלית להגיע למכנה משותף זהה, לעבוד בסטנדרט אחיד ולהשיג את התוצאות הרצויות תחת לוח הזמנים והתקציב המוגדרים. לא פחות חשוב מכך, היא מאפשרת לאנשי מקצוע צעירים ללמוד ולהתפתח עם הארגון.
מתודולוגית CI/CD מאפשרת להשתמש בכלי אוטומציה בתהליך פיתוח הקוד. כל תהליך בניה בפרויקט, גדול או קטן, צריך להתחיל באופן אוטומטי על מנת להקטין את מספר טעויות האנוש. בתהליך האוטומציה מתרחשים מספר צעדים חיוניים שאין לפסוח עליהם: בדיקת שגיאות הקלדה בקוד (static analysis), מבחנים אחידים לקוד (Unitests), מבחני אינטגרציה (Integration tests) ואריזה.
מהו דוקר? כיצד הוא מפעיל מכלים?
דוקר הוא פלטפורמת תוכנה שמאפשרת לבנות, לשתף ולהריץ יישומים בתוך מכלים (Containers). כדי להבין טוב יותר למה צריך פלטפורמה כזאת בארגון, בואו נניח שיש לכם מערכת שמורכבת ממספר רכיבים: בסיס נתונים, שרת ווב, שרת יישום, שירותים ( services) קטנים שעוזרים ליישום לרוץ ועוד.
בלי דוקר אתם עלולים להיתקל במספר בעיות בעבודה עם מערכת כזאת. קודם כל בסביבת הפיתוח: יכול להיות שתרצו לנסות לפתח גרסה חדשה של המערכת מול גרסה חדשה יותר של בסיס הנתונים, אבל עדיין לשמור על בסיס הנתונים הישן מותקן על המחשב כדי לתקן באגים בגרסת הפרודקשן. ובעצם אותה הבעיה קיימת עם כל רכיב תשתית שבחרתם – שדרוג של השרת, או של גרסת שפת התכנות או ספריות מסביב. כל אלה יכולים ליצור התנגשויות כשמנסים לשלב מספר גרסאות על אותה מכונת פיתוח.
אותה הבעיה קיימת עם כל רכיב תשתית שבחרתם – שדרוג של השרת, או של גרסת שפת התכנות או ספריות מסביב. כל אלה יכולים ליצור התנגשויות כשמנסים לשלב מספר גרסאות על אותה מכונת פיתוח. כשנכנס מפתח חדש לצוות הוא עלול למצוא את עצמו מבלה יום שלם בהתקנות. התקנת כל החלקים והתשתיות של המערכת על מכונה חדשה נהיית מורכבת יותר ככל שיש יותר רכיבים.
ובאותו האופן בשלב המעבר לייצור אתם עשויים להיתקל במספר בעיות: קושי להוסיף או להוריד "שרתים" מהרשת – מאחר וכל שרת צריך להחזיק את כל רכיבי התשתית כדי להריץ את המערכת.
בעיית ניצול של השרתים הקיימים בגלל התקנות גלובליות – יכול להיות שהשרת שלכם מספיק "פנוי" רוב הזמן כדי להריץ עוד רכיב במערכת, אבל הרכיב הזה דורש גרסה אחרת של בסיס הנתונים ואתם לא רוצים ליצור התנגשות.
דוקר יודע לפתור חלק גדול מהבעיות האלה באמצעות שימוש במכלים. כל מיכל מחזיק בתוכו אפליקציה אחת או יותר והדוקר עצמו יודע "להפעיל" מכלים כאלה בתוך סביבה חצי מבודדת. זה לא מכונה וירטואלית נפרדת אלא משהו הרבה יותר קליל. התהליכים והקבצים נשמרים ישירות על המכונה הנוכחית, אבל בנפרד מהמערכת הראשית ובעצם המפתחים נותנים ליישום הרגשה שהוא רץ לבד, למרות שהוא בעצם רץ עם עוד הרבה יישומים אחרים.
חשוב לציין שבגלל שאין הפרדה מוחלטת בין המכלים אם מיכל מסוים ירצה לשבור לכם את השרת או להאזין למכלים אחרים הוא יוכל לעשות את זה. לכן חשוב לזכור שדוקר אינו מכונה וירטואלית וחשוב להריץ רק מכלים שאתם סומכים עליהם.
ואיך משתלבת קוברנטיס?
קוברנטיס, Container Orchestration Framework , היא סוג של סביבת ענן. שיש להגיד לה מה להריץ – והיא מריצה. ״מזינים״ אותה ב Containers (מסוג Docker או rkt) והגדרות – והיא ״דואגת לשאר״. וכן יש להקצות לקוברנטיס כמה שרתים (nodes) שעליהם ירוצו הקונטיינרים. בנוסף, יש להקצות עוד כמה שרתים כדי להריץ את ה master nodes – ה״מוח״ מאחורי ה cluster. כך שניתן להגיד שקוברנטיס מאפשרת רמה חדשה וגבוהה יותר של יעילות בניצול משאבי-חומרה.
למפתחים שעובדים על גבי מערכות On-Premises ללא טכנולוגיות ענן. מעבר משם לקוברנטיס – היא באמת התקדמות אדירה. המעבר משימוש ב"ענן של מכונות וירטואליות" לקוברנטיס – הוא פחות דרמטי.
לסיכום, איזה כלי מומלץ כדי להשיג את המרב מ- CICD, Dockers, Containers וקוברנטיס?
Talend Data Fabric הכלי שנבנה בארכיטקטורה שמושתתת על קוד פתוח ופרדיגמות של פיתוח קוד מהיר ויעיל, ניתן לבנות את אותו docker בלחיצת כפתור או במנגנון אוטומטי של CI/CD מבלי שצריך לכתוב קוד או לפתח במשהו במיוחד.
דרך הגישה שהכלי מחולל קוד ואינו מצריך רכיבי ריצה ייעודיים (הכלי מחולל JAR או SPARK) עובדה זאת מאפשרת לתהליכים שרצים ל"רוץ" במהירות של פי 10 ואף יותר מול המוצרים המתחרים. בארכיטקטורה נבנו מנגנונים המאפשרים ללקוחות לתחזק את התהליכים בקלות (Continuous Integration) ובמהירות בזכות מנגנוני תהליכי הבדיקות וניהול הגרסאות המאפשרים יצירתה של גרסה חדשה של תהליך קיים והעברתה לייצור בדקות ספורות.
Talend Data Fabric מציע אוטומציה מלאה, שמירת ההשקעה בפיתוח, פתרון פתוח ללא צורך בשרת Run Time ייעודי, הסבת תהלכי Legacy באמצעות הMetadata Bridge, פתרון אינטגרטיבי עם עולם ה Big Data כך שזמן הפיתוח Time To Market הופך לקצר ביותר.
