הגדרת בנייה אוטומטית של תמונות Docker ב-CI/CD

בנייה אוטומטית של תמונות Docker: היכן התהליך נשבר

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

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

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

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

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

מה משתנה לאחר העברת הבנייה לצינור

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

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

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

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

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

היכן להריץ את הצינור: סוכנים, קונטיינרים, שרתים משלכם

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

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

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

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

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

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

מה נשאר במאגר ובצוות לאחר ההטמעה

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

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

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

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

מה נשבר לפני

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

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

מה שינו ומה קיבלו

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

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

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

במה נבדל מטמון שכבות ממטמון תלויות

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

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

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

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

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

ספקות טכניים לפני מעבר לצינור

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

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

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

היכן נשמרים סודות הבנייה?

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

האם הפריסה תיעצר בזמן המעבר?

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

למה הצינור נפל אצלנו לעתים קרובות בעבר?

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

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

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

כדי לחזור עם הערכה ותוכנית הטמעה, בדרך כלל נדרש מהמזמין:

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

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