הוא כלי הקוד הפתוח GitOps CLI שלנו לבנייה ואספקה של יישומים ל-Kubernetes. כמו שהובטח, סימן את ההתחלה של הוספת תכונות חדשות ל-werf ותיקון גישות מסורתיות. כעת אנו שמחים להציג את המהדורה v1.1, שהיא צעד גדול בפיתוח ובסיס לעתיד אַסְפָן werf. הגרסה זמינה כעת ב .
הבסיס לשחרור הוא הארכיטקטורה החדשה של אחסון הבמה ואופטימיזציה של העבודה של שני האספנים (עבור Stapel ו- Dockerfile). ארכיטקטורת האחסון החדשה פותחת את האפשרות להטמיע הרכבות מבוזרות ממספר מארחים ומכלולים מקבילים על אותו מארח.
ייעול העבודה כולל היפטרות מחישובים מיותרים בשלב חישוב חתימות השלבים ושינוי מנגנוני חישוב סכומי בדיקות קבצים כדי להיות יעילים יותר. אופטימיזציה זו מפחיתה את הזמן הממוצע של בניית פרויקטים באמצעות werf. ובניית סרק, כאשר כל השלבים קיימים במטמון שלבים-אחסון, עכשיו ממש מהירים. ברוב המקרים, הפעלה מחדש של ה-build תארך פחות משנייה אחת! זה חל גם על נהלים לאימות שלבים בתהליך עבודת הצוותים. werf deploy и werf run.
גם במהדורה זו הופיעה אסטרטגיה לתיוג תמונות לפי תוכן - תיוג מבוסס תוכן, שמופעל כעת כברירת מחדל והיחיד המומלץ.
בואו נסתכל מקרוב על החידושים המרכזיים ב-werf v1.1, ובמקביל נספר לכם על תוכניות לעתיד.
מה השתנה ב-werf v1.1?
פורמט חדש של שמות שלבים ואלגוריתם לבחירת שלבים מהמטמון
כלל חדש ליצירת שם במה. כעת כל בניית שלב מייצרת שם שלב ייחודי, המורכב מ-2 חלקים: חתימה (כמו שהייתה ב-v1.0) בתוספת מזהה זמני ייחודי.
לדוגמה, שם תמונת הבמה המלא עשוי להיראות כך:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...או באופן כללי:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Здесь:
-
SIGNATUREהוא חתימת במה, המייצגת את המזהה של תוכן הבמה ותלויה בהיסטוריה של עריכות ב-Git שהובילו לתוכן זה; -
TIMESTAMP_MILLISECהוא מזהה תמונה ייחודי מובטח שנוצר בזמן בניית תמונה חדשה.
האלגוריתם לבחירת שלבים מהמטמון מבוסס על בדיקת הקשר בין התחייבויות Git:
- Werf מחשב את החתימה של שלב מסוים.
- В שלבים-אחסון ייתכנו מספר שלבים עבור חתימה נתונה. Werf בוחר את כל השלבים התואמים את החתימה.
- אם השלב הנוכחי מקושר ל-Git (git-archive, שלב מותאם אישית עם תיקוני Git:
install,beforeSetup,setup; או git-latest-patch), ואז werf בוחר רק את השלבים המשויכים ל-commit שהוא אב קדמון של ה-commit הנוכחי (שעבורו נקרא ה-build). - מבין השלבים המתאימים הנותרים, נבחר אחד - העתיק ביותר לפי תאריך יצירה.
במה לענפי Git שונים יכולה להיות אותה חתימה. אבל werf תמנע את השימוש במטמון המשויך לענפים שונים בין הענפים הללו, גם אם החתימות תואמות.
.
אלגוריתם חדש ליצירה ושמירת שלבים באחסון השלבים
אם, בעת בחירת שלבים מהמטמון, werf לא מוצאת שלב מתאים, אז מתחיל תהליך הרכבת שלב חדש.
שים לב שתהליכים מרובים (במארח אחד או יותר) יכולים להתחיל לבנות את אותו שלב בערך באותו זמן. Werf משתמש באלגוריתם חסימה אופטימי שלבים-אחסון ברגע שמירת התמונה שנאספה לאחרונה שלבים-אחסון. בדרך זו, כאשר בניית השלב החדשה מוכנה, werf חוסם שלבים-אחסון ושומר שם תמונה טרייה שנאספה רק אם תמונה מתאימה כבר לא קיימת שם (לפי חתימה ופרמטרים נוספים - ראה את האלגוריתם החדש לבחירת שלבים מהמטמון).
תמונה שהורכבה טרי מובטחת בעלת מזהה ייחודי על ידי TIMESTAMP_MILLISEC (ראה פורמט שמות במה חדש). במקרה ב שלבים-אחסון תימצא תמונה מתאימה, werf תשליך את התמונה הטרייה ותשתמש בתמונה מהמטמון.
במילים אחרות: התהליך הראשון לסיום בניית התמונה (המהיר ביותר) יקבל את הזכות לאחסן אותה בשלבים-אחסון (ואז זו התמונה הבודדת הזו שתשמש עבור כל הבנייה). תהליך בנייה איטי לעולם לא יחסום תהליך מהיר יותר מלשמור את תוצאות הבנייה של השלב הנוכחי ולעבור לבנייה הבאה.
.
ביצועי בונה Dockerfile משופרים
כרגע, צינור השלבים לתמונה הבנויה מ-Dockerfile מורכב משלב אחד - dockerfile. בעת חישוב החתימה מחושב סכום הבדיקה של הקבצים context, אשר ישמש במהלך ההרכבה. לפני השיפור הזה, werf עברה באופן רקורסיבי על כל הקבצים והשיגה סכום בדיקה על ידי סיכום ההקשר והמצב של כל קובץ. החל מגרסה 1.1, werf יכולה להשתמש בסכומי ביקורת מחושבים המאוחסנים במאגר Git.
האלגוריתם מבוסס על . האלגוריתם לוקח בחשבון רשומות ב .dockerignore וחוצה את עץ הקבצים באופן רקורסיבי רק כשצריך. לפיכך, התנתקנו מקריאת מערכת הקבצים ומהתלות של האלגוריתם בגודל context אינו משמעותי.
האלגוריתם בודק גם קבצים לא במעקב ובמידת הצורך לוקח אותם בחשבון בסכום הבדיקה.
ביצועים משופרים בעת ייבוא קבצים
גרסאות של werf v1.1 משתמשות בשרת rsync כאשר . בעבר, הייבוא נעשה בשני שלבים באמצעות הרכבת ספרייה מהמערכת המארחת.
ביצועי הייבוא ב-macOS אינם מוגבלים עוד על ידי נפחי Docker, והייבוא הושלם באותו פרק זמן כמו לינוקס ו-Windows.
תיוג מבוסס תוכן
Werf v1.1 תומך במה שנקרא תיוג לפי תוכן תמונה - תיוג מבוסס תוכן. התגיות של תמונות Docker שהתקבלו תלויות בתוכן של תמונות אלו.
בעת הפעלת הפקודה werf publish --tags-by-stages-signature או werf ci-env --tagging-strategy=stages-signature פרסמו תמונות של מה שנקרא חתימת במה תמונה. כל תמונה מתויגת בחתימה משלה של שלבי תמונה זו, המחושבת לפי אותם כללים כמו החתימה הרגילה של כל שלב בנפרד, אך מהווה מזהה כללי של התמונה.
החתימה של שלבי התמונה תלויה ב:
- התוכן של תמונה זו;
- היסטוריות של השינויים ב-Git שהובילו לתוכן זה.
למאגר Git יש תמיד מחויבות דמה שאינן משנות את התוכן של קבצי התמונה. למשל, commit עם הערות בלבד או מיזוג commits, או commits שמשנים את אותם קבצים ב-Git שלא יובאו לתמונה.
בעת שימוש בתיוג מבוסס תוכן, נפתרות הבעיות של הפעלה מחדש מיותרת של פודים של יישומים ב-Kubernetes עקב שינויים בשם התמונה, גם אם תוכן התמונה לא השתנה. אגב, זו אחת הסיבות שמונעות אחסון של מיקרו-שירותים רבים של אפליקציה אחת במאגר Git יחיד.
כמו כן, תיוג מבוסס תוכן הוא שיטת תיוג אמינה יותר מאשר תיוג בסניפי Git, מכיוון שתוכן התמונות המתקבלות אינו תלוי בסדר ביצוע הצינורות במערכת ה-CI להרכבת מספר commits של אותו ענף.
זה חשוב: החל מעכשיו חתימת שלבים - האם אסטרטגיית התיוג המומלצת היחידה. הוא ישמש כברירת מחדל בפקודה werf ci-env (אלא אם אתה מציין במפורש סכימת תיוג אחרת).
. לתכונה זו יוקדש גם פרסום נפרד. מְעוּדכָּן (3 באפריל): מאמר עם פירוט .
רמות רישום
למשתמש יש כעת הזדמנות לשלוט בפלט, להגדיר את רמת הרישום ולעבוד עם מידע באגים. נוספו אפשרויות --log-quiet, --log-verbose, --log-debug.
כברירת מחדל, הפלט מכיל את המידע המינימלי:
בעת שימוש בפלט מילולי (--log-verbose) אתה יכול לראות איך werf עובד:
פלט מפורט (--log-debug), בנוסף למידע על ניפוי באגים, מכיל גם יומנים של ספריות בשימוש. לדוגמה, אתה יכול לראות כיצד מתרחשת אינטראקציה עם ה-Docker Registry, וגם לתעד את המקומות שבהם מבלה כמות משמעותית של זמן:
תכניות נוספות
אזהרה! האפשרויות המתוארות להלן מסומנות v1.1 יהפכו לזמינים בגרסה זו, רבים מהם בעתיד הקרוב. העדכונים יגיעו באמצעות עדכונים אוטומטיים . תכונות אלו אינן משפיעות על החלק היציב של פונקציות v1.1; המראה שלהן לא ידרוש התערבות ידנית של המשתמש בתצורות קיימות.
תמיכה מלאה בהטמעות שונות של Docker Registry (חדש)
- גרסה: v1.1
- תאריכים: מרץ
המטרה היא שהמשתמש ישתמש ביישום מותאם אישית ללא הגבלות בעת השימוש ב-werf.
נכון לעכשיו, זיהינו את מערך הפתרונות הבא שעבורם אנו הולכים להבטיח תמיכה מלאה:
- ברירת מחדל (ספרייה/רישום)*,
- AWS ECR
- צבע תכלת*,
- Docker Hub
- GCR*,
- חבילות GitHub
- רישום GitLab*,
- נמל*,
- רָצִיף.
פתרונות הנתמכים כעת באופן מלא על ידי werf מסומנים בכוכבית. לאחרים יש תמיכה, אבל עם מגבלות.
ניתן לזהות שתי בעיות עיקריות:
- פתרונות מסוימים אינם תומכים בהסרת תגים באמצעות ה-API של Docker Registry, מה שמונע ממשתמשים להשתמש בניקוי האוטומטי של werf. זה נכון עבור חבילות AWS ECR, Docker Hub ו-GitHub.
- חלק מהפתרונות אינם תומכים במה שמכונה מאגרים מקוננים (Docker Hub, GitHub Packages ו-Quy) או תומכים, אך המשתמש חייב ליצור אותם באופן ידני באמצעות ממשק המשתמש או ה-API (AWS ECR).
אנחנו הולכים לפתור בעיות אלו ואחרות באמצעות ממשקי API מקוריים של הפתרונות. משימה זו כוללת גם כיסוי המחזור המלא של פעולת werf עם בדיקות עבור כל אחד מהם.
בניית תמונה מבוזרת (↑)
- גרסה: v1.2 v1.1 (העדיפות ליישום תכונה זו הוגדלה)
- תאריכים: מרץ-אפריל מרץ
נכון לעכשיו, ניתן להשתמש ב-werf v1.0 ו-v1.1 רק על מארח ייעודי אחד לפעולות של בנייה ופרסום של תמונות ופריסה של האפליקציה ל-Kubernetes.
כדי לפתוח את האפשרויות של עבודה מבוזרת של werf, כאשר הבנייה והפריסה של יישומים ב-Kubernetes מושקים במספר מארחים שרירותיים והמארחים הללו אינם שומרים את מצבם בין בנייה (רצים זמניים), werf נדרש ליישם את יכולת השימוש ה-Docker Registry כחנות במה.
בעבר, כשפרויקט werf עדיין נקרא dapp, הייתה לו הזדמנות כזו. עם זאת, נתקלנו במספר בעיות שיש לקחת בחשבון בעת יישום פונקציונליות זו ב-werf.
שים לב. תכונה זו אינה מחייבת את האספן לעבוד בתוך תרמילים של Kubernetes, מכיוון לשם כך צריך להיפטר מהתלות בשרת Docker המקומי (ב-Kubernetes pod אין גישה לשרת Docker המקומי, כי התהליך עצמו פועל בקונטיינר, ו-werf לא תומך ולא יתמוך עבודה עם שרת Docker דרך הרשת). תמיכה בהפעלת Kubernetes תיושם בנפרד.
תמיכה רשמית עבור פעולות GitHub (חדש)
- גרסה: v1.1
- תאריכים: מרץ
כולל תיעוד werf (סעיפים הפניה и מדריך), כמו גם הפעולה הרשמית של GitHub לעבודה עם werf.
בנוסף, זה יאפשר ל-werf לעבוד על רצים ארעיים.
המכניקה של אינטראקציה של המשתמש עם מערכת ה-CI תתבסס על הצבת תוויות על בקשות משיכה כדי ליזום פעולות מסוימות לבניית/הפצת האפליקציה.
פיתוח ופריסה מקומית של יישומים עם werf (↓)
- גרסה: v1.1
- תאריכים: ינואר-פברואר אפריל
המטרה העיקרית היא להשיג תצורה מאוחדת אחת לפריסת יישומים הן מקומית והן בייצור, ללא פעולות מורכבות, מחוץ לקופסה.
ל-werf נדרש גם מצב הפעלה בו יהיה נוח לערוך את קוד האפליקציה ולקבל משוב מיידי מהאפליקציה הפועלת לצורך איתור באגים.
אלגוריתם ניקוי חדש (חדש)
- גרסה: v1.1
- תאריכים: אפריל
בגרסה הנוכחית של werf v1.1 בהליך cleanup אין תנאי לניקוי תמונות עבור ערכת התיוג מבוססת התוכן - תמונות אלו יצטברו.
כמו כן, הגרסה הנוכחית של werf (v1.0 ו-v1.1) משתמשת במדיניות ניקוי שונה עבור תמונות המתפרסמות תחת סכימות התיוג: Git branch, Git tag או Git commit.
הומצא אלגוריתם חדש לניקוי תמונות המבוסס על ההיסטוריה של commits ב-Git, מאוחד עבור כל סכימות התיוג:
- שמור לא יותר מתמונות N1 המשויכות ל-N2 המחויבות האחרונות עבור כל git HEAD (ענפים ותגים).
- אחסן לא יותר מתמונות שלב N1 המשויכות ל-N2 המחויבות האחרונות עבור כל git HEAD (ענפים ותגים).
- אחסן את כל התמונות שנמצאות בשימוש במשאבי אשכול Kubernetes כלשהם (כל הקשרי ה-kube של קובץ התצורה ומרחבי השמות נסרקים; אתה יכול להגביל התנהגות זו עם אפשרויות מיוחדות).
- אחסן את כל התמונות המשמשות במניפסטים של תצורת משאבים שנשמרו במהדורות של Helm.
- ניתן למחוק תמונה אם היא לא משויכת לאף HEAD מ-git (לדוגמה, בגלל שה-HEAD המתאים עצמו נמחק) ואינה משמשת במניפסטים כלשהם באשכול Kubernetes ובמהדורות של Helm.
בניית תמונה מקבילה (↓)
- גרסה: v1.1
- תאריכים: ינואר-פברואר אפריל*
הגרסה הנוכחית של werf אוספת את התמונות והחפצים המתוארים ב werf.yaml, ברצף. יש צורך להקביל את תהליך הרכבת שלבים עצמאיים של תמונות וחפצים, כמו גם לספק פלט נוח ואינפורמטיבי.
* הערה: המועד הוסט עקב עדיפות מוגברת ליישום הרכבה מבוזרת, שתוסיף עוד יכולות קנה מידה אופקי, כמו גם השימוש ב-werf עם GitHub Actions. הרכבה מקבילה היא שלב האופטימיזציה הבא, המספק מדרגיות אנכית בעת הרכבת פרויקט אחד.
מעבר להגה 3 (↓)
- גרסה: v1.2
- תאריכים: פברואר-מרץ מאי*
כולל העברה לבסיס קוד חדש ודרך מוכחת ונוחה להעברת התקנות קיימות.
* הערה: המעבר ל-Helm 3 לא יוסיף תכונות משמעותיות ל-werf, מכיוון שכל תכונות המפתח של Helm 3 (מיזוג תלת-כיווני וללא מלט) כבר מיושמים ב-werf. יתר על כן, לוורף יש בנוסף לאלו שצוינו. עם זאת, המעבר הזה נשאר בתוכניות שלנו וייצא לפועל.
Jsonnet לתיאור תצורת Kubernetes (↓)
- גרסה: v1.2
- תאריכים: ינואר-פברואר אפריל-מאי
Werf יתמוך בתיאורי תצורה עבור Kubernetes בפורמט Jsonnet. יחד עם זאת, werf תישאר תואמת ל- Helm ותהיה בחירה בפורמט תיאור.
הסיבה היא שלתבניות Go, לדעת רבים, יש מחסום כניסה גבוה, וגם ההבנה של הקוד של התבניות הללו נפגעת.
נשקלת גם האפשרות של הצגת מערכות תיאור תצורה אחרות של Kubernetes (לדוגמה, Kustomize).
עבודה בתוך Kubernetes (↓)
- גרסה: v1.2
- תאריכים: אפריל-מאי מאי-יוני
מטרה: לוודא שהתמונות נבנות והאפליקציה מועברת באמצעות רצים ב-Kubernetes. הָהֵן. ניתן לבנות, לפרסם, לנקות ולפרוס תמונות חדשות ישירות מ-Kubernetes pods.
כדי ליישם את היכולת הזו, תחילה עליך להיות מסוגל לבנות תמונות מבוזרות (ראה נקודה למעלה).
זה גם דורש תמיכה במצב ההפעלה של הבונה ללא שרת Docker (כלומר בנייה דמוית Kaniko או בנייה במרחב משתמש).
Werf תתמוך בבנייה על Kubernetes לא רק עם Dockerfile, אלא גם עם בונה ה-Stapel שלה עם בנייה מחדש מצטברת ו-Ansible.
צעד לקראת פיתוח פתוח
אנחנו אוהבים את הקהילה שלנו (, ) ואנחנו רוצים שיותר ויותר אנשים יעזרו להפוך את werf לטוב יותר, יבינו את הכיוון שאליו אנחנו צועדים וישתתפו בפיתוח.
ממש לאחרונה הוחלט לעבור ל על מנת לחשוף את תהליך העבודה של הצוות שלנו. כעת תוכלו לראות את התוכניות המיידיות, כמו גם את העבודה הנוכחית בתחומים הבאים:
- ;
- ;
- ;
- .
נעשתה עבודה רבה בנושאים:
- הוסרו לא רלוונטיים.
- הקיימים מובאים לפורמט אחד, עם מספר מספיק של פרטים ופרטים.
- נוספו נושאים חדשים עם רעיונות והצעות.
כיצד להפעיל את גרסה v1.1
הגרסה זמינה כעת ב (בערוצים יציב и קשה כאבן עם זאת, יציבות יופיעו כאשר מתרחשת ייצוב ea עצמו כבר יציב מספיק לשימוש, כי עבר בערוצים אלפא и בטא). מוּפעָל בצורה הבאה:
source $(multiwerf use 1.1 ea)
werf COMMAND ...מסקנה
ארכיטקטורת אחסון השלבים החדשה ואופטימיזציות של Builders עבור בוני Stapel ו- Dockerfile פותחות את האפשרות ליישם בנייה מבוזרת ומקבילה ב-werf. תכונות אלו יופיעו בקרוב באותה מהדורה 1.1 ויהפכו לזמינים אוטומטית באמצעות מנגנון העדכון האוטומטי (עבור משתמשים ).
במהדורה זו, נוספה אסטרטגיית תיוג המבוססת על תוכן תמונה - תיוג מבוסס תוכן, שהפכה לאסטרטגיית ברירת המחדל. גם יומן הפקודות הראשי עובד מחדש: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
השלב המשמעותי הבא הוא הוספת מכלולים מבוזרים. בנייה מבוזרת הפכה לעדיפות גבוהה יותר מבנייה מקבילה מאז v1.0 מכיוון שהם מוסיפים ערך רב יותר ל-werf: קנה מידה אנכי של בונים ותמיכה בבונים ארעיים במערכות CI/CD שונות, כמו גם היכולת לבצע תמיכה רשמית בפעולות GitHub . לכן, מועדי היישום של הרכבות מקבילות הועברו. עם זאת, אנו פועלים ליישם את שתי האפשרויות בהקדם האפשרי.
עקבו אחר החדשות! ואל תשכחו לבקר אותנו ב כדי ליצור בעיה, למצוא בעיה קיימת ולהוסיף יתרון, ליצור יחסי ציבור, או פשוט לצפות בפיתוח הפרויקט.
נ.ב.
קרא גם בבלוג שלנו:
- «»
- «";
- סדרת הערות על חידושים ב-werf:
- «";
- «";
- «";
- «".
מקור: www.habr.com