בעיית הניקוי ה"חכם" של תמונות מיכל ופתרונה ב-werf

המאמר דן בבעיות של ניקוי תמונות המצטברות ברישום מיכל (Docker Registry והאנלוגים שלו) במציאות של צינורות CI/CD מודרניים עבור יישומים מקוריים בענן המועברים ל-Kubernetes. הקריטריונים העיקריים לרלוונטיות של תמונות והקשיים הנובעים מכך באוטומציה של ניקיון, חיסכון במקום ועמידה בצרכי הצוותים. לבסוף, באמצעות הדוגמה של פרויקט קוד פתוח ספציפי, נספר לכם כיצד ניתן להתגבר על הקשיים הללו.

מבוא

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

1. השתמש במספר קבוע של תגים לתמונות;
2. לנקות את התמונות בדרך כלשהי.

המגבלה הראשונה מקובלת לפעמים על צוותים קטנים. אם למפתחים יש מספיק תגים קבועים (latest, main, test, boris וכו'), הרישום לא יתנפח בגודלו ובמשך זמן רב לא תצטרך לחשוב על ניקויו כלל. הרי כל התמונות הלא רלוונטיות נמחקות, ופשוט לא נשארת עבודה לניקוי (הכל נעשה על ידי אספן אשפה רגיל).

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

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

אבל איך בכלל קובעים אם תמונה רלוונטית?

קריטריונים לרלוונטיות של התמונה

ברוב המוחלט של המקרים, הקריטריונים העיקריים יהיו:

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

2. שנית (פחות ברור, אבל גם מאוד חשוב ושוב מתייחס לניצול) - תמונות ש נדרש להחזרה לאחור במקרה של זיהוי בעיות חמורות בגרסה הנוכחית. לדוגמה, במקרה של Helm, אלו תמונות המשמשות בגרסאות שמורות של המהדורה. (אגב, כברירת מחדל בהלם המגבלה היא 256 גרסאות, אבל לא סביר שמישהו באמת צריך לשמור כך מספר רב של גרסאות?..) הרי אנחנו, במיוחד, מאחסנים גרסאות כדי שנוכל להשתמש בהן מאוחר יותר, כלומר. "להתגלגל בחזרה" אליהם במידת הצורך.

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

4. רביעית - תמונות ש תואמים לגרסאות של האפליקציה שלנו, כלומר הם המוצר הסופי: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra וכו'.

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

זכאות ופתרונות קיימים

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

* תלוי בהטמעות ספציפיות של רישום קונטיינר. שקלנו את האפשרויות של הפתרונות הבאים: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - החל מספטמבר 2020.

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

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

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

איור של זרימת עבודה ב-Git

נניח שאתה עובד משהו כזה ב-Git:

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

מה קורה אם מדיניות הניקוי מאפשרת לשמור רק תמונות (לא למחוק) לפי שמות תגים נתונים?

ברור שתרחיש כזה לא ישמח אף אחד.

מה ישתנה אם המדיניות תאפשר לא למחוק תמונות? לפי מרווח זמן נתון / מספר התחייבויות אחרונות?

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

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

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

הדרך שלנו לניקוי תמונה אוניברסלי

מאיפה הצורך הזה? העובדה היא שאנחנו לא קבוצה נפרדת של מפתחים, אלא צוות שמשרת רבים מהם בבת אחת, ועוזר לפתור בעיות CI/CD באופן מקיף. והכלי הטכני העיקרי לכך הוא כלי השירות קוד פתוח werf. הייחודיות שלו היא שהוא לא מבצע פונקציה אחת, אלא מלווה תהליכי אספקה ​​רציפים בכל השלבים: מהרכבה ועד פריסה.

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

* למרות שהרישום עצמם עשויים להיות שונים (Docker Registry, GitLab Container Registry, Harbor וכו'), המשתמשים שלהם מתמודדים עם אותן בעיות. הפתרון האוניברסלי במקרה שלנו אינו תלוי ביישום הרישום, כי פועל מחוץ לרישום עצמם ומציע את אותה התנהגות לכולם.

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

אז נהיה עסוקים חיצוני הטמעת מנגנון לניקוי תמונות - במקום אותן יכולות שכבר מובנות ברגיסטרים למכולות. הצעד הראשון היה להשתמש ב-Docker Registry API כדי ליצור את אותה מדיניות פרימיטיבית עבור מספר התגים וזמן יצירתם (המוזכר לעיל). נוסף להם רשימת היתר מבוססת על תמונות המשמשות בתשתית פרוסה, כלומר Kubernetes. עבור האחרון, זה הספיק להשתמש ב-Kubernetes API כדי לחזור על כל המשאבים הפרוסים ולקבל רשימת ערכים image.

הפתרון הטריוויאלי הזה פתר את הבעיה הקריטית ביותר (קריטריון מס' 1), אך היה רק ​​תחילת דרכנו לשיפור מנגנון הניקוי. השלב הבא - ומעניין הרבה יותר - היה ההחלטה לשייך תמונות שפורסמו להיסטוריית Git.

תוכניות תיוג

מלכתחילה, בחרנו בגישה שבה התמונה הסופית צריכה לאחסן את המידע הדרוש לניקוי, ובנו את התהליך על סכימות תיוג. בעת פרסום תמונה, המשתמש בחר באפשרות תיוג ספציפית (git-branch, git-commit או git-tag) והשתמש בערך המתאים. במערכות CI, ערכים אלו נקבעו אוטומטית על סמך משתני סביבה. למעשה התמונה הסופית הייתה קשורה לפרימיטיבי Git ספציפי, אחסון הנתונים הדרושים לניקוי בתוויות.

גישה זו הביאה למערכת של מדיניות שאפשרה להשתמש ב-Git כמקור האמת היחיד:

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

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

אלגוריתם חדש

למה? עם תיוג מבוסס תוכן, כל תג יכול לספק התחייבויות מרובות ב-Git. בעת ניקוי תמונות, אתה כבר לא יכול להניח רק מה-commit שבו התגית החדשה נוספה לרישום.

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

• ה-commit שעליו בוצע הפרסום (אין זה משנה אם התמונה נוספה, שונתה או נשארה זהה ברישום המכילים);
• והמזהה הפנימי שלנו המתאים לתמונה המורכבת.

במילים אחרות, זה סופק קישור בין תגים שפורסמו ל-commits ב-Git.

תצורה סופית ואלגוריתם כללי

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

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

לשם המחשה, כך החלה להיראות תצורת ברירת המחדל של המדיניות:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

תצורה זו מכילה שלושה מדיניות התואמות את הכללים הבאים:

1. שמור את התמונה עבור 10 תגיות Git האחרונות (לפי תאריך יצירת התג).
2. שמור לא יותר מ-2 תמונות שפורסמו בשבוע האחרון ללא יותר מ-10 שרשורים עם פעילות בשבוע האחרון.
3. שמור 10 תמונות לסניפים main, staging и production.

האלגוריתם הסופי מסתכם בשלבים הבאים:

• אחזור מניפסטים מ-Container Registry.
• לא כולל תמונות בשימוש ב-Kubernetes, כי כבר בחרנו אותם מראש על ידי סקר ה-API של K8s.
• סורק היסטוריית Git ואי הכללת תמונות על סמך מדיניות שצוינה.
• הסרת התמונות שנותרו.

אם נחזור לאיור שלנו, זה מה שקורה עם werf:

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

מסקנה

• במוקדם או במאוחר, רוב הצוותים נתקלים בבעיית הצפת הרישום.
• כאשר מחפשים פתרונות, יש צורך קודם כל לקבוע את הקריטריונים לרלוונטיות של התמונה.
• הכלים המוצעים על ידי שירותי רישום קונטיינרים פופולריים מאפשרים לך לארגן ניקוי פשוט מאוד שאינו לוקח בחשבון את "העולם החיצון": התמונות המשמשות ב-Kubernetes והמוזרויות של זרימות העבודה של הצוות.
• אלגוריתם גמיש ויעיל חייב להיות בעל הבנה של תהליכי CI/CD ולפעול לא רק עם נתוני תמונה של Docker.

נ.ב.

קרא גם בבלוג שלנו:

• «תיוג מבוסס תוכן ב-werf Builder: למה ואיך זה עובד?";
• «מיזוג תלת כיווני ל-werf: פריסה ל-Kubernetes עם Helm "על סטרואידים"";
• «תמיכה עבור monorepo ו- multirepo ב-werf ומה הקשר ל-Docker Registry";
• «שחרור werf 1.1: שיפורים לבונה היום ותוכניות לעתיד".

מקור: www.habr.com