על מגרות, סביבות ריצה וה-"power-couple of devops"

כיצד מייצרים סביבה נקייה במחשב האישי שלנו עבור עבודת הפיתוח?

shutterstock servers

הפוסט נכתב על-ידי מירון גופר – מומחה DevOps בטיקל 

פעם, לפני לא מעט שנים, עוד כשהייתי סטודנט, עבדתי במשרת סטודנט בצוות שנקרא אז צוות בקרת תצורה (CM team). תפקידי הצוות, שהיום מן הסתם היה נקרא צוות DEVOPS, כללו אחריות על source control, על ה-build, על תהליכי ההתקנה ועל ניהול מעבדה קטנה של צוות הפיתוח. בתור הסטודנט הכי צעיר – קיבלתי את התפקידים שאף אחד אחר לא רצה. כלומר את ניהול המעבדה.

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

diskdrives

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

הצורך בסביבת ריצה זמינה

אבל אחד הדברים שלא השתנה הוא הצורך של מפתחים בסביבת ריצה זמינה. כולנו אוהבים לפתח על המחשב שלנו. יש לנו את כל הטריקים הקטנים, את ה-IDE או עורך הטקסט המועדף וכל מיני התאמות קטנות שאנחנו עושים בסביבת הפיתוח שלנו – לפעמים אפילו בלי לשים לב. הבעיה היא שהתאמה אישית כזאת לא תמיד טובה למוצר שלנו. המחשב שלנו משמש לעוד כל מיני צרכים מלבד פיתוח, יש עליו ישומי אופיס, מולטימדיה וכל מני דברים נוספים שאנחנו צריכים כי זה לא רק מחשב פיתוח, זה המחשב שלנו. אולי אנחנו מפתחים עליו גם מוצרים נוספים או עושים כל מני בדיקות ו"משחקים" בטכנולוגיות חדשות או "מריצים" רעיונות חדשים. כל זה גורם למחשב הפיתוח להיות מאד "מבולגן". מותקנים עליו המון דברים, גרסאות שונות של ג'אווה או רובי אחת ליד השניה. ספריות צד שלישי במגוון של גרסאות ועוד. זה טוב מאד לפרודוקטיביות שלנו וליצירתיות אבל קשה לסמוך על קוד שרץ בסביבה "מלוכלכת" כזו באותה מידה שאפשר לסמוך על קוד שנבדק בסביבה "נקיה" ונשלטת. אין איש DEVOPS שלא מכיר את התשובה הזו של מפתח ששבר את הבילד (או הבדיקות או, שומו שמיים, את סביבת היצור): ""אבל אצלי זה עבד…".

png;base64eb107b0c04464264

מחשב ״נקי״

היכולת להחזיק מחשב "נקי" זמין למפתח (ברור שלצוות ה-DEVOPS יש build servers וסביבות בדיקה נקיות אבל אני מדבר פה על הצרכים של המפתח עצמו). שמותקן עליו בדיוק מה שהמוצר צריך ורק מה שהמוצר צריך נותנת ערך גבוה מאד למפתח. עדיין אפשר לראות בהרבה מקומות שני מחשבים ואפילו יותר מתחת לשולחן של כל מפתח לצורך זה בדיוק. גם כאן הוירטואליזציה נותנת, מן הסתם, פתרונות הרבה יותר טובים. ראשית כל, סביר להניח שיהיה יותר זול להחזיק פחות מכונות. שנית אתה מקבל את כל היתרונות של הוירטואל. קל מאד לעבור מסביבה לסביבה (בעיקר כשאתה צריך לתמוך במטריצה גדולה של קונפיגורציות), אפשר לשמור snapshots של סביבות במצבים שונים ולחזור אליהם כשצריך ועוד…

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

לא רק אפליקציה אלא כל התשתית התומכת

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

בניהול של סביבות וירטואליות כאלו קיים מתח בין ניהול של תצורות וירטואליות (Images) לניהול של תהליכי התקנה חיצוניים. במילים אחרות: איזה חלק מהתוצאה הסופית אני מתקין מראש ושומר כ-Image (לאחרונה רווח המונח Box) ואיזה חלק מותקן על המכונה הוירטואלית אחרי שהיא עולה (עדיף, כמובן, בצורה אוטומטית). במקביל להתפתחות של כלי ניהול וירטואלים שמאפשרים לייצר "קופסאות" בקלות יחסית, להפיץ אותם, להרים ולהוריד אותם על שרת הוירטואליזציה וכדומה, חלה התפתחות רבה בכלים שממדלים, מנהלים ומאפשרים אוטומציה של תהליכי ההתקנה כדוגמת chef ו-puppet.

במתח הזה אין תשובות חד משמעיות וסביר להניח שלכל פרויקט ולכל איש DEVOPS יהיו את ההעדפות שלו. אישית, אני חסיד של הגישה שטוענת ש:"הכל הוא קוד". אני מעדיף, בדרך כלל, לעבוד עם קופסאות מינימליות (JEOS – Just Enough Operating System ) ולתת ל-chef לעשות את רוב העבודה. הסיבה היא שאני מעדיף לנהל קוד על פני קופסאות שחורות בינאריות. קוד אפשר לשים ב-git, קל יותר לנהל לו גרסאות, לעקוב אחרי התפתחויות ישנות, להשוות גרסאות, לנהל ענפי פיתוח וכדומה. יתרון נוסף, ולא פחות חשוב, הוא היכולת לעשות שימוש בקוד קיים, להיעזר בקהילה ובספריות צד שלישי. ולבסוף, (ומצאתי שנוטים לזלזל ביתרון הזה שלא בצדק) קוד, בעיקר אם הוא כתוב היטב ובניגוד לקבצי Image, ניתן לקרוא. אפשר לעבור עליו ולהבין את הסביבה שלך גם כשהיא למטה.

Screenshot

סביבה נקייה במחשב מלוכלך

אבל השלב האחרון במהפכה הוא, בעיני, המעניין ביותר. הכוח של המחשבים, כולל לפטופים, מצד אחד והיכולת להתקין בקלות מנוע וירטואליזציה על תחנת העבודה (מנועים כדוגמת virtual-box, vm-player ואחרים) מאפשרים למפתח לקבל את סביבת הריצה הנקייה, המנוהלת והמוגדרת היטב  – אצלו על המחשב. בלי להשפיע או להיות מושפעת מכל ה"זבל" שמותקן, כאמור, על המחשבים שלנו. מהרגע שהשתדרגתי למחשב חזק מספיק – אני מוצא את עצמי מנהל ארגון IT בזעיר אנפין בתוך ה-virtual-box שלי. מתקין מכונות, מקנפג רשתות, מעלה, מוריד, מחסל. כל החגיגה. כאן נכנס לפעולה אחד הכלים המועילים והמגניבים שיצא לי לפגוש לאחרונה – vagrant.

vagrant הוא למעשה סוג של מחולל. הוא קורא קובץ מרכזי אחד שמתאר את סביבת הריצה הוירטואלית שלי. ויודע להביא את ה-Image, להתקין אותו במנוע הוירטואלזיציה (כרגע נתמכים virtual-box ו-vmware) להרים, להוריד, להרוס, ליצור מחדש ועוד. במילים אחרות – כל מה שהייתי עושה בממשק הניהול של מנוע הוירטואליזיה (כולל פעולות מתקדמות כמו הגדרת רשתות, שירשור פורטים וכדומה) אני כותב ב-descriptor אחד שנשמר לי כקובץ טקסט (git, גרסאות, ענפים, השוואות, לקרא ולהבין … זוכרים) ומאפשר לי לשמור על אחידות גם ברמה הזו (קובץ שיופץ למפתחים אחרים ירים בדיוק את אותה סביבה אצל כל אחד) קובץ התיאור שנקרא (במפתיע) Vagrantfile הוא אמנם תיאורי במהותו אבל הוא כתוב ברובי כך שהוא קריא למדי.

יחד עם סט הולך וגדל של plugins – הכלי הזה נראה יותר ויותר טוב. התכונה החשובה ביותר ב-vagrant לטעמי היא החיבור הטבעי שלו ל-chef (וגם ל-puppet אם כבר מדברים). ב-Vagrantfile ניתן להגדיר את chef בתור provisioner ולהגדיר רשימות ריצה וענייני chef נוספים. הגדרה כזו מאפשרת לחבר את ה-Vagrantfile לפרוייקט chef שמתאר ומתקין את סביבת הריצה, להגדיר בו את הbox שהכנו מראש (או להשתמש באחת מתוך עשרות קופסאות קיימות שהקהילה משתפת) ולקבל מגוון מרשים של יכולות וגמישות. אפשר להרים סביבה נקייה, לבדוק תהליכי התקנה של האפליקציה וכשמשהו לא מצליח – זורקים ומתחילים מהתחלה. ה-Vagrantfile יכול להיות עשיר מאד ולהחזיק תיאור של מספר מחשבים עם יחסי הגומלין ביניהם, רשתות וכדומה. לאחרונה הוסיפו ב-vagrant תמיכה גם ב-AWS של אמזון. התמיכה הזו מאפשרת לשכפל את המערכות שרצות בסביבת הוירטואליזציה הפרטית שלי גם בענן האמזוני ולנהל את האחידות בעזרת קובץ descriptor אחד.

logos1

לסיכום

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

המעבר לוירטואליזציה מקומית ושימוש בשילוב החזק של ה-power-couple – chef & vagrant  לאוטומטיזציה וחילול של סביבות וירטואליות על מכונת הפיתוח מאפשר למפתח להנות משני העולמות, לעבוד על המחשב האישי שלו ולראות את הקוד רץ בסביבה "אמיתית" בקלות, במהירות ובאחידות עם שאר המפתחים, צוותי הבדיקות והיצור. סביבת פיתוח כזו מחזקת גם את ההכרות של המפתח עם התשתיות עליהן רצה האפליקציה שהוא מפתח ובמקום בו ישנם גם צורך וגם גישה – שותפות של המפתחים בהגדרה וב"פיתוח" סביבת הריצה היא מבורכת ותקדם את הפריוקט ללא ספק.

אם הגעתם עד לכאן הפוסט כנראה עניין אתכם. רוצים לשמוע עוד? הצטרפו לקבוצת המיטאפ: Full Stack Developers Israel, בה תוכל להמשיך ולהעמיק את הידע בנושא זה ואחרים ע"י טובי המומחים. יתכן ותמצא עניין באירוע הקרוב שיערך ב-28.11.13 בנושא :Chef and Vagrant: The DevOps Perfect Couple.

קרדיט תמונה: servers via Shutterstock.

הכתבה בחסות Tikal

הכתבה בחסות Tikal

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


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


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


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


טיקל היא נותנת החסות לקבוצת המיטאפ : Full Stack Developers Israel. קבוצה זו מתמקדת באתגר החדש של כל מפתח, לשלוט בכל שכבות האפליקציה והפיתוח: front-end, back-end, database/store, infrastructure and server operation.

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

Tikal

צוות המומחים של טיקל יעזרו לכל צוות פיתוח לסיים כל משימת פיתוח בזמן ובאפקטיביות גבוהה. החל מהתאמה ומעבר לטכנולוגיות חדשות, דרך תכנון ובניית פרוייקטים ואופטימיזציה בתחומי: JAVA, Javascript, Ruby, ALM & .NET

הגב

1 תגובה on "על מגרות, סביבות ריצה וה-"power-couple of devops""

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
יונתן שקד
Guest

בהיר, מדויק, קולח. אהבתי.

wpDiscuz

תגיות לכתבה: