O našem nástroji GitOps jsme již mluvili více než jednou. , a tentokrát bychom se rádi podělili o naše zkušenosti s montáží staveniště s dokumentací samotného projektu - (jeho ruská verze je ). Toto je obyčejné statické místo, ale jeho sestavení je zajímavé tím, že je postaveno pomocí dynamického množství artefaktů.
Přejděte na nuance struktury webu: vygenerujte společnou nabídku pro všechny verze, stránky s informacemi o vydáních atd. - nebudeme. Místo toho se zaměřme na problémy a vlastnosti dynamického sestavení a trochu na doprovodné procesy CI/CD.
Úvod: jak web funguje
Pro začátek je dokumentace werf uložena spolu s jejím kódem. To klade určité požadavky na vývoj, které jsou obecně nad rámec tohoto článku, ale minimálně lze říci, že:
- Nové funkce werf by neměly být vydány bez aktualizace dokumentace a naopak jakékoli změny v dokumentaci znamenají vydání nové verze werf;
- Projekt má poměrně intenzivní vývoj: nové verze mohou být vydávány několikrát denně;
- Jakékoli ruční operace k nasazení webu s novou verzí dokumentace jsou přinejmenším únavné;
- Projekt využívá sémantický přístup s 5 stabilizačními kanály. Proces vydání zahrnuje sekvenční průchod verzí kanály v pořadí zvyšující se stability: od alfa po skálopevnou;
- Stránka má ruskou verzi, která „žije a vyvíjí se“ (tj. její obsah je aktualizován) souběžně s hlavní (tj. anglickou) verzí.
Abychom skryli celou tuto „vnitřní kuchyni“ před uživatelem a nabídli mu něco, co „prostě funguje“, udělali jsme samostatný nástroj pro instalaci a aktualizaci werf - Je . Stačí zadat číslo vydání a kanál stability, který jste připraveni použít, a multiwerf zkontroluje, zda je na kanálu nová verze, a v případě potřeby ji stáhne.
V nabídce výběru verze na webu jsou v každém kanálu k dispozici nejnovější verze werf. Standardně podle adresy otevře se verze nejstabilnějšího kanálu pro nejnovější verzi - je také indexována vyhledávači. Dokumentace ke kanálu je k dispozici na samostatných adresách (např. pro beta verzi 1.0).
Celkově má web k dispozici následující verze:
- root (otevře se ve výchozím nastavení),
- pro každý aktivní aktualizační kanál každého vydání (např. ).
K vygenerování konkrétní verze webu obecně stačí zkompilovat pomocí spuštěním v adresáři /docs odpovídající příkaz úložiště werf (jekyll build), po přepnutí na značku Git požadované verze.
Nezbývá než dodat, že:
- k montáži se používá samotná utilita (werf);
- CI/CD procesy jsou postaveny na bázi GitLab CI;
- a to vše samozřejmě běží v Kubernetes.
úkoly
Nyní formulujme úkoly, které berou v úvahu všechna popsaná specifika:
- Po změně verze werf na libovolném kanálu aktualizace dokumentace na webu by se měla automaticky aktualizovat.
- Pro rozvoj musíte být někdy schopni zobrazit náhledové verze webu.
Po změně verze na libovolném kanálu z odpovídajících značek Git je nutné web znovu zkompilovat, ale v procesu vytváření obrazu získáme následující funkce:
- Protože se seznam verzí na kanálech mění, je nutné znovu sestavit dokumentaci pouze pro kanály, kde se verze změnila. Přestavba všeho znovu není totiž moc hezké.
- Sada kanálů pro vydání se může změnit. V určitém okamžiku například na kanálech nemusí být verze stabilnější než verze s předběžným přístupem 1.1, ale časem se objeví – neměli byste v tomto případě změnit sestavu ručně?
Ukazuje se, že montáž závisí na změně externích dat.
uskutečnění
Výběr přístupu
Případně můžete každou požadovanou verzi spustit jako samostatný pod v Kubernetes. Tato možnost znamená větší počet objektů v clusteru, který poroste s nárůstem počtu stabilních verzí werf. A to zase znamená složitější údržbu: každá verze má svůj vlastní HTTP server as malou zátěží. To s sebou samozřejmě nese i vyšší náklady na zdroje.
Šli jsme stejnou cestou sestavení všech potřebných verzí do jednoho obrázku. Kompilovaná statika všech verzí webu je umístěna v kontejneru s NGINX a provoz do odpovídajícího Nasazení přichází prostřednictvím NGINX Ingress. Jednoduchá struktura – bezstavová aplikace – umožňuje snadno škálovat Deployment (v závislosti na zatížení) pomocí samotného Kubernetes.
Abychom byli přesnější, shromažďujeme dva obrázky: jeden pro výrobní okruh, druhý je doplňkový pro vývojový okruh. Dodatečný obrázek se používá (spouští) pouze na dev okruhu spolu s hlavním a obsahuje verzi webu z revize a směrování mezi nimi se provádí pomocí prostředků Ingress.
klon werf vs git a artefakty
Jak již bylo zmíněno, pro vygenerování statiky webu pro konkrétní verzi dokumentace je potřeba sestavit přepnutím na příslušnou značku úložiště. Můžete to také provést klonováním úložiště při každém vytváření a výběrem příslušných značek ze seznamu. To je ale poměrně náročná operace na zdroje a navíc vyžaduje psaní netriviálních instrukcí... Další vážnou nevýhodou je, že s tímto přístupem není možné při sestavování něco uložit do mezipaměti.
Zde nám na pomoc přichází samotná utilita werf, která se implementuje chytré ukládání do mezipaměti a umožní vám používat . Použití werf k přidání kódu z úložiště výrazně urychlí sestavení, protože werf v podstatě jednou naklonuje úložiště a pak se spustí pouze fetch Pokud je potřeba. Navíc při přidávání dat z úložiště můžeme vybrat pouze potřebné adresáře (v našem případě se jedná o adresář docs), což výrazně sníží množství přidaných dat.
Vzhledem k tomu, že Jekyll je nástroj určený pro kompilaci statických dat a není potřeba ve výsledném obrázku, bylo by logické kompilovat v a do výsledného obrázku importovat pouze výsledek kompilace.
Píšeme werf.yaml
Rozhodli jsme se tedy, že zkompilujeme každou verzi do samostatného artefaktu werf. Nicméně my nevíme, kolik z těchto artefaktů bude během montáže, takže nemůžeme napsat pevnou konfiguraci sestavení (přesně vzato, stále můžeme, ale nebude to zcela efektivní).
werf vám umožňuje používat ve vašem konfiguračním souboru (werf.yaml), a to to umožňuje generovat konfiguraci za chodu v závislosti na externích datech (co potřebujete!). Externí data jsou v našem případě informace o verzích a vydáních, na základě kterých shromažďujeme požadovaný počet artefaktů a v důsledku toho získáváme dva obrázky: werf-doc и werf-dev jezdit na různých okruzích.
Externí data jsou předávána prostřednictvím proměnných prostředí. Zde je jejich složení:
-
RELEASES— řádek se seznamem verzí a odpovídající aktuální verzí werf ve formě mezerou odděleného seznamu hodnot ve formátu<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Příklad:1.0%v1.0.4-beta.20 -
CHANNELS— řádek se seznamem kanálů a odpovídající aktuální verzí werf ve formě mezerou odděleného seznamu hodnot ve formátu<КАНАЛ>%<НОМЕР_ВЕРСИИ>. Příklad:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— Verze vydání werf, která se má na webu standardně zobrazovat (není vždy nutné zobrazovat dokumentaci podle nejvyššího čísla vydání). Příklad:v1.0.4-beta.20 -
REVIEW_SHA— hash revize, ze kterého potřebujete sestavit verzi pro testovací smyčku.
Tyto proměnné budou vyplněny v GitLab CI pipeline a jak přesně je napsáno níže.
Nejprve pro pohodlí definujeme v werf.yaml Proměnné šablony Go a přiřaďte jim hodnoty z proměnných prostředí:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}
Popis artefaktu pro kompilaci statické verze webu je obecně stejný pro všechny případy, které potřebujeme (včetně generování kořenové verze, stejně jako verze pro dev okruh). Proto jej pomocí funkce přesuneme do samostatného bloku define - pro následné opětovné použití include. Šabloně předáme následující argumenty:
-
Version— vygenerovaná verze (název značky); -
Channel— název aktualizačního kanálu, pro který je artefakt generován; -
Commit— commit hash, pokud je artefakt generován pro revizní commit; - kontext.
Popis šablony artefaktu
{{- 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 }}
Název artefaktu musí být jedinečný. Toho můžeme dosáhnout například přidáním názvu kanálu (hodnoty proměnné .Channel) jako příponu názvu artefaktu: artifact: doc-{{ .Channel }}. Ale musíte pochopit, že při importu z artefaktů budete muset odkazovat na stejná jména.
Při popisu artefaktu se používá následující funkce werf: . Montáž označující adresář služby build_dir umožňuje ukládat Jekyll cache mezi běhy potrubí, což výrazně urychluje zpětnou montáž.
Možná jste si také všimli použití souboru releases.yml je soubor YAML s požadovanými daty vydání (artefakt získaný při provádění potrubí). Je potřeba při sestavování webu, ale v kontextu článku je pro nás zajímavý, protože závisí na jeho stavu opětovné sestavení pouze jednoho artefaktu — artefakt kořenové verze webu (v jiných artefaktech není potřeba).
To je implementováno pomocí podmíněného příkazu if Go šablony a návrhy {{ $Root.Files.Get "releases.yml" | sha256sum }} ve fázi . Funguje to následovně: při vytváření artefaktu pro kořenovou verzi (proměnná .Channel je root) hash souboru releases.yml ovlivňuje podpis celé fáze, protože je součástí názvu úlohy Ansible (parametr name). Tedy při změně obsah soubor releases.yml odpovídající artefakt bude znovu sestaven.
Věnujte prosím pozornost také práci s externím úložištěm. V obraze artefaktu z , přidá se pouze adresář /docsa v závislosti na předaných parametrech jsou okamžitě přidána data požadované značky nebo revize.
Chcete-li použít šablonu artefaktu ke generování popisu artefaktu přenesených verzí kanálů a vydání, uspořádáme smyčku na proměnné .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}
Protože smyčka vygeneruje několik artefaktů (doufáme, že ano), je třeba vzít v úvahu oddělovač mezi nimi - sekvenci --- (Další informace o syntaxi konfiguračního souboru viz ). Jak bylo definováno dříve, při volání šablony ve smyčce předáváme parametry verze, URL a kořenový kontext.
Podobně, ale bez smyčky, nazýváme šablonu artefaktu pro „zvláštní případy“: pro kořenovou verzi i verzi z revize:
{{ 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 }}
Vezměte prosím na vědomí, že artefakt pro odevzdání recenze bude vytvořen pouze tehdy, je-li nastavena proměnná .WerfReviewCommit.
Artefakty jsou připraveny – je čas začít s importem!
Finální obraz navržený pro běh na Kubernetes je běžný NGINX s přidaným konfiguračním souborem serveru nginx.conf a statické z artefaktů. Kromě artefaktu kořenové verze webu musíme opakovat smyčku na proměnné .WerfVersions importovat artefakty verzí kanálu a vydání + postupujte podle pravidla pro pojmenování artefaktů, které jsme přijali dříve. Vzhledem k tomu, že každý artefakt ukládá verze webu pro dva jazyky, importujeme je do míst poskytovaných konfigurací.
Popis výsledného obrázku 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 -}}Dodatečný obrázek, který se spolu s hlavním spouští na vývojovém okruhu, obsahuje pouze dvě verze webu: verzi z revize a kořenovou verzi webu (jsou zde obecná aktiva a pokud si vzpomínáte , údaje o vydání). Dodatečný obrázek se tedy bude lišit od hlavního pouze v sekci importu (a samozřejmě v názvu):
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 }}
Jak je uvedeno výše, artefakt pro potvrzení revize bude vygenerován pouze při spuštění proměnné prostředí set REVIEW_SHA. Pokud neexistuje žádná proměnná prostředí, bylo by možné obraz werf-dev vůbec nevygenerovat REVIEW_SHA, ale za účelem Docker obrazy ve werf fungovaly pro obraz werf-dev, necháme jej sestavit pouze s artefaktem kořenové verze (stejně je již sestaven), abychom zjednodušili strukturu potrubí.
Sestava je připravena! Pojďme k CI/CD a důležitým nuancím.
Pipeline v GitLab CI a funkce dynamického sestavení
Při spouštění sestavení musíme nastavit proměnné prostředí používané v werf.yaml. To neplatí pro proměnnou REVIEW_SHA, kterou nastavíme při volání pipeline z háku GitHub.
Potřebná externí data vygenerujeme v Bash skriptu generate_artifacts, který vygeneruje dva artefakty potrubí GitLab:
- файл
releases.ymls údaji o vydání, - файл
common_envs.sh, obsahující proměnné prostředí, které mají být exportovány.
Obsah souboru generate_artifacts najdete v našem . Samotný příjem dat není předmětem článku, ale spisu common_envs.sh je pro nás důležité, protože práce werf závisí na tom. Ukázka jeho obsahu:
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'
Výstup takového skriptu můžete využít například pomocí funkce Bash source.
Nyní přichází ta zábavná část. Aby sestavení i nasazení aplikace fungovalo správně, je nutné to zajistit werf.yaml byl stejný alespoň v rámci jednoho potrubí. Pokud tato podmínka není splněna, pak se signatury fází, které werf vypočítává během montáže a například nasazení, budou lišit. To povede k chybě nasazení, protože... obrázek potřebný pro nasazení bude chybět.
Jinými slovy, pokud jsou během sestavování obrazu webu stejné informace o vydáních a verzích a v době nasazení je vydána nová verze a proměnné prostředí mají různé hodnoty, pak nasazení selže s chybou: ostatně artefakt nové verze ještě nebyl postaven.
Pokud generace werf.yaml závisí na externích datech (například seznam aktuálních verzí, jako v našem případě), pak by složení a hodnoty těchto dat měly být zaznamenány v rámci potrubí. To je zvláště důležité, pokud se vnější parametry mění poměrně často.
Budeme přijímat a zaznamenávat externí data v první fázi potrubí v GitLabu (Předsestavení) a předávat je dále ve formě Artefakt GitLab CI. To vám umožní spouštět a restartovat úlohy potrubí (sestavení, nasazení, vyčištění) se stejnou konfigurací werf.yaml.
Obsah jeviště Předsestavení soubor .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 weekPo zachycení externích dat v artefaktu můžete sestavit a nasadit pomocí standardních fází potrubí GitLab CI: Build a Deploy. Samotný kanál spouštíme pomocí háčků z úložiště werf GitHub (tj. když dojde ke změnám v úložišti na GitHubu). Údaje k nim naleznete ve vlastnostech projektu GitLab v sekci CI/CD Settings -> Pipeline triggersa poté vytvořte odpovídající webhook na GitHubu (Nastavení -> Webhooky).
Fáze sestavení bude vypadat takto:
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 přidá dva artefakty z fáze do fáze sestavení Předsestavení, takže pomocí konstruktu exportujeme proměnné s připravenými vstupními daty source common_envs.sh. Stavbu zahajujeme ve všech případech s výjimkou spuštění potrubí podle harmonogramu. Dle harmonogramu povedeme potrubí pro čištění - v tomto případě není potřeba provádět montáž.
Ve fázi nasazení popíšeme dva úkoly – odděleně pro nasazení do produkčních a vývojových okruhů pomocí šablony 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
Úlohy se v podstatě liší pouze v označení kontextu clusteru, do kterého by měl werf provést nasazení (WERF_KUBE_CONTEXT) a nastavení proměnných prostředí smyčky (environment.name и environment.url), které se pak používají v šablonách grafů Helm. Obsah šablon neposkytujeme, protože... k danému tématu tam není nic zajímavého, ale najdete je v .
Konečný dotek
Vzhledem k tomu, že verze werf jsou vydávány poměrně často, budou se často vytvářet nové obrazy a registr Docker se neustále rozrůstá. Proto je nezbytné nakonfigurovat automatické čištění obrazu na základě zásad. Je to velmi snadné.
K implementaci budete potřebovat:
- Přidejte krok čištění
.gitlab-ci.yml; - Přidejte pravidelné provádění úklidové úlohy;
- Nastavte proměnnou prostředí s tokenem pro přístup k zápisu.
Přidání fáze čištění k .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
Téměř vše jsme již viděli o něco výše – pouze pro vyčištění je potřeba se nejprve přihlásit do registru Docker s tokenem, který má práva na mazání obrázků v registru Docker (automaticky vydávaný token úlohy GitLab CI nemá mají taková práva). Token musí být vytvořen v GitLabu předem a jeho hodnota musí být uvedena v proměnné prostředí WERF_IMAGES_CLEANUP_PASSWORD projekt (Nastavení CI/CD -> Proměnné).
Přidání úlohy čištění s požadovaným plánem se provádí v CI/CD ->
Jízdní řády.
To je vše: projekt v registru Docker již nebude neustále růst z nepoužívaných obrázků.
Na závěr praktické části mi dovolte připomenout, že kompletní výpisy z článku jsou dostupné v :
- ;
- .
Výsledek
- Obdrželi jsme logickou strukturu sestavy: jeden artefakt na verzi.
- Sestava je univerzální a nevyžaduje ruční změny při vydání nových verzí werf: dokumentace na webu se automaticky aktualizuje.
- Dva obrazy jsou sestaveny pro různé obrysy.
- Funguje to rychle, protože Ukládání do mezipaměti se využívá v maximální možné míře – když je vydána nová verze werf nebo je zavolán hák GitHub pro revizní odevzdání, je znovu vytvořen pouze odpovídající artefakt se změněnou verzí.
- Není třeba přemýšlet o mazání nepoužívaných obrázků: čištění podle zásad werf udrží registr Docker v pořádku.
Závěry
- Použití werf umožňuje sestavení pracovat rychle díky cachování jak samotného sestavení, tak cachování při práci s externími repozitáři.
- Práce s externími repozitáři Git eliminuje potřebu pokaždé klonovat celé úložiště nebo znovu vynalézat kolo se složitou optimalizační logikou. werf používá mezipaměť a klonování provede pouze jednou a poté použije
fetcha pouze v případě potřeby. - Schopnost používat šablony Go v konfiguračním souboru sestavení
werf.yamlumožňuje popsat sestavu, jejíž výsledek závisí na externích datech. - Použití mount ve werf výrazně zrychluje sběr artefaktů – kvůli cache, která je společná pro všechny pipeline.
- werf usnadňuje konfiguraci čištění, což je zvláště důležité při dynamickém budování.
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com