Динамично изграждане и внедряване на Docker изображения с werf на примера на сайт с документация с версии

Вече сме говорили за нашия инструмент GitOps повече от веднъж werf, като този път бихме искали да споделим опита от изграждането на сайт с документацията на самия проект - werf.io (руската му версия е en.werf.io). Това е нормален статичен сайт, но изграждането му е интересно, защото е изградено с помощта на динамичен брой артефакти.

Влезте в нюансите на структурата на сайта: генериране на общо меню за всички версии, страници с информация за версии и т.н. - ние няма. Вместо това, нека се съсредоточим върху проблемите и спецификата на динамичното сглобяване и малко върху свързаните CI/CD процеси.

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

Нека започнем с факта, че документацията на werf се съхранява заедно с нейния код. Това налага определени изисквания за разработка, които обикновено са извън обхвата на тази статия, но като минимум може да се каже, че:

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

За да скрием цялата тази "вътрешна кухня" от потребителя, предлагайки му нещо, което "просто работи", направихме отделен инструмент за инсталиране и актуализиране на werf - multiwerf. Просто трябва да посочите номера на версията и канала за стабилност, който сте готови да използвате, и multiwerf ще провери дали има нова версия на канала и ще я изтегли, ако е необходимо.

Най-новите версии на werf във всеки канал са достъпни в менюто за избор на версия на сайта. По подразбиране при werf.io/документация отваря се версията на най-стабилния канал за последното издание - той също се индексира от търсачките. Документация за канала е достъпна на отделни адреси (напр. werf.io/v1.0-beta/документация за бета версия 1.0).

Общо сайтът разполага със следните версии:

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

За да генерирате конкретна версия на сайта, в общия случай е достатъчно да я компилирате с помощта на Джекилкато стартирате в директорията /docs werf хранилище със съответната команда (jekyll build), след като преминете към Git тага на необходимата версия.

Остава само да добавим, че:

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

задачи

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

1. След промяна на версията на werf на всеки канал за актуализация документацията на сайта трябва да се актуализира автоматично.
2. За развитие е необходимо понякога да можете прегледайте визуализациите на сайта.

Прекомпилирането на сайта трябва да се извърши след промяна на версията на всеки канал от съответните Git тагове, но в процеса на изграждане на изображението ще получим следните функции:

• Тъй като списъкът с версии на каналите се променя, е необходимо само да се изгради отново документацията за каналите, където версията е променена. В крайна сметка възстановяването на всичко наново не е много красиво.
• Наборът от канали за издания може да се промени. В даден момент, например, може да няма версия на каналите, по-стабилна от изданието за ранен достъп 1.1, но с течение на времето те ще се появят - в този случай не променяйте сборката на ръка?

Оказва се, че сглобяването зависи от промяна на външни данни.

Изпълнение

Избор на подход

Като алтернатива можете да стартирате всяка необходима версия като отделен пакет в Kubernetes. Тази опция предполага по-голям брой обекти в клъстера, който ще расте с увеличаване на броя на стабилните версии на werf. А това от своя страна предполага по-сложна поддръжка: всяка версия има собствен HTTP сървър и с малко натоварване. Разбира се, това води и до по-високи разходи за ресурси.

Тръгнахме по пътя сглобяване на всички необходими версии в едно изображение. Компилираната статика на всички версии на сайта е в контейнер с NGINX, а трафикът към съответното разполагане идва през NGINX Ingress. Една проста структура - приложение без състояние - улеснява мащабирането на Разгръщане (в зависимост от натоварването) с помощта на самия Kubernetes.

За да бъдем по-точни, изграждаме две изображения: едното е за производствения цикъл, второто е допълнително за цикъла за разработка. Допълнителното изображение се използва (стартира) само на dev loop заедно с основното и съдържа версията на сайта от прегледа на комита, а маршрутизирането между тях се извършва с помощта на ресурси на Ingress.

werf срещу git клонинг и артефакти

Както вече споменахме, за да генерирате статика на сайта за конкретна версия на документацията, трябва да изградите, като превключите към съответния етикет на хранилището. Можете също да направите това, като клонирате хранилището всеки път, когато изграждате, като избирате подходящите тагове от списъка. Това обаче е доста ресурсоемка операция и освен това изисква писане на нетривиални инструкции ... Друг сериозен недостатък е, че при този подход няма начин да се кешира нещо по време на асемблирането.

Тук самата помощна програма werf идва на помощ, внедрявайки интелигентно кеширане и ви позволява да използвате външни хранилища. Използването на werf за добавяне на код от хранилището значително ще ускори изграждането, защото werf по същество клонира хранилището веднъж и след това го прави само fetch ако е необходимо. Освен това, когато добавяме данни от хранилището, можем да изберем само необходимите директории (в нашия случай това е директорията docs), което значително ще намали количеството добавени данни.

Тъй като Jekyll е инструмент за компилиране на статики и не е необходим в крайното изображение, би било логично да се компилира до werf артефакт, и в крайното изображение импортирайте само резултат от компилация.

Пишем 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 pipeline, а как точно е написано по-долу.

На първо място, за удобство, ние определяме в 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 }}. Но трябва да разберете, че когато импортирате от артефакти, ще трябва да се позовавате на същите имена.

При описване на артефакт се използва тази характеристика на werf, като напр монтаж. Монтиране със сервизна директория build_dir ви позволява да запазвате кеша на Jekyll между стартиранията на тръбопровода, което значително ускорява повторното сглобяване.

Освен това може да сте забелязали използването на файла releases.yml е YAML файл с данни за изданието, поискани от github.com (артефакт, получен чрез изпълнение на конвейера). Необходим е при компилирането на сайта, но в контекста на статията ни е интересен, защото зависи от състоянието му възстановяване само на един артефакт - артефакт на сайта на основната версия (не е необходим в други артефакти).

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

защото цикълът ще генерира няколко артефакта (надяваме се да е така), трябва да вземете предвид разделителя между тях - последователността --- (За подробности относно синтаксиса на конфигурационния файл вижте документация). Както беше дефинирано по-рано, когато извикваме шаблона в цикъл, ние предаваме параметри на версията, URL адрес и корен на контекста.

По подобен начин, но без цикъл, наричаме шаблона на артефакта за „специални случаи“: за основната версия, както и версията от ангажимента за преглед:

{{ 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 -}}

Допълнителното изображение, което работи заедно с основното във веригата за разработка, съдържа само две версии на сайта: версията от ангажимента за преглед и основната версия на сайта (има общи активи и, ако си спомняте, данни за издания). По този начин допълнителното изображение ще се различава от основното само в секцията за импортиране (и, разбира се, в името):

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 и характеристики на динамично сглобяване

Когато изпълняваме компилацията, трябва да зададем променливите на средата, използвани в werf.yaml. Това не се отнася за променливата REVIEW_SHA, която ще зададем, когато извикваме конвейера от куката на GitHub.

Ние ще прехвърлим формирането на необходимите външни данни към 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

След като коригирате външни данни в артефакт, можете да изградите и внедрите, като използвате стандартните етапи на GitLab CI pipeline: Build and Deploy. Ние стартираме самия тръбопровод чрез кукички от хранилището на werf GitHub (тоест, когато се правят промени в хранилището на GitHub). Данните за тях могат да бъдат взети в свойствата на проекта GitLab в секцията CI / CD настройки -> Задействания на тръбопроводаи след това създайте съответния 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. Започваме етапа на изграждане във всички случаи, с изключение на планираното пускане на тръбопровода. Според графика ще пуснем тръбопровод за почистване - в този случай не е необходимо да строите.

На етапа на внедряване ще опишем две задачи - поотделно за внедряване в производствени и dev вериги, използвайки 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 постоянно ще расте. Поради това е наложително да конфигурирате автоматично почистване на изображения според правилата. Много е лесно да направите това.

Изпълнението ще изисква:

• Добавете стъпка за почистване към .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 с токен, който има права за изтриване на изображения в регистъра на Docker (автоматично издаденият токен за задача GitLab CI няма такова права). Токенът трябва да бъде въведен предварително в GitLab и неговата стойност трябва да бъде посочена в променливата на средата WERF_IMAGES_CLEANUP_PASSWORD проект (Настройки на CI/CD -> Променливи).

Добавянето на задача за почистване с необходимия график се извършва в CI/CD ->
Списъци.

Всичко: проектът в регистъра на Docker вече няма да нараства постоянно от неизползвани изображения.

В края на практическата част напомням, че пълните списъци от статията са налични в отивам:

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

Резултат

1. Имаме логична структура на изграждане: един артефакт на версия.
2. Сглобката е универсална и не изисква ръчни промени, когато се пускат нови версии на werf: документацията на сайта се актуализира автоматично.
3. Две изображения са сглобени за различни контури.
4. Работи бързо, защото кеширането се използва максимално — когато се пусне нова версия на werf или се извика кука на GitHub за ангажимент за преглед — само съответният артефакт с модифицираната версия се изгражда отново.
5. Няма нужда да мислите за изтриване на неизползвани изображения: почистването чрез политики на werf ще поддържа регистъра на Docker в ред.

Данни

• Използването на werf позволява на сглобката да работи бързо поради кеширането както на самата сглобка, така и на кеширането при работа с външни хранилища.
• Работата с външни хранилища на Git елиминира необходимостта от клониране на хранилището всеки път напълно или преоткриване на колелото с сложна логика за оптимизация. werf използва кеша и прави клонирането само веднъж и след това използва fetch и то само при нужда.
• Възможност за използване на Go-templates в конфигурационния файл за изграждане werf.yaml ви позволява да опишете сборка, чийто резултат зависи от външни данни.
• Използването на mount в werf значително ускорява събирането на артефакти - поради кеша, който е общ за всички конвейери.
• werf улеснява персонализирането на почистването, което е особено вярно за динамичните компилации.

PS

Прочетете също в нашия блог:

• «Изпълнение на команди по време на доставката на нова версия на приложение в Kubernetes»;
• «Изграждане и внедряване на подобни микроуслуги с werf и GitLab CI»;
• «Използване на werf за внедряване на сложни диаграми на Helm»;
• «Представяне на werf 1.0 stable: какво общо има GitOps с него, статус и планове".

Източник: www.habr.com