הגדרת Docker BuildKit לאופטימיזציה של בנייה

בניית images נתקעת בדקות: היכן צוואר הבקבוק

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

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

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

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

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

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

קיצור זמן הבנייה החוזרת

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

בשירות טיפוסי הבנייה החוזרת מתקצרת מעשרות דקות לאחת-שתיים. לפי מדידות פומביות של Docker BuildKit, שיעור השכבות המנוצלות מחדש בהרצות חוזרות עולה על 80%. ככל שאתם מפרסמים לעיתים תכופות יותר, האפקט חזק יותר: ההמתנה לבנייה מפסיקה לעכב releases.

פחות פערים בין בנייה מקומית לבנייה בשרת

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

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

Docker BuildKit הגדרה: מצבי בנייה ומה לבחור

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

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

מגבלות המטמון המשותף בין ענפים

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

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

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

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

1. אודיט הבנייה. לוקחים ערכי בסיס: זמן בנייה מלאה ובנייה אינקרמנטלית, גודל ה-image, שיעור הצעדים שנפלו למטמון, ומה הכי часто מאפס אותו — סדר ההעתקה, התקנת תלויות אחרי הקוד, היעדר .dockerignore.
2. סכמת הבנייה: שכבות ושלבים. מפרקים את התהליך לשלבים, מגדירים בסיס משותף, מקומות למינוט המטמון של מנהלי החבילות ושכבות ששורדות בנייה מחדש בלי שינויים.
3. הגדרת executors הבנייה וההרשאות. מחליטים היכן רץ ה-daemon — על צומת ייעודי, בתוך container או במצב ללא הרשאות root — ומעניקים הרשאות מינימליות מספקות ל-registry.
4. הפעלת המצב. מתקנים את קונפיגורציית ה-daemon ואת קובץ הבנייה, מגדירים ייצוא המטמון ל-registry, כדי שינוצל מחדש לא רק על מכונה אחת.

בדיקת התוצאה על מאגרים בייצור

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

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

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

• קובץ קונפיגורציית הבנייה — מצבים מופעלים, מגבלות מקביליות, מדיניות מטמון; לכל פרמטר יש הערה מדוע נבחר דווקא הוא.
• סכמת השכבות והצעדים — מה נכנס לשכבה משותפת, מה נבנה מחדש בתיקון קוד, והיכן עוברים גבולות המטמון ומדוע.
• כללי גישה לאחסון ה-images — תפקידים, תוחלת חיים של פרטי הזדהות, מי רשאי לפרסם, לדרוס tag ולמחוק images.
• תיאור המגבלות — מה הבנייה במכוון אינה עושה ואילו תנאים שוברים אותה, כדי שהצוות לא יצפה ליותר מדי.
• נוהל הוצאה — הרצף מהקומיט ועד ה-image המוכן, נקודות הבדיקה ותנאי העצירה.
• הוראות לשחזור הבנייה — כיצד להרים אותה מאפס בעת אובדן המטמון, מהיכן מגיעות שכבות הבסיס, וכיצד לחזור ל-image הקודם.
• checklist קבלה — מכלול בדיקות שלפיהן תיקון הקונפיגורציה נחשב בטוח.
• מפת העברת הידע — תיעוד של ישיבת הפענוח עם הצוות והתשובות לשאלות שעלו במהלכה.

מה הצוות יוכל לשנות בעצמו

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

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

מקרה בוחן: זמן הבנייה קוצר פי כמה, כשלי הפריסה נעלמו

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

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

מה נעשה בתוך תהליך הבנייה

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

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

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

מה לעשות אם הבנייה כבר עובדת ואסור לשבור אותה?

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

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

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

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

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

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

מגבלות, תאימות ושאלות טכניות אופייניות

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

אילו דרישות יש ל-executors ולשרתי הבנייה?

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

האם יהיה צורך לשכתב את סקריפטי הבנייה?

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

מה עם בידוד הנתונים וההרשאות?

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

כיצד לחזור אחורה אם משהו ישתבש?

ה-rollback הוא החזרת שיטת הבנייה לקדמותה, הגדרה אחת בקונפיגורציית ה-executor. ה-images ב-registry אינם נדרסים, ולכן ה-release הקודם נשאר זמין ונפרס בדקות.

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

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

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

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