CI/CD עבור Helm Charts: lint אוטומטי, בדיקות ופרסום

למה CI/CD Helm Charts נשבר בעריכות ידניות

פרסום ידני של צ'ארטים נראה בטוח כל עוד יש מעט תיקונים. מהנדס אחד עורך values.yaml בענף שלו, השני — דרך לוח הבקרה של הסביבה, השלישי מוסיף מניפסט ישירות באשכול, רק כדי "להעלות מהדורה".

אחרי כמה שבועות אף אחד מהשינויים האלה לא משוחזר מאפס: ההיסטוריה של מה שבאמת נשלח לסביבה לא נשמרת בשום מקום.

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

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

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

מה נותנת אוטומציה של ההוצאה: אפקט מדיד

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

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

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

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

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

אפשרויות לארגון ההוצאה: השוואת גישות

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

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

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

שלבי יישום הוצאה אוטומטית של תבניות

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

1. ביקורת תהליך ההוצאה. אוספים רשימת צ'ארטים והתלויות שלהם, מתעדים צעדים ידניים ומקומות שבהם הגרסה במאגר חלוקה מגרסת קובצי המקור.
2. סכימת סביבות. מגדירים סט סביבות — בדיקות, קדם-ייצור, ייצור — ואיך בכל אחת מוצבים הערכים. התבניות נשארות משותפות, וההבדלים עוברים לקבצי ערכים.
3. הגדרת בדיקות לפני פרסום. לצינור מוסיפים ניתוח סטטי של תבניות, רינדור מניפסטים עם אימות ערכים וסכימה, בקרת גרסה והיסטוריית שינויים.
4. תרגול בסביבת בדיקות. הצ'ארט הבנוי מותקן באשכול מבודד ועובר מחזור מלא: התקנה, עדכון, חזרה לאחור, מחיקה. כאן נתפסות שגיאות שהופיעו בעבר בסביבת הייצור.
5. פרסום וניהול גרסאות. מחברים מאגר, קובעים כללי שמות לגרסאות ומדיניות שמירת ארטיפקטים, כדי שהחזרה למהדורה קודמת תישאר זמינה.
6. מסירה לצוות. נוהל הוצאה, ניתוח כשלים שגרתיים והדרכת מהנדסים — מהדורה לא צריכה להיות תלויה באדם אחד.

לאחר מכן ההוצאה הופכת לפעולה חוזרת: צ'ארט עם שגיאה פשוט לא יגיע למאגר.

ערכת הגדרות, סכימות ונוהלים לתחזוקה

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

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

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

מקרה בוחן: מבנייה ידנית לפרסום אוטומטי

איך הוציאו קודם

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

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

מה השתנה

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

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

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

במה מהדורת Helm שונה מבנייה רגילה

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

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

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

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

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

ספקות טכניים נפוצים לגבי אוטומציה של ההוצאה

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

איך להבין ששינוי בצ'ארט הוא בטוח?

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

האם נוכל לתחזק את זה בכוחות עצמנו?

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

איך מאובטח פרסום הצ'ארטים?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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