הגדרת מאגר Helm פרטי עם אוטומציה ו-ACL

מאגר Helm פרטי: היכן זה נשבר ומה הסיכון

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

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

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

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

האפקט של ההטמעה: מהירות ריליסים ויציבות הפריסה

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

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

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

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

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

השוואת מצבים: מטמון פרוקסי, מאגר מבודד, היברידי

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

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

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

סדר ההטמעה: מביקורת ועד מסירה לתפעול

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

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

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

הרכב האספקה: קונפיגורציות, סכימות ונהלי גישה

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

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

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

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

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

מה היה לפני

פריסת כל הסביבה ארכה כשלוש שעות והחזיקה מעמד על אדם אחד, שידע את סדר השירותים וזכר אילו צ׳ארטים קשורים זה לזה. ב-8 ריליסים מתוך 10 נשארו תיקונים ידניים, ופערים בקונפיגורציות בין סביבות יצרו 6–9 תקלות ברבעון. חזרה לגרסה הקודמת ארכה 40–50 דקות: את ארכיון הצ׳ארט הנדרש חיפשו ביומני הצינור ובהתכתבות.

מה קרה אחרי

פרסנו Helm Repository פרטי עם ACL לפי צוותים: פרסום מתבצע רק מהצינור לפי תג, הצ׳ארטים חתומים, ומדיניות מחזור חיים מחזיקה את הבנייות האחרונות לכל גרסה ראשית ומנקה את השאר — עם זאת, חזרה לריליס הקודם נשארת אפשרית. פריסת הסביבה התקצרה ל-12 דקות, תיקונים ידניים עברו לקטגוריית חריגים ועוברים סקירה כמו קוד רגיל.

במשך שני רבעים לאחר המעבר, פערי קונפיגורציה לא יצרו אף תקרית, וזמן שחזור הפריסה ירד מ-40–50 דקות ל-2.

מה לעשות אם כבר פרוס מטמון פרוקסי ציבורי

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

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

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

שאלות על מגבלות, מטמון והרשאות גישה

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

איך מפרידים הרשאות בין צוותים?

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

מה יקרה אם המאגר לא זמין?

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

נדבר על המשימה: מה צריך להערכה ולתוכנית הטמעה

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

מה אנחנו מבררים להתחלה:

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

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