conf files in or out
ישנן 2 גישות להיכן להחזיק קבצי קונפיגורציה הגישה השמרנית והגישה המהירה\פרקטית, בתור אנשי DEVOPS אנו כל הזמן נדרשים לשקור את המהירות מול היציבות של המערכת.
לכל גישה ישנן יתרונות וחסרונות ואין תשובה נכונה, כל מקרה צריך להיות נידון לגופו, במאמר זה ננסה להציג את ההבדלים בין הגישות והיתרונות והחסרונות\סיכונים של כל גישה.
במאמר זה לא נסקור את הטכניקות ליישום כל גישה ולכן נתייחס לטכניקות בסיסיות ליישום בשביל קלות הדיון, לא נתייחס גם לאבטחת מידע, שמירת סיסמאות וכו.
נתחיל בהסבר קצר על הגישות ולאחר מכן נסקור כל גישה לעומק
הגישה השמרנית – קבצי קונפיגורציה כגון קבצי .env או appconfig למינהם הם חלק אינטגרלי מהבילד, כאשר הם שונים בין סביבה לסביבה, אבל עדיין חלק מהבילד, כלומר עבור סביבת QA נצטרך להריץ בילד מלא, ואותו דבר עבור סביבת PROD . כל סביבה תקבל בילד מלא משלה. במהלך הבילד יוצמדו לפי הסביבה קבצה הקונפיגורציה של אותה סביבה. אך ה IMAGE של הבילד יכלול את קבצי הקונפיגורציה ולא ניתן להפריד בינהם.
הגישה הפרקטית – קבצי קונפיגורציה הם לא חלק מהבילד, הבילד הוא המערכת בלבד וקבצי הקונפיגורציה יגיעו עם עליית המכונה\קונטיינר בצורה מרוחקת על ידי פקודות עליה (entrypoint) לפני זמינות המכונה. כך כל הסביבות מכילות את אותו הקוד עם אותו ה IMAGE והקבצי קונפיגורציה נטענים בעליה. כלומר סביבת QA מאושרת מאפשרת העלאה של ה IMAGE לסביבת PROD ללא צורך לבנות בילד חדש.
יתרונות וחסרונות של השיטה השמרנית
יתרונות השיטה השמרנית כשמה כן היא, היא שמרנית יותר, בגלל שבילד מורכב מכל החלקים שלו, ואין בו חלקים משתנים ה IMAGE קבוע ואינו משתנה, כלומר מיזערנו בצורה משמעותית את הסיכונים לבעיות בבילד הזה. בילדים בשיטה השמרנית יציבים יותר ועם פחות תקלות.
החסרון המשמעותי של השיטה הזו הוא התקורה בשינוי קונפיגורציה, שינוי קונפיגורציה או הוספת שורת קונפיגורציה משמעותה בילד מלא, על כל המשתמע מכך, גירסה מלאה לרבות בדיקות וניהול סיכונים של גרסה. המשמעות העיקרית היא הרבה זמן ומשאבים לשינוי “מינורי”.
יתרונות וחסרונות של השיטה הפרקטית
היתרון המרכזי הוא מהירות, שינוי קונפיגורציה הינו שינוי מינורי, שינוי שיכול להתבצע ללא בילד , ללא כל ה”בירוקרטיה” הנדרשת בבניית בילד. מה שמאפשר לנו לשנות סיסה ל DB במעט מאוד זמן, או להוסיף קונפיגורציה ולבצע התאמות “תוך כדי ריצה”.
החיסרון המרכזי של השיטה הוא היתרון שלה, אנו מאבדים חלק משמעותי מה”בירוקרטיה” שמעניקה לנו יציבות, כאנשי DEVOPS המטרה העיקרית שלנו זה להעניק למערכת יציבות, והשיטה הזו רומסת את היציבות שבנינו מסיבה מאוד פשוטה, עיקר התקלות במערכת שלנו יגיאו מאדם, השיטה הזו מאפשרת לאדם אחד באירגון לבצע טעות קריטית מבלי ליידע אף אחד, וחלק משמעותי שצריך לתת לו מקום הוא שהטעות לא תמיד תצוף מיד, אלא הקריסה יכולה להגיע מספר ימים לאחר השינוי, כך שלא תהיה קורלציה טבעית בין התקלה למה שנעשה. לדוגמה הוספת שורת קונפיגורציה לגרסה עתידית, לא אמורה להשפיע על המערכת הקיימת, אך שברנו את קובץ הקונפיגורציה, רק הקונטיינר שיפול ויעלה במקומו קונטיינר חדש יציף לנו את הבעיה, מה שאומר שאם לא בוצעה החלפת קונטיינרים יזומה על ידי משנה הקונפיגורציה לא נדע על התקלה עד שהקונטיינרים שלנו יוחלפו וזה יכול לקחת מספר ימים באופן לא יזום.
לסיכום:
גישתי האישית לרוב נוטה לכיוון הגישה השמרנית, לעולם הבעיות הכי גדולות שלנו יגיעו מטעויות קטנות של אנשים, בגלל שזה נראה קטן וזניח יקח לנו הרבה זמן למצוא את התקלה, לכן במקרה הזה אני הולך לרוב על הגישה הבירוקרטית. נדירים המיקרים שאני מעדיף את הגישה הפרקטית, לרוב זה אצל לקוחות שיש להם ריבוי סביבות on prem כלומר מערכת אחת שמיושמת בתוך חוות של לקוחות רבים עם מתודולגיית עדכון מערכת פנימית של כל לקוח.
יגאל אלון 114, תל אביב
