מדוע Docker Registry פרטי נשבר עם צמיחת הצוות
כל עוד האימג'ים נמשכים ממקור ציבורי, הפריסה תלויה בשירות של מישהו אחר. מגבלות ההורדה של אימג'ים מופעלות ברגע הכי לא מתאים — כשכמה ענפים נבנים במקביל והסוכנים מבקשים בבת אחת את שכבות הבסיס. הבנייה לא נופלת מיד: היא מאטה, חלק מהשלבים נופלים בזמן קצוב, וצריך להפעיל מחדש את הפייפליין ביד.
הכשל השני שקט יותר ולכן יקר יותר. תגיות נדרסות, ומתחת לאותו שם בסביבות שונות מופיעים בתים שונים: הבודק בודק לא את מה שהריליס יבנה. חוסר הסנכרון של אימג'ים בין הסביבות אינו נראה בלוגים, הוא ניכר בתקריות — ״בבדיקות זה עבד, בפרודקשן לא״. יכולת השחזור של הבנייה אובדת, כי אף אחד לא יודע מה בדיוק נמצא באימג'.
בהמשך נשבר גם הרולבק של הריליס לפי אימג'. כל עוד השכבות הדרושות נמצאות במטמון המקומי של הסוכן, הכול מחזיק מעמד; במעבר של סוכן או דריסה של תגית, הגרסה הקודמת פשוט לא קיימת. נשאר לבנות מחדש את הקומיט הקודם מהזיכרון ולקוות שהתלויות יימשכו באותן גרסאות.
המשמעות — שעות של השבתה לצוות וחלונות ריליס שאבדו. זה לא מתוקן במשמעת, אלא בהחלפת נקודת האחסון: מאגר אימג'ים משלכם עם תגיות בלתי משתנות, הפרדת הרשאות ובדיקת אימג'ים לפני הפריסה. נסביר איך סוגרים את זה.
מה נותן מאגר אימג'ים מנוהל
נקודת חלוקה אחודה לאימג'ים מסירה את הסיבה העיקרית לפערים בין הסביבות. Docker Registry פרטי מרכז ארטיפקטים במקום אחד: היישום נבנה פעם אחת, ומכאן כל הסביבות — פיתוח, בדיקות, פרודקשן — מקבלות את אותה שכבה בלתי משתנה.
הוויכוח ״אצלי זה עובד״ נגמר, כי אין מה להשוות: מזהה הארטיפקט זהה בכל הסביבות, ולא נבנה מחדש בכל מכונה.
מטמון שכבות לצד משאבי המחשוב מקצר את זמן הפריסה של הריליס. שכבות בסיס נמשכות פעם אחת, בעת עדכון היישום מועבר רק החלק שהשתנה, והפריסה מפסיקה להיות תלויה בזמינות של מאגרים ציבוריים. האפקט האופייני — הפריסה מתבצעת בכמה דקות במקום עשרות, והצוותים מפסיקים לשכפל תעבורה בבניות מקבילות.
בקרת גרסאות נשענת על מדיניות תגיות: ריליס מקבל תווית בלתי משתנה, ותגיות מתחלפות נסגרות לכתיבה, כדי שמתחת לאותו שם לא יימצא ארטיפקט אחר. מכאן צומח רולבק בר-שחזור — חזרה לריליס הקודם נעשית בהחלפת תווית ואורכת דקות, בלי בנייה מחדש ובלי לחפש את הבנייה הדרושה בקטלוג של מישהו אחר.
סריקה בזמן העלאה ולפי לוח זמנים משנה את תמונת הפגיעויות: המדיניות לא מכניסה לפרודקשן אימג' עם ממצאים קריטיים, ולכן שיעור הארטיפקטים עם פגיעויות ידועות יורד, ולא עולה יחד עם מספר השירותים.
מודל הרשאות מבוסס תפקידים מוסיף סדר: הצוות רואה ומפרסם רק את הפרויקטים שלו, הפעולות נרשמות ביומן, וההרשאות מבוטלות עם עזיבת העובד.
אפשרויות אחסון אימג'ים: השוואת מודלים
הבחירה באופן אחסון האימג'ים קובעת שני דברים: כמה מהר הצוות חוזר לריליס הקודם וכמה צפויה הגדילה של המאגר עצמו. ההבדלים בין האפשרויות אינם בחומרה, אלא במי שאחראי לזמינות, לעדכונים, להרשאות גישה ולניקוי תגיות ישנות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מאגר מקומי על חומרה שלכם | הנתונים לא צריכים לצאת מהסביבה שלכם; יש מכונות משלכם ומהנדסים שמוכנים לתחזק את השירות | עדכונים, גיבויים ומקום בדיסקים — באחריותכם; כשל של צומת עוצר בניות עד להקמת מופע שני |
| מאגר מנוהל בענן | הצוות מפוזר, אין רצון להחזיק תשתית; צריך התחלה מהירה וגישה מרשתות שונות | הגדרת הרשאות וסריקה מוגבלות ליכולות הספק; נפח המאגר ומספר הפניות דורשים משמעת בניקוי |
| סכימה היברידית עם שכפול | הבנייה מתבצעת בתוך הרשת, והחלוקה לאתרים חיצוניים; צריך גם מהירות וגם זמינות | שתי נקודות אחסון: חוסר סנכרון תגיות בעת כשל בשכפול, קשה יותר לנתח תקריות, נדרשת מדיניות ״מי המקור״ |
המגבלות בכל שלושת המצבים מופיעות באותו אופן: נגמר המקום או נפל צומת — הבניות נעצרו, ואין לאן לחזור. לכן לצד המאגר מגדירים מיד תפקידים ותחומי נראות, ולא נותנים לצוות גישת כתיבה משותפת.
בהמשך נסביר איך זה נסגר ב-Harbor: הפרדת הרשאות לפי פרויקטים, סריקה אוטומטית של אימג'ים בזמן העלאה וכללי ניקוי לפי תגיות.
שלבי הטמעה: מאודיט ועד מסירה
העבודה מתבצעת בסדר שבו המאגר מופעל בלי לעצור פריסות קיימות: קודם מתעדים מה כבר קיים, אחר כך מתכננים אחסון והרשאות, ורק לאחר מכן מעבירים אימג'ים.
- אודיט של פייפליינים לבנייה ומיפוי אימג'ים. אילו שירותים נבנים, מאיפה מגיעות שכבות הבסיס, מי ואיך דוחף, כמה תגיות חיות במאגר הישן. התוצאה — רשימת מאגרים וכלל שמות אחיד.
- סכימת המאגר. פרויקטים ומכסות, מדיניות מחזור חיים (כמה תגיות מחזיקים, מתי מנקים), מיקום האחסון ושכפול. את הסכימה מתאמים לפני הפריסה, אחרת יהיה צריך להעביר נתונים שוב.
- פריסה וחיבור. מקימים Harbor בקונפיגורציה עמידה בכשלים, מגדירים TLS, אינטגרציה עם ספריית המשתמשים הארגונית וגיבוי.
- הרשאות גישה. תפקידים לפי פרויקטים, חשבונות שירות נפרדים לפייפליינים, הפרדה בין קריאה לכתיבה, גישה אנונימית סגורה.
- העברת אימג'ים. מעבירים תוך שמירה על digests ובדיקת שלמות — אין צורך לבנות מחדש דבר, הפריסות לא נפסקות.
- בדיקת פריסה. מריצים בניות ופריסות אמיתיות: סריקת פגיעויות, מדיניות חסימה של ממצאים קריטיים, חזרה לתגית הקודמת.
- מסירת המאגר לצוות. נהלים, סכימה, סדר שחזור והדרכה על סביבה חיה — מכאן הצוות מנהל את המאגר בעצמו.
קונפיגורציות של Registry, מדיניות גישה ונהלים
אחרי ההטמעה נשאר לצוות הלקוח לא רק מאגר עובד, אלא גם סט מלא של ארטיפקטים שלפיהם אפשר לפתח ולתחזק אותו בלעדינו. קובצי הקונפיגורציה נשמרים ב-git לצד מניפסטים של פריסה, ולכן ההבדלים בין הסביבות נקבעים בערכים, ולא בעריכה ידנית של תבניות. מה בדיוק מוסרים:
- קונפיגורציות של המאגר: פרמטרי אחסון, חיבורים חיצוניים, מגבלות גודל העלאה, בדיקות פגיעויות מופעלות ותקופות שמירה של שכבות.
- מדיניות גישה: כללים ברמת פרויקטים ומאגרים, דרישות לאימג'ים חתומים, איסור דריסה של תגיות בלתי משתנות.
- תפקידים והרשאות צוותים: מטריצת ״צוות — פרויקט — פעולה״, קישור לספריית המשתמשים הארגונית, חשבונות נפרדים לסוכני בנייה.
- נוהל עדכון אימג'ים: תדירות בנייה מחדש של שכבות בסיס, סדר הוצאת תיקוני אבטחה, האחראים לאישור.
- כללי ניקוי ושמירה: כמה אימג'ים אחרונים לכל תגית נשארים, מה יוצא מהמאגר אוטומטית, איך לשמר אפשרות רולבק.
- סכימת גיבוי: אילו מטא-נתונים וארטיפקטים מגובים, באיזו תדירות, איך נבדק שחזור בסביבה נפרדת.
- הנחיות לצוותים: איך לקבל גישה, איך לפרסם אימג', לאן לפנות בתקרית ואיך לקרוא דוח סריקה.
כל מסמך משויך לקובץ ולגרסה מסוימים, ולא מתאר מצב רצוי. המסירה מלווה בהרצה: פורסים את המאגר מאפס לפי החומרים האלה ומשווים את התוצאה לסביבת העבודה.
מקרה בוחן: איך קיצרנו את זמן הפריסה ומספר התקריות
הצוות תחזק כארבעים שירותים: הבנייה עברה בפייפליין של אינטגרציה רציפה, והאימג'ים נשמרו במאגר ציבורי בלי מדיניות גישה. הפריסה לסביבת בדיקות ארכה בממוצע 35–40 דקות, וחצי מהזמן הוקדש להצבת תגיות ידנית ולבניות חוזרות אחרי שגיאות לא ברורות.
בסביבות היו גרסאות שונות: המפתח דחף latest, הבודק הקים אימג' לא נכון, התורן לא הצליח להבין מהר מה בדיוק רץ עכשיו. פערים בין סביבות צפו שלוש־ארבע פעמים בשבוע, וניתוח תקרית עם אימג' — רולבק לגרסה הלא נכונה, ספרייה לא תואמת — ארך שעתיים־שלוש.
פרסנו מאגר פרטי על Harbor: פרויקטים לפי צוותים וסביבות, תפקידים ב-RBAC, חשבונות שירות נפרדים לפייפליין, תגיות בלתי משתנות וכלל שמירה שמנקה שכבות ישנות אך משאיר את הבניות האחרונות לרולבק.
סריקת פגיעויות מתבצעת בעת שליחת אימג', בנייה עם ממצאים קריטיים נחסמת עד לתיקון, וחריגה מוסדרת במפורש ולפרק זמן מוגבל.
אחרי שלושה חודשים: פריסה לסביבה — כשש דקות במקום ארבעים, כי הסביבה מושכת את האימג' לפי תגית בלתי משתנה. פערי גרסאות בין סביבות הצטמצמו לאפס. שיעור האימג'ים עם פגיעויות קריטיות ידועות ירד מ-22% ל-0.4% — נותרו מקרים בודדים שבהם העדכון תלוי בספק חיצוני. תקריות הקשורות באימג'ים לא נרשמו במשך שני רבעונים.
הרולבק עם זאת נשאר בשליטה: הבניות הדרושות נשמרות, יומן המאגר מראה מי ומתי שלח אימג', ולכן הניתוח אורך דקות ולא שעות.
מה לעשות אם מאגר אימג'ים כבר פרוס באופן ידני
אין צורך לבנות מחדש מאגר עצמאי עובד מאפס — מעבירים אותו לפלטפורמה מנוהלת תוך שמירה על כתובות החלוקה הקודמות של האימג'ים. מתחילים במיפוי: בלעדיו ההעברה הופכת לניסוי תגיות באקראי. אחר כך — מעבר מדורג שבו הפריסות לא נעצרות.
מיפוי האימג'ים מבוסס על עובדות, לא על רשימה בראש של מהנדס: המאגר מחזיר רשימת מאגרים ותגיות, ומשווים אותה ליומני פניות, לקישורים בקונפיגורציות של אשכולות ולשלבי בנייה.
בתוצאה רואים אילו אימג'ים נמשכים על ידי סביבות פרודקשן ובדיקות, אילו משכפלים זה את זה בשכבות, ואילו לא התבקשו אף פעם. בדרך כלל חלק ניכר מהתגיות מתגלה כנטל — וזה מיד קובע את היקף העבודה האמיתי.
העברת מאגר קיים נעשית בתקופת עבודה כפולה: Harbor מורם לצידו, מגדירים פרוקסי לכתובת הישנה, והוא נשאר המקור עד שהצרכן האחרון עובר. בניות מועברות לחשבונות שירות המוגבלים לפרויקט שלהן, ומפתחות משותפים מבוטלים עם התקדמות המיגרציה — מעבר חלק בלי חלון השבתה.
הרשאות ואחסון מסדרים מיד: פרויקטים לפי צוותים, תפקידים מ״קריאה בלבד״ עד מנהל מאגר, סנכרון עם ספריית משתמשים, מכסות וכלל שמירה — עשר התגיות האחרונות לכל מאגר, תגיות ריליס בלתי משתנות.
תגיות מדור קודם לא מוחקים בלי בדיקה: מכבים אותן לפי מדד הפניות, והשכבות שהתפנו נאספות על ידי אוסף אשפה.
ספקות טכניים נפוצים במעבר למאגר משלכם
הספק העיקרי במעבר ממאגר חיצוני הוא לא ״איך להגדיר״, אלא ״מה יקרה כשהוא יפסיק להגיב״. להלן תשובות ישירות על זמינות, כתיבה מחדש של פייפליינים לבנייה ואחריות לאחר המסירה.
מה יקרה אם המאגר לא יהיה זמין?
קונטיינרים פרוסים ממשיכים לעבוד: האימג' כבר נמצא על הצומת, וההפעלה מחדש נעשית מהמטמון המקומי. את המאגר מחזיקים בשני מופעים באתרים שונים, והמצב — באחסון משוכפל. כשל של מכונה אחת לא עוצר בניות ופריסות, ובדיקת זמינות מוציאה את הצומת מאיזון בעצמה.
האם יהיה צריך לכתוב מחדש פייפליינים לבנייה?
לא. כתובת המאגר ופרטי הגישה מוצאים למשתני סביבה — משתנה שורה בהגדרות סוכן הבנייה, והלוגיקה של השלבים נשארת כשהייתה. במהלך המעבר המראה הישנה עובדת במקביל, ולכן המעבר מתבצע בלי לעצור פריסות.
עד כמה מאגר פרטי מוגן?
הגישה מבוססת על תפקידים: הצוות רואה רק את הפרויקטים שלו, והרשאות קריאה וכתיבה מופרדות. אימג'ים נסרקים לפגיעויות בזמן העלאה, המדיניות חוסמת פריסה של בניות עם ממצאים קריטיים, ולמערכות אוטומציה משתמשים בפרטי גישה קצרי מועד במקום סיסמה משותפת לכולם.
מה עם תמיכה לאחר המסירה?
מוסרים קונפיגורציות, סכימות פריסה, נהלי עדכון ושחזור, והגישות מוסדרות לצד שלכם. המהנדסים נשארים בליווי עם זמן תגובה מוסכם, אך לא כיחידים שיודעים לתחזק את המאגר: לאחר ההדרכה, את התפעול מבצע הצוות שלכם.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית עבודה למאגר, נדרש מינימום של נתוני פתיחה: היכן האימג'ים נמצאים сейчас, כמה צוותים מפרסמים, מהן הדרישות לגישות ולאחסון. בדרך כלל מספיק שיחה עם המהנדס שלנו וגישה לקונפיגורציה הנוכחית — אין צורך לפרק את כל הסביבה כולה.
- רשימת השירותים והצוותים שמפרסמים ומושכים אימג'ים — ממנה תלויה סכימת הפרויקטים והבידוד ביניהם.
- נפחים ואחסון נוכחי: כמה תגיות חיות במאגר ומה חייב להישמר בהעברה.
- דרישות לתפקידים: מי רק קורא, מי מפרסם, למי נדרשות הרשאות אדמין ולכמה זמן.
- כללי שמירה: כמה גרסאות אחרונות להחזיק, מה יוצא מהמאגר בלי אפשרות רולבק.
- מדיניות בדיקת אימג'ים לפגיעויות: לחסום פרסום או רק לתעד את התוצאה.
- אחראי מטעם הלקוח וחלון שבו מותרות עבודות בסביבה המשותפת.
בתגובה מתקבלת תוכנית עבודה למאגר: שלבים, שינויים בבניות הקיימות, נקודות בדיקה וקריטריוני קבלה, וכן הערכת הטמעה בפירוק לפי שלבים — בלי עבודה ״לפי המצב בשטח״. התוכנית מתואמת עם המוביל הטכני שלכם, ובמידת הצורך — עם אבטחת המידע.
לאחר התיאום מתחילים בסביבת בדיקות: מקימים מאגר, מעבירים צוות פיילוט, בודקים את מהירות הבנייה והעלאת האימג'ים. בהמשך — מעבר מדורג של שאר הצוותים, הדרכת תורנים ומסירת תיעוד. תארו את המשימה בשתי מילים — נחזור עם הערכה ותוכנית.