ProHoster > בלוג > מינהל > תיוג מבוסס תוכן ב-werf Builder: למה ואיך זה עובד?

תיוג מבוסס תוכן ב-werf Builder: למה ואיך זה עובד?

תיוג מבוסס תוכן ב-werf Builder: למה ואיך זה עובד?

werf הוא כלי הקוד הפתוח GitOps CLI שלנו לבנייה ואספקה ​​של יישומים ל-Kubernetes. IN גרסה 1.1 תכונה חדשה הוצגה באוסף התמונות: תיוג תמונות לפי תוכן או תיוג מבוסס תוכן. עד כה, סכימת התיוג האופיינית ב-werf כללה תיוג תמונות Docker לפי תג Git, ענף Git או Git commit. אבל לכל התוכניות הללו יש חסרונות שנפתרים לחלוטין על ידי אסטרטגיית התיוג החדשה. פרטים על זה ולמה זה כל כך טוב נמצאים תחת חתך.

השקת סט של שירותי מיקרו ממאגר Git אחד

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

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

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

תיוג לפי סניף Git ותגית Git

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

כאשר נוצרת תג Git חדש - לדוגמה, כאשר משוחררת גרסה חדשה - תג Docker חדש ייווצר עבור כל תמונות הפרויקט ב-Docker Registry:

  • myregistry.org/myproject/frontend:v1.1.10
  • myregistry.org/myproject/myservice1:v1.1.10
  • myregistry.org/myproject/myservice2:v1.1.10
  • myregistry.org/myproject/myservice3:v1.1.10
  • myregistry.org/myproject/myservice4:v1.1.10
  • myregistry.org/myproject/myservice5:v1.1.10
  • myregistry.org/myproject/database:v1.1.10

שמות התמונות החדשים הללו מועברים דרך תבניות Helm לתצורת Kubernetes. כאשר מתחילים את הפריסה עם הפקודה werf deploy השדה מתעדכן image במניפסטים של משאב Kubernetes והפעלה מחדש של המשאבים המתאימים עקב שינוי שם התמונה.

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

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

תיוג על ידי Git commit

ל-werf יש גם אסטרטגיית תיוג הקשורה ל-Git commits.

Git-commit הוא מזהה עבור התוכן של מאגר Git ותלוי בהיסטוריית העריכה של קבצים במאגר Git, כך שנראה הגיוני להשתמש בו לתיוג תמונות ב-Docker Registry.

עם זאת, לתיוג על ידי Git commit יש את אותם חסרונות כמו לתיוג על ידי סניפים של Git או תגיות Git:

  • ניתן ליצור commit ריק שלא משנה אף קובץ, אבל תג ה-Docker של התמונה ישתנה.
  • ניתן ליצור התחייבות למיזוג שאינה משנה את הקבצים, אך תג ה-Docker של התמונה ישתנה.
  • ניתן לבצע commit שמשנה את הקבצים ב-Git שאינם מיובאים לתמונה, ותג ה-Docker של התמונה ישתנה שוב.

תיוג שם סניף Git אינו משקף את גרסת התמונה

ישנה בעיה נוספת הקשורה באסטרטגיית התיוג עבור סניפי Git.

תיוג לפי שם סניף עובד כל עוד ההתחייבויות על אותו סניף נאספות ברצף בסדר כרונולוגי.

אם בסכימה הנוכחית המשתמש מתחיל לבנות מחדש commit ישן המשויך לענף מסוים, אז werf ישכתב את התמונה באמצעות תג Docker המקביל עם גרסה חדשה שנבנתה של התמונה עבור ה-commit הישן. פריסות המשתמשות בתג זה מעתה ואילך מסתכנות במשיכת גרסה אחרת של התמונה בעת הפעלה מחדש של פודים, וכתוצאה מכך האפליקציה שלנו תאבד את הקשר עם מערכת ה-CI ותהפוך לסינכרון.

בנוסף, עם דחיפות עוקבות לסניף אחד עם פרק זמן קצר ביניהן, ה-commit הישן עשוי להיות קומפילציה מאוחר יותר מהחדש יותר: הגרסה הישנה של התמונה תחליף את החדשה באמצעות תגית ה-Git branch. בעיות כאלה יכולות להיפתר על ידי מערכת CI/CD (לדוגמה, ב-GitLab CI הצינור של האחרון מושק לסדרה של commits). עם זאת, לא כל המערכות תומכות בכך וחייבת להיות דרך אמינה יותר למנוע בעיה מהותית שכזו.

מהו תיוג מבוסס תוכן?

אז מה זה תיוג מבוסס תוכן - תיוג תמונות לפי תוכן.

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

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

תג מזהה כזה הוא מה שנקרא חתימת בימת תמונה.

כל תמונה מורכבת מסדרה של שלבים: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch וכו ' לכל שלב יש מזהה המשקף את תוכנו - חתימת במה (חתימת במה).

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

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

חתימת הבמה פותרת את כל הבעיות הללו:

  • עמיד בפני התחייבויות Git ריקות.
  • Resistant to Git commits שמשנים קבצים שאינם רלוונטיים לתמונה.
  • לא מוביל לבעיה של שיפוץ הגרסה הנוכחית של התמונה בעת הפעלה מחדש של builds עבור התחייבויות Git ישנות של סניף.

זוהי כעת אסטרטגיית התיוג המומלצת והיא ברירת המחדל ב-werf עבור כל מערכות ה-CI.

כיצד להפעיל ולהשתמש ב-werf

לפקודה יש ​​כעת אפשרות מתאימה werf publish: --tag-by-stages-signature=true|false

במערכת CI, אסטרטגיית התיוג מוגדרת על ידי הפקודה werf ci-env. בעבר הוגדר עבורו הפרמטר werf ci-env --tagging-strategy=tag-or-branch. עכשיו, אם אתה מציין werf ci-env --tagging-strategy=stages-signature או אל תציין אפשרות זו, werf תשתמש באסטרטגיית התיוג כברירת מחדל stages-signature. קְבוּצָה werf ci-env יגדיר אוטומטית את הדגלים הדרושים לפקודה werf build-and-publish (או werf publish), כך שאין צורך לציין אפשרויות נוספות עבור פקודות אלו.

לדוגמה, הפקודה:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...יכול ליצור את התמונות הבאות:

  • registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
  • registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

כאן 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d הוא חתימה של שלבי התמונה backendו - f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - חתימה של שלבי תמונה frontend.

בעת שימוש בפונקציות מיוחדות werf_container_image и werf_container_env אין צורך לשנות שום דבר בתבניות Helm: פונקציות אלו ייצרו אוטומטית את שמות התמונות הנכונים.

תצורה לדוגמה במערכת CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

מידע נוסף על תצורה זמין בתיעוד:

בסך הכל

  • אפשרות חדשה werf publish --tag-by-stages-signature=true|false.
  • ערך אופציה חדשה werf ci-env --tagging-strategy=stages-signature|tag-or-branch (אם לא צוין, ברירת המחדל תהיה stages-signature).
  • אם השתמשת בעבר באפשרויות התיוג עבור Git commits (WERF_TAG_GIT_COMMIT או אפשרות werf publish --tag-git-commit COMMIT), ולאחר מכן הקפד לעבור לאסטרטגיית התיוג חתימת שלבים.
  • עדיף להעביר מיד פרויקטים חדשים לתוכנית התיוג החדשה.
  • בעת העברה ל-werf 1.1, רצוי להחליף פרויקטים ישנים לערכת התיוג החדשה, אך הישנה תג-או-ענף עדיין נתמך.

תיוג מבוסס תוכן פותר את כל הבעיות המכוסות במאמר:

  • עמידות שם תג Docker ל-Git commits ריקים.
  • חוסן של שם התג Docker ל-Git מחויבות שמשנות קבצים לא רלוונטיים לתמונה.
  • לא מוביל לבעיה של שיפוץ הגרסה הנוכחית של התמונה בעת הפעלה מחדש של builds עבור commits ישנים של Git עבור סניפי Git.

תשתמש בזה! ואל תשכחו לבקר אותנו ב GitHubליצור בעיה או למצוא בעיה קיימת, להוסיף פלוס, ליצור יחסי ציבור או פשוט לצפות בפיתוח הפרויקט.

נ.ב.

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

מקור: www.habr.com

הוספת תגובה