כעת אתה יכול לבנות תמונות Docker ב-werf באמצעות Dockerfile רגיל

מוטב מאוחר מלעולם לא. או איך כמעט עשינו טעות רצינית בכך שאין לנו תמיכה ב-Dockerfiles רגילים לבניית תמונות יישומים.

נדבר על werf - כלי עזר GitOps שמשתלב עם כל מערכת CI/CD ומספק ניהול של כל מחזור החיים של האפליקציה, המאפשר:

• לאסוף ולפרסם תמונות,
• לפרוס יישומים ב- Kubernetes,
• למחוק תמונות שאינן בשימוש באמצעות מדיניות מיוחדת.

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

רקע: אספן תמונות משלך

זה מה שקרה עם אספן התמונות ב-werf: ה-Dockerfile הרגיל לא הספיק לנו. אם תעיף מבט מהיר בהיסטוריה של הפרויקט, בעיה זו הופיעה כבר בגרסאות הראשונות של werf (ואז עדיין המכונה dapp).

תוך כדי יצירת כלי לבניית יישומים לתוך תמונות Docker, מהר מאוד הבנו ש- Dockerfile לא מתאים לנו לכמה משימות מאוד ספציפיות:

1. הצורך לבנות יישומי אינטרנט קטנים טיפוסיים לפי הסכימה הסטנדרטית הבאה:
   • להתקין תלות של יישומים כלל-מערכתיים,
   • התקן חבילה של ספריות תלות באפליקציות,
   • לאסוף נכסים,
   • והכי חשוב, עדכנו את הקוד בתמונה במהירות וביעילות.
2. כאשר מתבצעים שינויים בקבצי הפרויקט, על הבונה ליצור במהירות שכבה חדשה על ידי החלת תיקון על הקבצים שהשתנו.
3. אם קבצים מסוימים השתנו, יש צורך לבנות מחדש את השלב התלוי המתאים.

היום לאספן שלנו יש הרבה אפשרויות אחרות, אבל אלו היו הרצונות והדחפים הראשוניים.

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

תצורה ישנה עבור dapp ברובי

התצורה הנוכחית עבור werf ב-YAML

גם מנגנון האספן השתנה עם הזמן. בהתחלה, פשוט יצרנו קובץ Dockerfile זמני מהתצורה שלנו, ואז התחלנו להריץ הוראות הרכבה בקונטיינרים זמניים ולבצע commit.

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

מודעות לבעיה

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

במקום לענות על שאלה זו, אנו מציעים פתרון. מה אם כבר יש לך Dockerfile (או קבוצה של Dockerfile) ואתה רוצה להשתמש ב-werf?

NB: דרך אגב, למה בכלל תרצה להשתמש ב-werf? התכונות העיקריות מסתכמות בנקודות הבאות:

• מחזור ניהול יישומים מלא כולל ניקוי תמונה;
• היכולת לנהל את ההרכבה של מספר תמונות בו-זמנית מתצורה אחת;
• תהליך פריסה משופר עבור תרשימים תואמי Helm.

רשימה מלאה יותר שלהם ניתן למצוא בכתובת עמוד הפרויקט.

אז, אם קודם לכן היינו מציעים לשכתב את ה- Dockerfile בתצורה שלנו, עכשיו נגיד בשמחה: "תן ל-werf לבנות את ה- Dockerfile שלך!"

כיצד להשתמש?

היישום המלא של תכונה זו הופיע במהדורה werf v1.0.3-beta.1. העיקרון הכללי הוא פשוט: המשתמש מציין את הנתיב ל-Dockerfile קיים ב-werf config, ולאחר מכן מפעיל את הפקודה werf build... וזהו - werf תרכיב את התמונה. בואו נסתכל על דוגמה מופשטת.

בואו נכריז על הבא Dockerfile בשורש הפרויקט:

FROM ubuntu:18.04
RUN echo Building ...

ואנחנו נכריז werf.yamlשמשתמש בזה Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

את כל! שמאלה לרוץ werf build:

בנוסף, אתה יכול להצהיר על הדברים הבאים werf.yaml כדי לבנות מספר תמונות מ-Dockerfiles שונים בבת אחת:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

לבסוף, הוא תומך גם בהעברת פרמטרי בנייה נוספים, כגון --build-arg и --add-host - דרך werf config. תיאור מלא של תצורת התמונה של Dockerfile זמין בכתובת דף תיעוד.

איך זה עובד?

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

1. כל תמונה הבנויה מ-Dockerfile מורכבת משלב אחד שנקרא dockerfile (תוכל לקרוא עוד על אילו שלבים נמצאים ב-werf כאן).
2. לבמה dockerfile werf מחשב חתימה שתלויה בתוכן של תצורת Dockerfile. כאשר תצורת Dockerfile משתנה, חתימת הבמה משתנה dockerfile ו-werf יוזם בנייה מחדש של השלב הזה עם תצורת Dockerfile חדשה. אם החתימה לא משתנה, werf לוקח את התמונה מהמטמון (פרטים נוספים על השימוש בחתימות ב-werf תוארו ב הדוח הזה).
3. לאחר מכן, ניתן לפרסם את התמונות שנאספו באמצעות הפקודה werf publish (או werf build-and-publish) והשתמש בו לפריסה ל-Kubernetes. תמונות שפורסמו ל-Docker Registry ינוקו באמצעות כלי ניקוי סטנדרטיים של werf, כלומר. תמונות ישנות (יותר מ-N ימים), תמונות הקשורות לסניפי Git שאינם קיימים ומדיניות אחרת ינוקו אוטומטית.

פרטים נוספים על הנקודות המתוארות כאן ניתן למצוא בתיעוד:

• תהליך פרסום;
• אינטגרציה עם תהליך הפריסה של Kubernetes;
• תהליך ניקיון.

הערות ואמצעי זהירות

1. כתובת URL חיצונית אינה נתמכת ב-ADD

נכון לעכשיו אין תמיכה בשימוש בכתובת URL חיצונית בהנחיה ADD. Werf לא ייזום בנייה מחדש כאשר המשאב בכתובת ה-URL שצוינה משתנה. אנו מתכננים להוסיף תכונה זו בקרוב.

2. אתה לא יכול להוסיף .git לתמונה

באופן כללי, הוספת ספרייה .git בתמונה - מנהג רע מרושע והנה הסיבה:

1. אם .git נשאר בתמונה הסופית, זה מפר את העקרונות אפליקציית 12 גורמים: מכיוון שהתמונה הסופית חייבת להיות מקושרת ל-commit בודד, זה לא אמור להיות אפשרי לעשות git checkout התחייבות שרירותית.
2. .git מגדיל את גודל התמונה (המאגר יכול להיות גדול בגלל העובדה שפעם נוספו לו קבצים גדולים ואז נמחקו). הגודל של עץ עבודה המשויך רק ל-commit ספציפי לא יהיה תלוי בהיסטוריה של הפעולות ב-Git. במקרה זה, התוספת וההסרה שלאחר מכן .git מהתמונה הסופית לא יעבוד: התמונה עדיין תרכוש שכבה נוספת - כך פועל Docker.
3. Docker יכול ליזום בנייה מחדש מיותרת, גם אם אותו commit נבנה, אבל מעצי עבודה שונים. לדוגמה, GitLab יוצר מדריכים משובטים נפרדים ב /home/gitlab-runner/builds/HASH/[0-N]/yourproject כאשר הרכבה מקבילית מופעלת. ההרכבה הנוספת תהיה בשל העובדה שהספרייה .git שונה בגרסאות משובלות שונות של אותו מאגר, גם אם אותו commit נבנה.

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

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

סך הכל

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

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

אז, אם פתאום יש לך כמה קבצי Dockerfiles שוכבים מסביב... נסה את זה werf!

נ.ב. רשימת תיעוד בנושא

• מדריכים להתחלה מהירה;
• תצורות בונה dockerfile;
• מכשיר שלבים בוורף;
• תהליך פרסום תמונות;
• אינטגרציה עם תהליך הפריסה של Kubernetes;
• תהליך ניקיון;
• Stapel Builder כחלופה ל- Dockerfile.

קרא גם בבלוג שלנו: "werf - הכלי שלנו עבור CI / CD ב-Kubernetes (סקירה כללית ודוח וידאו)".

מקור: www.habr.com