הגדרת Buildah לבניית אימג'י OCI ללא Docker

Buildah: בניית תמונות OCI ללא דמון וללא הרשאות סופר-משתמש

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

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

Buildah מסיר את התלות הזו: בנייה של תמונות OCI ללא Docker מתבצעת בתהליכים נפרדים בלי דמון ארוך-חיים, ולכן אין צורך לא להעביר socket ולא להחזיק בצומת שירות מיוחס שפועל תמיד.

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

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

מה נותנת בנייה של תמונות ללא דמון מיוחס

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

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

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

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

היכן Buildah מתאים: השוואת מצבי בנייה

Buildah בונה תמונות OCI ישירות, בלי דמון שפועל ללא הפסקה, ולכן אפשר להריץ את אותו Containerfile במצבים שונים — במכונת המפתח, בצומת הבנייה של ה-pipeline או בתוך סביבה מבודדת. הם נבדלים לא בתחביר, אלא בהרשאות, בגישה לרשת ובמי שאחראי על ניקיון המאגר המקומי. בדיוק משום כך בוחרים את המצב לפי המשימה, ולא ״בעין״.

הקו המנחה הוא כזה: אם החזרתיות חשובה, ה-Containerfile רץ ב-pipeline במצב rootless, והבנייה המקומית נשארת כלי לדיבוג. בידוד מתאים במקום שבו תמונת הבסיס מגיעה מבחוץ או שהסביבה צריכה להיות נעולה לפני ה-pin.

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

איך מתבצעת הטמעת הבנייה על Buildah

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

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

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

ערכת מסירה: תיאורי בנייה, תפקידים, תקנונים

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

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

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

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

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

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

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

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

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

במה נבדלת בנייה ללא דמון מבנייה קלאסית?

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

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

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

ספקות של מהנדסים: מטמון, registries פרטיים, תאימות

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

מה עושים עם registries סגורים?

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

האם מטמון השכבות יישמר בין בניות?

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

האם התמונה תיבנה לכמה ארכיטקטורות?

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

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

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

• תיאורי בנייה וסקריפטים: Dockerfile פעילים, entrypoint, שלבי משימות — מהם רואים אילו הוראות מפסיקות לעבוד בבנייה ללא דמון.
• registries יעד והרשאות: כתובות המאגרים, חשבונות נפרדים לקריאת שכבות בסיס ולכתיבת התוצאה, דרישות לחתימת תמונות.
• מטריצת פלטפורמות: לאילו ארכיטקטורות בונים והאם נדרשת בנייה רב-ארכיטקטונית — בצומת אחד או מבוזרת.
• תמונות בסיס: מקורות מותרים ומראות פנימיות, דרישות להרכב חבילות מינימלי ולעדכון חולשות.
• סביבת בנייה: runners ללא הרשאות root, גישה לרשת, מגבלות CPU ודיסק, דרישות למטמון שכבות בין הרצות.
• מדיניות תגים ואחסון: סכימת ניהול גרסאות, כללי ניקוי ה-registry, עומק ה-rollback ל-releases קודמים.
• סביבת פריסה: cluster או מארחים נפרדים, בדיקות תקינות, דרישות ל-rollback לגרסה הקודמת.

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