תמיכה עבור monorepo ו- multirepo ב-werf ומה הקשר ל-Docker Registry

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

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

נושאים

בואו נדמיין מצב כזה. לחברה צוותי פיתוח רבים העובדים על פרויקטים עצמאיים. רוב היישומים פועלים על Kubernetes ולכן הם מכילים מכולות. כדי לאחסן מכולות, תמונות, אתה צריך רישום (רישום). כרישום כזה, החברה משתמשת ב- Docker Hub עם חשבון יחיד COMPANY. בדומה לרוב מערכות אחסון קוד המקור, Docker Hub אינו מאפשר היררכיית מאגר מקוננת, כמו COMPANY/PROJECT/IMAGE. במקרה כזה... כיצד תוכל לאחסן אפליקציות לא מונוליטיות ברישום עם מגבלה זו מבלי ליצור חשבון נפרד לכל פרויקט?

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

פתרונות

אם היישום מוֹנוֹלִיטִי, מגיע בתמונה אחת, אז אין שאלות ואנחנו פשוט שומרים את התמונות ב-Container Registry של הפרויקט.

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

1. אחסן תמונות במאגרים מקוננים נפרדים:

   

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

   

NB: למעשה, יש אפשרות נוספת עם שמירה במאגרים שונים, PROJECT-frontend и PROJECT-backend, אך לא נשקול זאת בגלל מורכבות התמיכה, הארגון והפצת הזכויות בין המשתמשים.

תמיכה werf

בתחילה, werf הגבילה את עצמה למאגרים מקוננים - למרבה המזל, רוב הרישום תומכים בתכונה זו. החל מהגרסה v1.0.4-alpha.3, נוספה עבודה עם רישום שבהם קינון אינו נתמך, ו- Docker Hub הוא אחד מהם. מנקודה זו ואילך, למשתמש יש בחירה כיצד לאחסן את תמונות האפליקציה.

יישום זמין תחת אפשרות --images-repo-mode=multirepo|monorepo (בְּרִירַת מֶחדָל multirepo, כלומר אחסון במאגרים מקוננים). זה מגדיר את הדפוסים שלפיהם תמונות מאוחסנות ברישום. זה מספיק כדי לבחור את המצב הרצוי בעת שימוש בפקודות הבסיסיות, וכל השאר יישאר ללא שינוי.

מכיוון שניתן להגדיר את רוב אפשרויות ה-werf משתני סביבה, במערכות CI / CD, בדרך כלל קל להגדיר את מצב האחסון באופן גלובלי עבור הפרויקט כולו. לדוגמה, במקרה של GitLab פשוט הוסף משתנה סביבה בהגדרות הפרויקט: הגדרות -> CI / CD -> משתנים: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

השטן נמצא בפרטים

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

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

1. 3 אסטרטגיות מקושרות על ידי פרימיטיביות Git כגון תג, ענף ו-commit;
2. אסטרטגיה 1 לתגים מותאמים אישית שרירותיים.

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

כאשר נשמר במאגר אחד (monorepo), בתג התמונה, בנוסף למטא תג, ניתן לאחסן גם את שם התמונה: PROJECT:frontend-META-TAG. כדי להפריד ביניהם, לא הכנסנו שום מפריד ספציפי, אלא פשוט הוספנו את הערך הדרוש לתווית של התמונה הסופית בעת הפרסום.

NB: אם אתה מעוניין להסתכל על כל מה שמתואר בקוד המקור של werf, אז נקודת ההתחלה יכולה להיות יחסי הציבור 1684.

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

תִמצוּת

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

הישארו איתנו ובקרוב מאוד נספר לכם על חידושים נוספים בתחום werf!

נ.ב.

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

• «כעת אתה יכול לבנות תמונות Docker ב-werf באמצעות Dockerfile רגיל";
• «werf - הכלי שלנו עבור CI / CD ב-Kubernetes (סקירה כללית ודוח וידאו)".

מקור: www.habr.com