הגדרת מדיניות תמונות בסיס (Base Image Policy)

מדיניות תמונות בסיס: מה נשבר בלעדיה

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

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

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

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

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

אפקט מדיד: זמן בנייה ויציבות סביבות

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

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

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

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

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

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

מצבי עדכון ובקרת גרסאות של תמונות

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

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

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

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

שלבי הטמעה: מביקורת המאגר ועד לנוהל

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

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

לאחר מכן הכלל חי בתהליך הבנייה, ולא בהוראה: הפרה נראית מיד, ולא בניתוח תקרית.

נהלי עדכון, תרשימים ומפת תלויות

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

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

מקרה בוחן: איך הסרנו סטיות בין סביבות והאצנו את היציאה

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

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

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

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

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

במה שונה הצמדה קשיחה ממצב המלצה?

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

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

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

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

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

ספקות טכניים: סריקה, חתימות, תאימות

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

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

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

סריקת פרצות לא תאט את הצינור?

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

איך לחזור אחורה אם הבסיס החדש שובר את הגרסה?

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

נדבר על המשימה: ביקורת המאגר ותוכנית הטמעה

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

לצורך הערכה מספיק לצרף:

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

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

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