ProHoster > блог > Администрација > Динамично склопување и распоредување на слики на Docker со werf користејќи го примерот на верзиирана локација за документација

Динамично склопување и распоредување на слики на Docker со werf користејќи го примерот на верзиирана локација за документација

Веќе разговаравме за нашата алатка GitOps повеќе од еднаш. верф, а овој пат би сакале да го споделиме нашето искуство во склопување на страницата со документацијата на самиот проект - werf.io (неговата руска верзија е en.werf.io). Ова е обична статична локација, но нејзиното склопување е интересно по тоа што е изградено со користење на динамичен број артефакти.

Динамично склопување и распоредување на слики на Docker со werf користејќи го примерот на верзиирана локација за документација

Одете во нијансите на структурата на страницата: генерирање заедничко мени за сите верзии, страници со информации за изданија итн. - ние нема. Наместо тоа, да се фокусираме на прашањата и карактеристиките на динамичкото склопување и малку на придружните процеси CI/CD.

Вовед: како работи страницата

За почеток, документацијата на werf се чува заедно со нејзиниот код. Ова наметнува одредени развојни барања кои генерално се надвор од опсегот на овој член, но во најмала рака може да се каже дека:

  • Новите функции на werf не треба да се објавуваат без ажурирање на документацијата и, обратно, какви било промени во документацијата подразбираат објавување на нова верзија на werf;
  • Проектот има прилично интензивен развој: нови верзии може да се издаваат неколку пати на ден;
  • Сите рачни операции за распоредување на локација со нова верзија на документација се барем досадни;
  • Проектот прифаќа семантички пристап верзии, со 5 канали за стабилност. Процесот на ослободување вклучува последователно поминување на верзиите низ канали со цел да се зголеми стабилноста: од алфа до карпеста цврстина;
  • Веб-страницата има верзија на руски јазик, која „живее и развива“ (т.е., чија содржина е ажурирана) паралелно со главната верзија (т.е. англиски јазик).

За да ја скриеме сета оваа „внатрешна кујна“ од корисникот, нудејќи му нешто што „само функционира“, направивме посебна алатка за инсталација и ажурирање на werf - Дали мултиверф. Само треба да го наведете бројот на издавање и каналот за стабилност што сте подготвени да ги користите, а multiwerf ќе провери дали има нова верзија на каналот и ќе ја преземе доколку е потребно.

Во менито за избор на верзии на веб-локацијата, најновите верзии на werf се достапни во секој канал. Стандардно, по адреса werf.io/documentation се отвора верзијата на најстабилниот канал за најновото издание - исто така е индексирана од пребарувачите. Документацијата за каналот е достапна на посебни адреси (на пример, werf.io/v1.0-beta/documentation за бета издание 1.0).

Севкупно, страницата ги има на располагање следниве верзии:

  1. root (се отвора стандардно),
  2. за секој активен канал за ажурирање на секое издание (на пример, werf.io/v1.0-beta).

За да генерирате специфична верзија на страницата, воопшто, доволно е да ја составите користејќи Jekyllсо трчање во директориумот /docs соодветната команда во складиштето на werf (jekyll build), по префрлувањето на ознаката git на потребната верзија.

Останува само да се додаде дека:

  • самата алатка (werf) се користи за склопување;
  • CI/CD процесите се изградени врз основа на GitLab CI;
  • и сето ова, се разбира, работи во Кубернетес.

задачи

Сега, да формулираме задачи што ги земаат предвид сите опишани специфики:

  1. По промената на верзијата на werf на кој било канал за ажурирање документацијата на страницата треба автоматски да се ажурира.
  2. За развој треба понекогаш да можете прегледајте ги верзиите за преглед на страницата.

Веб -страницата мора да се преработи по промената на верзијата на кој било канал од соодветните ознаки за Git, но во процесот на градење на сликата ќе ги добиеме следниве карактеристики:

  • Бидејќи списокот на верзии на каналите се менува, потребно е само повторно да се изгради документацијата за каналите каде што верзијата е променета. На крајот на краиштата, повторното градење на сè не е многу убаво.
  • Сетот на канали за изданија може да се промени. Во одреден момент во времето, на пример, можеби нема да има верзија на каналите постабилна од изданието со ран пристап 1.1, но со текот на времето тие ќе се појават - во овој случај, зарем не треба рачно да го менувате склопот?

Излегува дека склопувањето зависи од промената на надворешните податоци.

Реализация

Избор на пристап

Алтернативно, можете да ја извршите секоја потребна верзија како посебен дел во Kubernetes. Оваа опција подразбира поголем број на објекти во кластерот, кој ќе расте со зголемувањето на бројот на стабилни верф-изданија. И ова, пак, подразбира покомплексно одржување: секоја верзија има свој HTTP сервер и со мало оптоварување. Се разбира, ова повлекува и поголеми трошоци за ресурси.

Ние тргнавме по истиот пат склопување на сите потребни верзии во една слика. Компилираната статика на сите верзии на страницата се наоѓа во контејнер со NGINX, а сообраќајот до соодветното распоредување доаѓа преку NGINX Ingress. Едноставна структура - апликација без државјанство - ви овозможува лесно да го размерите распоредувањето (во зависност од оптоварувањето) користејќи самиот Kubernetes.

Да бидеме попрецизни, собираме две слики: едната за производното коло, втората е дополнителна за колото на dev. Дополнителната слика се користи (лансирана) само на Dev Circuit заедно со главното и ја содржи верзијата на страницата од извршувањето на прегледот, а рутирањето меѓу нив се изведува со употреба на Ingress Resources.

werf vs git клон и артефакти

Како што веќе споменавме, за да генерирате статика на страницата за одредена верзија на документацијата, треба да изградите со префрлување на соодветната ознака на складиштето. Можете исто така да го направите ова со клонирање на складиштето секој пат кога го градите, избирајќи ги соодветните ознаки од списокот. Сепак, ова е прилично интензивна операција и, згора на тоа, бара пишување нетривијални инструкции... Друг сериозен недостаток е тоа што со овој пристап не постои начин да се кешира нешто за време на склопувањето.

Овде ни доаѓа на помош самата алатка werf која спроведува паметно кеширање и ви овозможува да користите надворешни складишта. Користењето на werf за додавање код од складиштето значително ќе го забрза градењето, бидејќи werf суштински еднаш го клонира складиштето и потоа го извршува само fetch ако е потребно. Покрај тоа, кога додаваме податоци од складиштето, можеме да ги избереме само потребните директориуми (во нашиот случај ова е директориумот docs), со што значително ќе се намали количината на додадени податоци.

Бидејќи ekекил е алатка дизајнирана за составување статички податоци и не е потребна во конечната слика, би било логично да се соберат во артефакт на верф, и во конечната слика увезете го само резултатот од компилацијата.

Пишуваме werf.yaml

Значи, решивме дека ќе ја собереме секоја верзија во посебен артефакт на WERF. Сепак ние не знаеме колку од овие артефакти ќе има за време на склопувањето, така што не можеме да напишеме фиксна конфигурација за изградба (строго кажано, сè уште можеме, но нема да биде целосно ефективна).

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 — хаш на заложбата за преглед од која треба да ја изградите верзијата за тест циклусот.

Овие променливи ќе бидат пополнети во цевководот GitLab CI, и како точно е напишано подолу.

Пред сè, за погодност, дефинираме во werf.yaml Одете променливи на шаблоните, доделувајќи им вредности од променливите на околината:

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

Описот на артефактот за составување на статичната верзија на страницата е генерално ист за сите случаи што ни се потребни (вклучувајќи го и генерирањето на root верзијата, како и верзијата за колото на dev). Затоа, ќе го преместиме во посебен блок користејќи ја функцијата define - за последователна повторна употреба include. Следниве аргументи ќе ги пренесеме до образецот:

  • Version — генерирана верзија (име на ознака);
  • Channel — името на каналот за ажурирање за кој е генериран артефактот;
  • Commit — извршете хаш, ако артефактот е генериран за заложба за преглед;
  • контекст.

Опис на шаблонот за артефакт

{{- 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 }}. Но, треба да разберете дека при увоз од артефакти, ќе треба да се повикате на истите имиња.

Кога се опишува артефакт, се користи следнава карактеристика на верф: монтирање. Монтирање што го покажува директориумот за услуги build_dir ви овозможува да го зачувате кешот на Jekyll помеѓу цевководите, што значително го забрзува повторното склопување.

Можеби сте ја забележале и употребата на датотеката releases.yml е датотека YAML со податоци за издавање побарани од github.com (артефакт добиен при извршување на цевковод). Потребен е при составувањето на страницата, но во контекст на статијата ни е интересен бидејќи зависи од нејзината состојба повторно составување на само еден артефакт — артефакт на root верзијата на страницата (не е потребен во други артефакти).

Ова се спроведува со користење на условната изјава if Одете шаблони и дизајни {{ $Root.Files.Get "releases.yml" | sha256sum }} во фаза фази. Работи на следниов начин: кога се гради артефакт за root верзијата (променлива .Channel е еднаква на root) хаш на датотеката releases.yml влијае на потписот на целата фаза, бидејќи е дел од името на Ansible Task (параметар 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 -}}

Бидејќи јамката ќе генерира неколку артефакти (се надеваме дека е така), неопходно е да се земе предвид сепараторот меѓу нив - низата --- (За повеќе информации за синтаксата на конфигурациските датотеки, видете документација). Како што беше дефинирано претходно, кога повикуваме шаблон во циклус, ги пренесуваме параметрите на верзијата, URL-то и коренскиот контекст.

Слично, но без јамка, го нарекуваме шаблонот за артефакт за „посебни случаи“: за root верзијата, како и верзијата од задолжението за преглед:

{{ 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 и статични од артефакти. Покрај артефактот на root верзијата на страницата, треба да ја повториме јамката на променливата .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, содржи само две верзии на страницата: верзијата од извршената проверка и коренската верзија на страницата (има општи средства и, ако се сеќавате , објави податоци). Така, дополнителната слика ќе се разликува од главната само во делот за увоз (и, се разбира, во името):

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, но со цел да чистење со полиси Докерските слики во werf работеа за сликата на werf-dev, ќе оставиме да се изгради само со артефактот на root верзијата (во секој случај веќе е изграден), за да се поедностави структурата на гасоводот.

Склопот е подготвен! Да преминеме на CI/CD и важните нијанси.

Pipeline во GitLab CI и карактеристики на динамичното градење

Кога ја извршуваме изградбата, треба да ги поставиме променливите на околината што се користат во werf.yaml. Ова не се однесува на променливата REVIEW_SHA, која ќе ја поставиме при повикување на гасоводот од куката на GitHub.

Ќе ги генерираме потребните надворешни податоци во скрипта Bash generate_artifacts, кој ќе генерира два артефакти на гасоводот GitLab:

  • датотеката releases.yml со податоци за ослободување,
  • датотеката common_envs.sh, што ги содржи променливите на животната средина што треба да се извезат.

Содржина на датотеката generate_artifacts ќе најдете во нашата складишта со примери. Самото примање на податоците не е тема на статијата, туку датотека common_envs.sh е важно за нас, бидејќи работата на верфот зависи од тоа. Пример за неговата содржина:

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

Откако ги снимивте надворешните податоци во артефактот, можете да изградите и распоредите користејќи ги стандардните фази на гасоводот GitLab CI: Изградба и распоредување. Ние го лансираме самиот гасовод со употреба на куки од складиштето WERF Github (т.е., кога има промени во складиштето Github). Податоците за нив може да се најдат во својствата на проектот Гитлаб во делот CI/CD Settings -> Pipeline triggers, а потоа креирајте ја соодветната Webhook во GitHub (Поставки -> Веб-куки).

Фазата на градење ќе изгледа вака:

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 chart. Содржините на шаблоните нема да ги даваме, бидејќи ... нема ништо интересно за темата во прашање, но можете да ги најдете во складишта за статијата.

Конечен допир

Бидејќи верзиите на 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 веќе нема постојано да расте од неискористени слики.

На крајот од практичниот дел, дозволете ми да ве потсетам дека целосните огласи од статијата се достапни во оди:

Резултира

  1. Добивме логичка структура на склопување: еден артефакт по верзија.
  2. Склопот е универзален и не бара рачни промени кога се објавуваат нови верзии на werf: документацијата на веб-локацијата автоматски се ажурира.
  3. Две слики се собрани за различни контури.
  4. Работи брзо, бидејќи Кеширањето се користи колку што е можно повеќе - кога е објавена нова верзија на werf или кога ќе се повика кука на GitHub за да се изврши преглед, само соодветниот артефакт со изменетата верзија се обновува.
  5. Нема потреба да размислувате за бришење неискористени слики: чистењето според правилата на werf ќе го одржува Докерскиот регистар во ред.

Наоди

  • Користењето на werf му овозможува на склопот да работи брзо поради кеширањето и на самиот склоп и на кеширањето при работа со надворешни складишта.
  • Работата со надворешни складишта на Git ја елиминира потребата да се клонира целото складиште секој пат или повторно да се измисли тркалото со незгодна логика за оптимизација. werf користи кеш и го прави клонирањето само еднаш, а потоа користи fetch и само кога е потребно.
  • Способност да се користат шаблони Go во конфигурациската датотека за изградба werf.yaml Ви овозможува да опишете склоп чиј резултат зависи од надворешните податоци.
  • Користењето на монтирање во werf значително го забрзува собирањето на артефакти - поради кешот, кој е заеднички за сите цевководи.
  • werf го олеснува конфигурирањето на чистењето, што е особено важно кога се гради динамично.

PS

Прочитајте и на нашиот блог:

Извор: www.habr.com

Додадете коментар