Cloud Native Buildpacks: קונטיינריזציה אוטומטית ללא Dockerfile

Cloud Native Buildpacks: היכן נשברת בנייה ידנית של אימג'ים

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

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

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

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

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

מה נותנת בנייה של אימג'ים בלי Dockerfile בפועל

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

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

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

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

השוואה בין גישות לבניית אימג'ים של שירותים

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

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

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

איך עובר יישום בנייה אוטומטית

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

1. מלאי שירותים. אוספים רשימה של מאגרים, שפות, גרסאות runtime ומסמנים כל מה שלא נגזר אוטומטית: חבילות מערכת שהותקנו ידנית, נקודות כניסה לא סטנדרטיות, קבצי קונפיגורציה שנוספים בשלב הבנייה. התוצאה — טבלת «שירות / מה להעביר / בעלים».
2. הכנת אימג' בונה. מקבעים את אימג' הבסיס, סט הסטאקים הנתמכים וגרסת מנגנון מחזור החיים. למקרים נדירים (בינאריים קנייניים, תלויות לא סטנדרטיות) מוסיפים buildpack או הרחבה משלנו במקום לערוך קוד זר.
3. העברת חוקים מ-Dockerfile לקונפיגורציה. משתמש ללא root, נקודת כניסה, משתני סביבה, תגיות אימג' ובדיקת חיות מתוארים דקלרטיבית. הבנייה מפסיקה להיות תלויה במי שערך את ה-Dockerfile אחרון.
4. הגדרת בנייה בצינור. מפעילים מטמון שכבות בין הרצות, חזרתיות לפי אימג' בונה מקובע, חתימת תוצאה והפקת רשימת רכיבים — בלי צעדים ידניים בסוכן הבנייה.
5. בדיקה בסביבת סטנד. משווים את האימג' החדש לקודם לפי זמן בנייה, גודל, מספר ממצאי סורק פגיעויות וזמן עליית קונטיינר; מריצים בדיקות עשן ובדיקת מיגרציות.
6. העברה הדרגתית של שירותים. קודם צוות אחד-שניים, נסיגה — לאימג' הקודם לפי תג. את השאר מעבירים לפי מוכנות, בלי לעצור את מחזור השחרורים.
7. מסירת תקנון תחזוקה. מתעדים עדכון אימג' בונה, סדר חיבור שירות חדש, תחומי אחריות וחוקי נסיגה.

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

הרכב חומרי המסירה והתקנונים

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

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

מקרה בוחן: מעבר ל-buildpacks עבור 40 שירותים

מה היה לפני המעבר

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

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

מה שינו ומה נהיה

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

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

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

במה בנייה מהמקור שונה מבנייה מאימג'?

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

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

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

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

מצב ידני נשאר במקומות שדורשים תלויות מערכת לא סטנדרטיות או סדר הכנה משלהם לסביבה; חלק מהמקרים האלה נסגר על ידי חיבור קובץ בנייה מוכר כאחד משלבי הבנייה האוטומטית.

שאלות טכניות: מטמון, הרשאות, נסיגת בנייה

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

איך בונים עם תלויות פרטיות בלי לגרור סודות לתוך האימג'?

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

באיזה משתמש עולה הקונטיינר והאם אפשר לשנות זאת?

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

איך חוזרים לסכמת בנייה קודמת אם משהו לא מתאים?

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

נדון במשימת בניית האימג'ים שלכם

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

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

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