הגדרת Docker Hub: מדוע בניות נופלות בהעלאה
צינור הבנייה עובר בדיקות, אורז תמונה — ונופל בשלב האחרון, בהעלאה לרשם. זהו כשל אופייני בהעלאת תמונה: הפריסה נתקעת, בסביבה נשארת הגרסה הקודמת, וברשם אין ארטיפקט שאפשר לחזור אליו. עצירת הבנייה בקו הסיום עולה ביוקר — זמן עבודת הצינור בוזבז, והתוצאה לא סופקה.
הסיבות בדרך כלל שלוש, והן מצטברות זו על זו. הרשאות למאגר ניתנות במפתח גישה שפג תוקפו או שיודע רק לקרוא: ההעלאה נתקלת בסירוב, למרות שבאופן מקומי אותה פקודה עוברת.
מגבלות הבקשות מנוצלות בבקשות אנונימיות משותפות מצמתי בנייה משותפים — הורדת שכבות בסיס מתחילה להחזיר שגיאה, והצינור מתפורר עוד לפני הקומפילציה. תגים לא מנוהלים משלימים את התמונה: latest הצף נדרס על ידי הגרסה הקודמת, מטמון השכבות אינו עושה שימוש חוזר, וכל בנייה מושכת הכול מחדש.
בהמשך הכשל מוסווה בעקיפות ידניות: מהנדסים נכנסים לרשם מהמכונה שלהם, מעלים תמונה ידנית, מחליפים זמנית פרטי התחברות. כך נוצרות תלויות לא מתועדות באדם מסוים, שאינן ידועות לחבר צוות חדש, והכשל הבא מגיע כבר ברגע השחרור.
נבחן כיצד זה נסגר. הגדרת Docker Hub מתחילה לא מפקודת כניסה, אלא מארגון: הפרדת הרשאות לפי מאגרים, פרטי התחברות נפרדים לצמתי בנייה, מטמון שכבות משותף וכללי שמירה לתגים.
מה נותן רשם תמונות מנוהל לצוות
כל עוד תמונות נמשכות ישירות מרשם ציבורי, כל הרצה של הצינור מורידה מחדש שכבות בסיס. מטמון השכבות חי רק בתוך צומת בנייה אחד ומתפורר עם החלפת מבצע או ניקוי דיסק — שיעור ההורדות החוזרות נשאר גבוה, וזמן הבנייה נקבע לא על ידי הקוד, אלא על ידי עובי תמונת הבסיס ומהירות הערוץ החיצוני.
רשם מנוהל משנה את התמונה: שכבות בסיס מפורסמות פעם אחת, תגים מקובעים, והבנייה מגיעה לתמונה חתומה כבר ממאגר פנימי. מטמון השכבות הופך למשותף לכל המבצעים, בנייה מצטברת עושה שימוש חוזר בשכבות שלא השתנו, וזמן הבנייה מתקצר פי כמה — באופן צפוי, ולא «כשמזל עם הרשת».
בנפרד נעלם סוג שלם של כשלים הקשור למגבלות בקשות לרשם חיצוני ולהעלאה אנונימית. בעבר הצינור נפל על לא דבר: מיצו את המכסה להורדה, קיבלו סירוב באימות, נתפס פסק זמן בניתוק הערוץ. לאחר הגדרת אימות עם פרטי התחברות נפרדים לבנייה ומטמון פרוקסי פנימי, הרצות כאלה פשוט מפסיקות להתקיים.
מהירות הפריסה — תוצאה ישירה. כאשר תמונה נבנית תוך דקות ומגיעה לסביבת היעד בלי להמתין להורדה, הגרסה מפסיקה להיות אירוע של חצי יום. הצוות פורס לעתים קרובות יותר ובמנות קטנות יותר, והחזרה לתג הקודם אורכת כמו הפריסה עצמה.
הגדרת Docker Hub: מצבי גישה ומכסות
בחירת מצב גישה קובעת מה יקרה כאשר קטלוג תמונות חיצוני יגביל העלאה או שצומת בנייה יאבד קשר איתו. במצב בסיסי הצינור מושך שכבות בסיס ישירות, ובמיצוי המכסה הוא נופל לא בגלל הקוד, אלא בגלל מגבלה חיצונית.
להפריד בין סביבה פרטית לציבורית מראש זול יותר מאשר לנתח נפילות לילה. הסכמות נבדלות זו מזו בכך אילו מצבי גישה הן מתירות והיכן עובר גבול האמון.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| עבודה ישירה עם Docker Hub ציבורי | אבות טיפוס, בניות בודדות, צוות קטן | מכסה משותפת להעלאה, תמונות פרטיות דורשות תעריף נפרד |
| רשם פרטי בתוך Docker Hub | תמונות סגורות, כמה צוותים, לא רוצים להקים סביבה משלהם | גישות לפי טוקנים ותפקידים, מכסת ההורדה נשמרת |
| רשם עצמאי בתשתית שלך | סביבה מבודדת, מדיניות שמירה וביקורת משלך | דרושים אחסון, גיבויים, סבב החלפת תעודות, תחזוקת עדכונים |
| מטמון פרוקסי ומראה תמונות | צמתים רבים, שכבות בסיס חוזרות, ערוץ חיצוני לא יציב | הבקשה הראשונה בכל זאת יוצאת החוצה, נדרשת מדיניות פינוי לפי גודל |
בדרך כלל בונים סכמה משולבת: מראה מכסה שכבות בסיס משותפות, רשם פרטי — בניות משלך, וקטלוג ציבורי נשאר נקודת כניסה לתמונות חיצוניות נדירות. בהמשך מגדירים מצבי גישה לפי עומס ודרישות ביקורת.
שלבי הגדרת רשם ומדיניות גישה
סדר העבודות כאן חשוב יותר ממהירות: מדיניות גישה שנקבעה לפני מיפוי מלאי צריכה להיעשות מחדש, ומגבלות על תדירות בקשות ניכרות רק בבנייה אמיתית. להלן הרצף שבו הגדרת Docker Hub עוברת בלי לעצור את הצינור ובלי חריגים ידניים.
- ביקורת בניות. אוספים רשימת תמונות, תדירות פרסומים, מקורות שכבות בסיס וחשבונות שכבר יש להם גישה. בפלט — טבלה «תמונה — צוות — תדירות — קריטיות», והיא קובעת את כל ההחלטות הבאות.
- סכמת מאגרים ומרחבי שמות. מפזרים תמונות לפי ארגונים כך שהרשאות ניתנות לקבוצה, ולא לכל שירות בנפרד. תמונות ציבוריות ופנימיות חיות במרחבי שמות שונים ואינן מערבבות גישות.
- טוקנים לגישה. מקימים טוקני שירות עם הרשאות מינימליות, מפרידים קריאה וכתיבה, מגבילים תוקף ומגדירים סבב החלפה. סיסמאות מחשבונות בתצורות בנייה נעלמות לחלוטין.
- כללי שמירה. משאירים N התמונות האחרונות לכל תג, השאר מנוקה — הרשם מפסיק לגדול, והחזרה לגרסה קודמת נשארת אפשרית.
- בדיקה על צינור אמיתי. מריצים בנייה, פרסום, פריסה וחזרה לאחור במרחב בדיקה. בנפרד בוחנים התנהגות בעת פגיעה במגבלת בקשות ועבודה דרך מטמון תמונות מקומי.
- מסירה והדרכת תורנים. מוסרים סכמת מאגרים, נוהל סבב החלפת טוקנים והוראות לתקלות אופייניות, מנתחים עם משמרת תורנות סירוב אימות ומיצוי מגבלה.
לאחר מכן הרשם חי לפי הכללים המתוארים, ולא לפי הזיכרון של מהנדס מסוים.
תצורות, מדיניות גישה ונהלים
הגדרת Docker Hub לא מסתיימת בלוגין עובד. התוצאה — סט ארטיפקטים שלפיהם צוות הלקוח ממשיך לעבוד בלעדינו: תצורות, סכמות, כללי גישה ונהלים. הכול נשאר במאגרים של הלקוח, כדי ששינויים ייעשו באופן צפוי, ולא לפי הזיכרון של מהנדס מסוים.
- קבצי תצורה של לקוח וסוכן רשם — עם הערות אילו פרמטרים משתנים במעבר בין סביבות.
- סכמת מאגרים וכללי שמות תגים: היכן חיים תמונות בסיס, היכן תמונות גרסה, היכן בניות זמניות.
- מטריצת הרשאות: תפקידי קריאה, פרסום וניהול עם שיוך לצוותים ולסביבות.
- חשבונות שירות לבנייה ולפריסה — נפרדים לכל סביבה, בלי הרשאה למחוק היסטוריית תגים.
- סדר סבב החלפת מפתחות וטוקנים: תוקף, מי מפיק, כיצד מבוטלת גישה שנחשפה.
- מדיניות שמירה: כמה תמונות מחזיקים לכל תג, מה מנוקה אוטומטית, כיצד מתבצעת חזרה לגרסה קודמת.
- נוהל תחזוקת רשם: בדיקות מתוכננות, תגובה למיצוי מגבלות בקשות, נקודות בקרה ואחראים.
- תיעוד הרשם: הוראות למפתחים, סכמת גישה, סדר הסלמה בתקלה.
אנחנו מוסרים לא רק קבצים, אלא גם ניתוח: מדוע נבחרו מגבלות כאלה, היכן צווארי הבקבוק ומה לשנות עם גידול מספר הצוותים.
מקרה בוחן: הסרנו כשלי העלאת תמונות בבנייה
צוות מוצר עם עשרה שירותים בנה תמונות בצינור בנייה משותף, וכל שלב משך שכבות בסיס ישירות מרשם ציבורי חיצוני Docker Hub. בבניות מקבילות הורדות אנונימיות נתקלו במגבלות בקשות, וחלק מהמשימות נפלו בשלב קבלת תמונת הבסיס, ולא בקוד. שיעור הבניות שנכשלו עמד על כ-18%, וניתוח כל נפילה כזו גזל זמן ממהנדס תורנות ודחה את הפריסה.
מה שינו: הקימו ארגון עם חשבונות שירות נפרדים לכל סוכן בנייה והנפיקו להם טוקנים לקריאה בלבד — במקום בקשות אנונימיות משותפות. בתוך הסביבה הקימו רשם-מטמון פרוקסי: הוא לוקח שכבה פעם אחת מבחוץ ומוסר אותה לכל הצמתים, כולל בניות ופריסות חוזרות. עבור המטמון הגדירו כללי שמירה — נשארים רק תגים עדכניים בשימוש, ולכן האחסון לא גדל ללא גבול.
מדדים לפני ואחרי: שיעור הבניות שנכשלו ירד מ-18% ל-1–2%, ובשארית רק שגיאות קומפילציה. מספר הבקשות לרשם החיצוני הצטמצם בערך פי 30 — כמעט כל ההורדות מגיעות ממטמון מקומי. זמן הפריסה ירד מ-14 ל-6 דקות: השכבות כבר לא ממתינות לרשת החיצונית ולא מתחרות על מגבלות.
כשלים שהוסרו: חריגה ממגבלות בקשות ופסקי זמן בהורדת תמונות נעלמו לחלוטין. המטמון גם מסיר את התלות בזמינות הרשם החיצוני — בתקלות רשת הבנייה ממשיכה על שכבות מקומיות. טוקנים עם הרשאות מוגבלות נמצאים במאגר מאובטח ומתחלפים לפי לוח זמנים, ולא בהגדרות בנייה פתוחות.
במה מטמון פרוקסי של רשם שונה ממראה
בקצרה: מראה מחזיקה תמונות אצלך באופן קבוע, מטמון פרוקסי — רק את אלו שכבר נתבקשו. מכאן נבדלים הזמינות בעת כשל מקור, נפח האחסון וצפויות הבנייה.
מראה של רשם — זו העתקה שלך של מאגרים נבחרים. הסנכרון מתבצע לפי לוח זמנים או לפי אירוע, ולכן כאשר Docker Hub אינו זמין הבנייה נמשכת: התמונות כבר נמצאות בתוך הסביבה, ומוגש בדיוק אותו תג שקיבעת. המחיר לכך — האחסון גדל עם מספר הגרסאות שהועתקו, והעדכניות מוגבלת לחלון הסנכרון.
מטמון פרוקסי בנוי אחרת: הוא לא מעתיק הכול מראש, אלא מעביר בקשה למקור ומשאיר העתקה לפי פנייה. ההורדה הראשונה של תמונה יוצאת החוצה, לאחר מכן היא מוגשת ממטמון מקומי. בעת כשל מקור זמין רק מה שכבר חומם — תג חדש לא יימשך עד שהקשר יתחדש.
בפועל הבחירה בסכמה לעתים רחוקות בינארית, ובדרך כלל מנצח היברידי. מטמון פרוקסי מכסה תמונות בסיס ותלויות חיצוניות, שבהן חשובה העדכניות ולא נדרש סט מלא של גרסאות; מראה — תגים קריטיים שהשחרור תלוי בהם.
בנפרד מתכננים מדיניות ניקוי: בלעדיה המטמון גדל כמו מראה, וצוואר הבקבוק הופך להיות לא המקור, אלא הדיסק. אימות מול הרשם החיצוני מחזיקים בשכבת הפרוקסי — כך פרטי ההתחברות לא מתפזרים בין סוכני בנייה.
ספקות טכניים נפוצים לגבי רשם
ספקות נפוצים לגבי רשם לעתים רחוקות נוגעים לבנייה עצמה — הם עוסקים בגישות, בהיגיינת תגים ובהתנהגות תחת עומס מקביל. להלן ארבע שאלות שצוותי הנדסה שואלים לפני ההתחלה, וכיצד כל אחת נסגרת ברמת הרשאות ותצורה, ולא הבטחות.
לתת לקבלנים גישה לחשבון הראשי — מסוכן?
החשבון הראשי נשאר אצלך. הקבלן מקבל משתמש נפרד עם הרשאות רק למאגרים מסוימים, והטוקן מונפק עם תוקף מוגבל ומבוטל בפקודה אחת. כל הפעולות נרשמות ביומן עם שיוך לחשבון — בסיום העבודות הגישה מוסרת כולה, בלי להחליף סיסמאות ראשיות.
תגים מצטברים ותופסים מקום — איך לנקות בלי סיכון?
כלל מחזור חיים מחזיק N התמונות האחרונות לכל תג ומסיר את השאר, כולל שכבות ביניים שאיש כבר לא מפנה אליהן. חזרה לגרסה קודמת נשארת אפשרית, כי הניקוי לפי תאריך ולפי מספר, ולא «למחוק הכול ישן». הרשם מפסיק לגדול באופן ליניארי עם מספר הבניות.
האם נעמוד בבניות מקבילות בכמה ענפים?
מגבלות נספרות לפי מספר בקשות לרשם בפרק זמן, ולכן הבנייה נתקלת בהן לא מנפח התמונות, אלא מהתדירות שלהן. בנוסף הן מוסרות על ידי שכבת בסיס משותפת, מטמון בין ענפים וחזרה על בקשה עם השהיה בעת סירוב. סכמה שמוגדרת כך עוברת בשקט שיא, כאשר כמה ענפים נבנים בו-זמנית.
כבר פרסנו רשם עצמאי משלנו — צריך להחליף?
לא בהכרח. תמונות חיצוניות מחברים כמראה מעל הרשם שלך: הן נשמרות במטמון מקומי בפנייה הראשונה, והבניות הפנימיות נשארות היכן שהן. אם המקור החיצוני אינו זמין או מחזיר שגיאה, הבניות ממשיכות להגיע מהמטמון — צוואר הבקבוק מפסיק להיות נקודת כשל.
נדון במשימה ונחזור עם תוכנית עבודה
כדי לחזור עם הערכת לוחות זמנים ותוכנית עבודה, אנחנו צריכים נתוני מקור על מצבו הנוכחי של רשם התמונות. להלן מה שמסיר את רוב אי-הוודאות ומאפשר לא לכלול שלבים מיותרים «ליתר ביטחון».
- איך בנויה הגישה כעת: חשבונות אישיים של מפתחים, ארגון, משתמשי שירות נפרדים — ומי בדיוק מפרסם תמונות.
- מאין מגיעות הבניות: מכונות מקומיות או צינור משותף, כמה משימות מבוצעות במקביל ובאיזו תדירות.
- מבנה האחסון: מספר מאגרים, סכמת תיוג, אילו תגים נחשבים לתגי גרסה ואילו נדרסים.
- היכן נפרסות הסביבות: סביבה סגורה או אתרים חיצוניים, מאילו אזורים מתבצעת הורדת תמונות.
- דרישות להפרדת הרשאות: למי מותר לפרסם, האם נדרשים תפקידים נפרדים לצוותים ובדיקת תמונות לפני פריסה.
- תסמינים שכבר מפריעים: שגיאות אימות, סירובים בבקשות תכופות, התנגשויות בעת דריסת תגים.
אם אין נתונים לגבי חלק מהסעיפים — זו גם תשובה: נכלול בתוכנית העבודה שלב מיפוי מלאי ונתאם איתך את סדר השלבים. תאר את המשימה בצורה חופשית, צרף תצורות אם קיימות, — נחזור עם הערכת לוחות זמנים והצעה לסדר העבודות.