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

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

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

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

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

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

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

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

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

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

За генериране на конкретна версия на сайта, обикновено е достатъчно да извършите компилация с помощта на Jekyll, стартирайки в директорията /docs на репозитория werf с подходящата команда (jekyll build), предварително превключвайки на Git-тег на необходимата версия.

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

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

Задачи

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

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

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

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

Излиза, че компилацията зависи от променящи се външни данни..

Реализация

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

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

Ние обаче избрахме пътя на компилация на всички необходими версии в един образ.Скомпилираната статична информация на всички версии на сайта се намира в контейнер с NGINX, а трафикът на съответния Deployment идва чрез NGINX Ingress. Простата структура — stateless приложение — позволява лесно мащабиране на Deployment (в зависимост от натоварването) с помощта на самия Kubernetes.

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

werf срещу git clone и артефакти

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

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

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

Пишем werf.yaml

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

werf позволява да се използват Go шаблони в своя файл за конфигурация (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 — хеш на review-коммита, от който трябва да се сглоби версията за тестовия контур.

Тези променливи ще се попълват в GitLab CI pipeline, а как точно — е описано по-долу.

Първо, за удобство, ще определим в werf.yaml променливи на Go-шаблони, присвоявайки им стойности от променливи на средата:

{{ $_ := 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 — хеш на коммита, ако артефактът се генерира за review-коммит;
• контекст.

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

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
артефакт: doc-{{ .Channel }}
от: jekyll/builder:3
монтиране:
- от: build_dir
  до: /usr/local/bundle
ansible:
  инсталиране:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - име: "Инсталиране на зависимости"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  предиНастройка:
{{- if .Commit }}
  - shell: echo "Проверете SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - име: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      съдържание: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - файл:
      път: /app/docs/_data/releases.yml
      състояние: touch
{{- end }}
  - файл:
      път: "{{`{{ item }}`}}"
      състояние: директория
      режим: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - файл:
      dest: /app/docs/pages_ru/cli
      състояние: линк
      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
  до: /app/
  собственик: jekyll
  група: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    инсталиране: ['docs/Gemfile','docs/Gemfile.lock']
    предиНастройка: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

Името на артефакта трябва да бъде уникално. Можем да постигнем това, например, като добавим името на канала (стойността на променливата .Channel) като суфикс на името на артефакта: артефакт: doc-{{ .Channel }}. Но е необходимо да се разбере, че при импортиране от артефакти ще е необходимо да се позовавате на същите имена.

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

Също така, може да сте заб注意ли използването на файла releases.yml — това е YAML файл с данни за релизите, който се заявява с github.com (артефакт, получен при изпълнението на pipeline). Той е необходим при компилирането на сайта, но в контекста на статията ни е интересен поради факта, че от състоянието му зависи повторното компилиране само на един артефакт — артефактът на сайта с коренова версия (в другите артефакти не е нужно).

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

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

Сборката е готова! Преминаваме към CI/CD и важните нюанси.

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

При стартиране на сборката е необходимо да зададем променливите на средата, използвани в werf.yaml. Това не се отнася за променливата REVIEW_SHA, която ще задаваме при извикване на pipeline от GitHub hook.

Извличането на необходимите външни данни ще бъде изнесено в Bash-скрипт generate_artifacts, който ще генерира два артефакта за pipeline на 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 функция източник.

А сега най-интересното. За да работят както сборката, така и деплоя на приложението правилно, е необходимо да се уверите, че werf.yaml беше са еднакви поне в рамките на един pipeline. Ако това условие не бъде изпълнено, то подписите на етапите, които werf изчислява при сборката и, например, деплоя, ще бъдат различни. Това ще доведе до грешка при деплоя, тъй като необходимият за деплоя образ ще липсва.

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

Ако генерирането werf.yaml зависи от външни данни (например, списък с актуални версии, както в нашия случай), то съставът и стойностите на тези данни трябва да бъдат фиксирани в рамките на pipeline. Това е особено важно, ако външните параметри се променят доста често.

Ние ще получаваме и фиксираме външни данни на първия етап от pipeline в GitLab (Prebuild) и ще ги предаваме нататък под формата на артефакт GitLab CI. Това ще позволи стартиране и повторно стартиране на задачите в pipeline (сборка, деплой, почистване) с еднаква конфигурация в werf.yaml.

Съдържание на етапа Prebuild файла .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 и Deploy. Самият pipeline стартираме по хукове от GitHub репозитория на werf (т.е. при промени в репозитория на GitHub). Данните за тях можем да вземем в настройките на проекта GitLab в раздела CI / CD Settings -> Pipeline triggers, а след това ще създадем съответстващ Webhook в GitHub (Settings -> 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 ще добави в етапа на сборка две артефакта от етапа Prebuild, така че ще експортираме променливите с подготвените входни данни с помощта на конструкцията source common_envs.sh. Стартираме фаза на изграждане при всички случаи, с изключение на стартиране на пайплайн по разписание. По разписание ще стартира пайплайн за почистване — в този случай не е необходимо изграждане.

На етапа на разгръщане ще опишем две задачи — поотделно за разгръщане на production и 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 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 Settings -> Variables).

Добавянето на задачата за почистване с необходимо разписание става в CI/CD ->
Schedules.

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

В заключение на практическата част напомням, че пълните листинги от статията са достъпни в Git:

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

Резултат

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

Изводи

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

P.S.

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

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

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