הרכבה ופריסה דינמית של תמונות Docker עם werf באמצעות דוגמה של אתר תיעוד גרסה

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

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

מבוא: איך האתר עובד

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

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

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

בתפריט בחירת הגרסה באתר, הגרסאות העדכניות ביותר של werf זמינות בכל ערוץ. כברירת מחדל, לפי כתובת werf.io/documentation הגרסה של הערוץ היציב ביותר עבור המהדורה האחרונה נפתחת - היא גם מתווספת לאינדקס על ידי מנועי החיפוש. תיעוד לערוץ זמין בכתובות נפרדות (לדוגמה, werf.io/v1.0-beta/documentation עבור מהדורת בטא 1.0).

בסך הכל, באתר זמינות הגרסאות הבאות:

1. root (נפתח כברירת מחדל),
2. עבור כל ערוץ עדכון פעיל של כל מהדורה (לדוגמה, werf.io/v1.0-beta).

כדי ליצור גרסה ספציפית של אתר, באופן כללי, זה מספיק כדי להרכיב אותו באמצעות ג'קילעל ידי ריצה בספרייה /docs פקודה מתאימה למאגר werf (jekyll build), לאחר מעבר לתג Git של הגרסה הנדרשת.

נותר רק להוסיף כי:

• כלי השירות עצמו (werf) משמש להרכבה;
• תהליכי CI/CD בנויים על בסיס GitLab CI;
• וכל זה, כמובן, פועל ב-Kubernetes.

משימות

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

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

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

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

מתברר כי הרכבה תלויה בשינוי נתונים חיצוניים.

Реализация

בחירת גישה

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

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

ליתר דיוק, אנו אוספים שתי תמונות: אחת עבור מעגל הייצור, השנייה היא תמונה נוספת עבור מעגל הפיתוח. התמונה הנוספת משמשת (מושקת) רק במעגל ה-dev יחד עם הראשית ומכילה את גרסת האתר מה- review commit, והניתוב ביניהם מתבצע באמצעות משאבי Ingress.

werf vs git clone וחפצים

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

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

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

אנחנו כותבים werf.yaml

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

werf מאפשר לך להשתמש לך תבניות בקובץ התצורה שלך (werf.yaml), וזה מאפשר את זה ליצור תצורה תוך כדי תנועה תלוי בנתונים חיצוניים (מה שאתה צריך!). הנתונים החיצוניים במקרה שלנו הם מידע על גרסאות ומהדורות, שעל בסיסן אנו אוספים את המספר הנדרש של חפצים וכתוצאה מכך אנו מקבלים שתי תמונות: werf-doc и werf-dev לרוץ על מעגלים שונים.

נתונים חיצוניים מועברים דרך משתני סביבה. הנה ההרכב שלהם:

• RELEASES - שורה עם רשימת מהדורות והגרסה הנוכחית המתאימה של werf, בצורה של רשימת ערכים מופרדת ברווחים בפורמט <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. דוגמא: 1.0%v1.0.4-beta.20
• CHANNELS - שורה עם רשימת ערוצים והגרסה הנוכחית המתאימה של werf, בצורה של רשימת ערכים מופרדת ברווחים בפורמט <КАНАЛ>%<НОМЕР_ВЕРСИИ>. דוגמא: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION - גרסת שחרור werf שתוצג כברירת מחדל באתר (לא תמיד יש צורך להציג תיעוד לפי מספר הגרסה הגבוה ביותר). דוגמא: v1.0.4-beta.20
• REVIEW_SHA - hash של מחויבת הביקורת שממנה אתה צריך לבנות את הגרסה עבור לולאת הבדיקה.

משתנים אלו ימולאו בצינור GitLab CI, וכיצד בדיוק כתוב למטה.

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

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

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

• Version - גרסה שנוצרה (שם התג);
• Channel - שם ערוץ העדכון שעבורו נוצר החפץ;
• Commit - commit hash, אם החפץ נוצר עבור התחייבות ביקורת;
• הֶקשֵׁר.

תיאור תבנית חפץ

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

שם החפץ חייב להיות ייחודי. נוכל להשיג זאת, למשל, על ידי הוספת שם הערוץ (ערך המשתנה .Channel) כסיומת לשם של החפץ: artifact: doc-{{ .Channel }}. אבל אתה צריך להבין שכאשר מייבאים מחפצים, תצטרך להתייחס לאותם שמות.

בעת תיאור חפץ, נעשה שימוש בתכונת ה-werf הבאה: הַרכָּבָה. הרכבה המציינת את ספריית השירות build_dir מאפשר לך לשמור את המטמון של Jekyll בין ריצות צינור, אשר מאיץ באופן משמעותי את ההרכבה מחדש.

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

זה מיושם באמצעות ההצהרה המותנית if לך תבניות ועיצובים {{ $Root.Files.Get "releases.yml" | sha256sum }} בשלב שלבים. זה עובד באופן הבא: בעת בניית חפץ עבור גרסת השורש (משתנה .Channel שווה ל root) קובץ hash releases.yml משפיע על החתימה של כל השלב, מכיוון שהיא חלק מהשם של המשימה Ansible (פרמטר name). כך, בעת שינוי תוֹכֶן файла releases.yml החפץ המתאים יורכב מחדש.

אנא שימו לב גם לעבודה עם מאגר חיצוני. בתמונה של חפץ מ מאגר werf, רק הספרייה מתווספת /docs, ובהתאם לפרמטרים שעברו, הנתונים של התג או הביקורת הנדרשים מתווספים מיד.

כדי להשתמש בתבנית החפץ כדי ליצור תיאור של החפץ של הגרסאות המועברות של ערוצים ומהדורות, אנו מארגנים לולאה על המשתנה .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

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

באופן דומה, אך ללא לולאה, אנו קוראים לתבנית החפצים עבור "מקרים מיוחדים": עבור גרסת הבסיס, כמו גם הגרסה מ-review commit:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

שים לב שהחפץ עבור מחויבות הביקורת ייבנה רק אם המשתנה מוגדר .WerfReviewCommit.

החפצים מוכנים - זה הזמן להתחיל לייבא!

התמונה הסופית, שנועדה לרוץ על Kubernetes, היא NGINX רגיל עם קובץ תצורת שרת נוסף nginx.conf וסטטי מחפצים. בנוסף לארטיפקט של גרסת השורש של האתר, עלינו לחזור על הלולאה על המשתנה .WerfVersions כדי לייבא חפצים של גרסאות ערוץ ושחרור + פעל לפי כלל מתן השם של חפצים שאימצנו קודם לכן. מכיוון שכל חפץ מאחסן גרסאות של האתר לשתי שפות, אנו מייבאים אותן למקומות המסופקים על ידי התצורה.

תיאור התמונה הסופית werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

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

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

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

ההרכבה מוכנה! בואו נעבור ל-CI/CD ולניואנסים חשובים.

צינור ב- GitLab CI ותכונות של בנייה דינמית

בעת הפעלת ה-build עלינו להגדיר את משתני הסביבה בהם נעשה שימוש werf.yaml. זה לא חל על המשתנה REVIEW_SHA, אותו נגדיר בעת קריאת pipeline מה-GitHub hook.

אנו ניצור את הנתונים החיצוניים הדרושים בסקריפט של Bash generate_artifacts, שייצור שני חפצי צינור של GitLab:

• файл releases.yml עם נתוני שחרור,
• файл common_envs.sh, המכיל את משתני הסביבה המיועדים לייצוא.

תוכן הקובץ generate_artifacts תמצא אצלנו מאגרים עם דוגמאות. רכישת הנתונים עצמה אינה נושא המאמר, אלא הקובץ common_envs.sh חשוב לנו, כי העבודה של werf תלויה בזה. דוגמה לתוכן שלו:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

אתה יכול להשתמש בפלט של סקריפט כזה, למשל, באמצעות הפונקציה Bash source.

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

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

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

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

תוכן הבמה בנייה מראש файла .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

לאחר לכידת הנתונים החיצוניים ב-Artifact, אתה יכול לבנות ולפרוס באמצעות שלבי הצינור הסטנדרטיים של GitLab CI: Build and Deploy. אנו משיקים את הצינור עצמו באמצעות הוקס ממאגר GitHub werf (כלומר, כאשר יש שינויים במאגר ב- GitHub). ניתן למצוא נתונים עבורם במאפייני הפרויקט של GitLab במדור הגדרות CI/CD -> מפעילי צינור, ולאחר מכן צור את ה-Webhook המתאים ב-GitHub (הגדרות -> Webhooks).

שלב הבנייה ייראה כך:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

GitLab יוסיף שני חפצים מהשלב לשלב הבנייה בנייה מראש, אז אנו מייצאים משתנים עם נתוני קלט מוכנים באמצעות המבנה source common_envs.sh. אנו מתחילים את שלב הבנייה בכל המקרים, למעט השקת הצינור לפי לוח זמנים. על פי לוח הזמנים נפעיל צנרת לניקיון - במקרה זה אין צורך בביצוע הרכבה.

בשלב הפריסה, נתאר שתי משימות - בנפרד לפריסה למעגלי ייצור ופיתוח, באמצעות תבנית YAML:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

המשימות שונות במהות רק בציון ההקשר של האשכול שאליו werf צריכה לבצע את הפריסה (WERF_KUBE_CONTEXT), והגדרת משתני סביבת הלולאה (environment.name и environment.url), אשר משמשים לאחר מכן בתבניות תרשים Helm. לא נספק את תוכן התבניות, כי... אין שם שום דבר מעניין לנושא המדובר, אבל אתה יכול למצוא אותם ב מאגרים עבור המאמר.

המגע הסופי

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

כדי ליישם תצטרך:

• הוסף שלב ניקוי ל .gitlab-ci.yml;
• הוסף ביצוע תקופתי של משימת ניקוי;
• הגדר משתנה סביבה עם אסימון גישה לכתיבה.

הוספת שלב ניקוי ל .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

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

הוספת משימת ניקיון עם לוח הזמנים הנדרש מתבצעת ב CI/CD ->
לוחות זמנים.

זהו: פרויקט ב-Docker Registry כבר לא יצמח כל הזמן מתמונות שאינן בשימוש.

בסוף החלק המעשי, הרשו לי להזכיר לכם שהרישומים המלאים מהמאמר זמינים ב Git:

• .gitlab-ci.yml;
• werf.yaml.

תוצאה

1. קיבלנו מבנה הרכבה לוגי: חפץ אחד לכל גרסה.
2. ההרכבה היא אוניברסלית ואינה דורשת שינויים ידניים כאשר יוצאות גרסאות חדשות של werf: התיעוד באתר מתעדכן אוטומטית.
3. שתי תמונות מורכבות לקווי מתאר שונים.
4. זה עובד מהר, כי נעשה שימוש ב-Caching ככל האפשר - כאשר משוחררת גרסה חדשה של werf או הוק של GitHub נקרא לביצוע ביקורת, רק החפץ המתאים עם הגרסה ששונתה נבנה מחדש.
5. אין צורך לחשוב על מחיקת תמונות שאינן בשימוש: ניקוי לפי מדיניות werf ישמור על הסדר של ה-Docker Registry.

ממצאים

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

נ.ב.

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

• «הפעלת פקודות תוך אספקת מהדורת אפליקציה חדשה ל-Kubernetes";
• «בנה ופריסה של שירותי מיקרו מאותו סוג עם werf ו-GitLab CI";
• «שימוש ב-werf כדי לפרסם תרשימי Helm מורכבים";
• «הצגת werf 1.0 stable: מה הקשר של GitOps לזה, סטטוס ותוכניות".

מקור: www.habr.com