🥇Vydání werf 1.1: zlepšení v sestavovači dnes a plány do budoucna

werf — naše GitOps CLI nástroj s otevřeným zdrojovým kódem pro sestavování a dodávání aplikací na Kubernetes. Jak jsme slíbili, vydání verze v1.0 označilo začátek přidávání nových funkcí do werf a přehodnocení osvědčených přístupů. Nyní s radostí představujeme verzi v1.1, která je velkým krokem vpřed a základním kamenem pro budoucnost. sestavovače werf. Verze je momentálně k dispozici na kanálu 1.1 ea.

Základem vydání je nová architektura úložiště fází a optimalizace výkonu obou sestavovačů (pro Stapel a Dockerfile). Nová architektura úložiště otevírá možnosti pro realizaci distribuovaných sestavení z více hostitelů a paralelních sestavení na jednom hostiteli.

Optimalizace výkonu zahrnuje odstranění nadbytečných výpočtů při výpočtu podpisů fází a změnu mechanismů výpočtu kontrolních součtů souborů na efektivnější. Tato optimalizace zkracuje průměrnou dobu sestavení projektu pomocí werf. A prázdná sestavení, kdy všechny fáze existují v cache, stages-storage, jsou nyní skutečně rychlá. Většina případů opětovného spuštění sestavení proběhne rychleji než za 1 sekundu! To se také týká a verifikačních procedur fází během práce týmů. werf deploy a werf run.

Také v této verzi se objevila strategie označování obrazů na základě obsahu — content-based tagging, která je nyní nastavena jako výchozí a je jedním z nejvíce doporučovaných přístupů.

Podívejme se podrobněji na klíčové novinky v werf v1.1 a zároveň si povíme o plánech do budoucna.

Co se změnilo ve werf v1.1?

Nový formát pojmenování fází a algoritmus výběru fází z cache

Nové pravidlo generování názvu fáze. Nyní každé sestavení fáze generuje unikátní název fáze, který se skládá z dvou částí: podpisu (jak tomu bylo v v1.0) a unikátního časového identifikátoru.

Například celé jméno obrazu fáze může vypadat takto:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

… nebo v obecném tvaru:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Zde:

SIGNATURE — to je podpis fáze, který představuje identifikátor obsahu fáze a závisí na historii změn v Gitu, které vedly k tomuto obsahu;
TIMESTAMP_MILLISEC — to je zaručeně unikátní identifikátor obrazu, který se generuje v okamžiku sestavení nového obrazu.

Algoritmus výběru fází z cache je založen na kontrole souvislosti Git commitů:

Werf vypočítává podpis určité fáze.
V stages-storage může existovat několik fází se stejným podpisem. Werf vybírá všechny vhodné fáze podle podpisu.
Pokud je aktuální fáze spojena s Gitem (git-archive, uživatelská fáze s Git patchy: install, beforeSetup, setup; nebo git-latest-patch), pak werf vybere pouze ty fáze, které jsou spojeny s commitem, který je předkem aktuálního commitu (pro který byla vyvolána stavba).
Z zbývajících vhodných fází se vybírá jedna — nejstarší podle data vytvoření.

Fáze pro různé Git větve může mít stejný podpis. Ale werf zamezí používání cache spojené s různými větvemi mezi těmito větvemi, i když se podpisy shodují.

→ Dokumentace.

Nový algoritmus tvorby a ukládání fází do úložiště fází

Pokud během výběru fází z cache werf nenajde vhodnou fázi, zahájí se proces stavby nové fáze.

Poznamenejme, že několik procesů (na jednom nebo více hostitelích) může zahájit stavbu jedné a té samé fáze přibližně ve stejnou dobu. Werf používá algoritmus optimistické blokace stages-storage při ukládání čerstvě postaveného obrazu v stages-storage. Takže, když je nová fáze hotová, werf blokuje stages-storage a uloží tam čerstvě postavený obraz pouze v případě, že tam ještě neexistuje vhodný obraz (podle podpisu a dalších parametrů — viz nový algoritmus výběru fází z cache).

Čerstvě postavený obraz bude mít zaručeně unikátní identifikátor podle TIMESTAMP_MILLISEC (viz nový formát pojmenování fází). V případě, že v stages-storage bude nalezen vhodný obraz, werf odmítne čerstvě postavený obraz a použije obraz z cache.

Jinými slovy: první proces, který dokončí stavbu obrazu (nejrychlejší), získá právo uložit ho do stages-storage (a pak tento jediný obraz bude používán pro všechny stavby). Pomalejší proces stavby nikdy nezablokuje rychlejší proces od ukládání výsledků stavby aktuální fáze a přechodu k stavbě další.

→ Dokumentace.

Vylepšena výkonnost sestavovače Dockerfile

V současné době se pipeline fází pro obraz sestavovaný z Dockerfile skládá z jedné fáze — dockerfile. Při výpočtu podpisu se bere v úvahu kontrolní suma souborů context, které budou použity při sestavování. Před tímto vylepšením werf rekurzivně procházel všechny soubory a získával kontrolní součet, když sečítal kontext a mod každého souboru. Od verzí v1.1 může werf využívat vypočítané kontrolní součty uložené v Git repozitáři.

Na základě algoritmu je — git ls-tree. Algoritmus zohledňuje záznamy v .dockerignore a prochází rekurzivně stromem souborů pouze v případě potřeby. Tímto způsobem jsme se zbavili čtení souborového systému, a závislost algoritmu na velikosti context není rozhodující.

Algoritmus také kontroluje untracked soubory a v případě potřeby je zahrnuje do kontrolního součtu.

Byla vylepšena výkonnost při importu souborů

Ve verzích werf v1.1 se při importu souborů z artefaktů a obrazů. Dříve byl import prováděn ve dvou krocích pomocí montování adresáře z hostitelského systému.

Výkon importů v macOS již není omezen Docker volumes, a importy se provádějí ve stejném čase jako v Linuxu a Windows.

Označování na bázi obsahu

Werf v1.1 podporuje takzvané označování podle obsahu obrazu — content-based tagging. Tagy výsledných Docker obrazů závisí na obsahu těchto obrazů.

Při spuštění příkazu werf publish --tags-by-stages-signature nebo werf ci-env --tagging-strategy=stages-signature budou označeny publikované obrazy takzvanou podpisem fází obrazu. Každý obraz je označen svou vlastní fází podpisu tohoto obrazu, která je vypočítána podle stejných pravidel jako běžný podpis každé fáze samostatně, ale je to generalizovaný identifikátor obrazu.

Podpis fáze obrazu závisí na:

obsahu tohoto obrazu;
historii změn v Gitu, které vedly k tomuto obsahu.

V Git repozitáři jsou vždy prázdné commity, které nemění obsah souborů obrazu. Například commity pouze se komentáři nebo sloučovací commity, nebo commity, které mění ty soubory v Gitu, které nebudou importovány do obrazu.

Při použití označování na bázi obsahu se řeší problémy s nadbytečnými restartami podů aplikace v Kubernetes kvůli změnám názvu obrazu, dokonce i když se obsah obrazu nezměnil. Mimochodem, to je jeden z důvodů, které brání uchování mnoha mikroslužeb jedné aplikace v jednom Git repozitáři.

Tagování na základě obsahu je spolehlivější metodou tagování než tagování podle Git větví, protože obsah výsledných obrazů nezávisí na pořadí provádění pipeline v CI systému pro sestavení několika commitů ze stejné větve.

Je důležité: od tohoto okamžiku stages-signature — to je jediná doporučená strategie tagování. Ta bude jako výchozí použita v týmu werf ci-env (pokud není výslovně uvedena jiná tagovací schéma).

→ Dokumentace. Tato funkce bude také věnována samostatné publikaci. AKTUALIZOVÁNO (3. dubna): Článek s podrobnostmi byla vydána.

Úrovně logování

Uživatel má nyní možnost ovládat výstup, nastavovat úroveň logování a pracovat s ladicími informacemi. Přidány možnosti --log-quiet, --log-verbose, --log-debug.

Ve výstupu je ve výchozím nastavení minimum informací:

Při použití podrobného výstupu (--log-verbose) lze sledovat, jak werf funguje:

Podrobný výstup (--log-debug), kromě ladicích informací werf, obsahuje také logy používaných knihoven. Například lze vidět, jak probíhá interakce s Docker Registry, a také zaznamenat místa, kde se vynakládá značné množství času:

Další plány

Pozor! Níže popsané možnosti s označením v1.1 budou k dispozici již v této verzi, mnohé z nich — v blízké době. Aktualizace přijdou prostřednictvím automatických aktualizací při použití multiwerf. Tyto možnosti se netýkají stabilní části funkcí v1.1, jejich uvedení nevyžaduje ruční zásah uživatele do již existujících konfigurací.

Úplná podpora různých implementací Docker Registry (NOVÉ)

Verze: v1.1
Termíny: březen
Issue

Cílem je, aby uživatel mohl používat libovolnou implementaci bez omezení při používání werf.

V současné době jsme identifikovali následující sadu řešení, pro která garantujeme plnou podporu:

Default (library/registry)*,
AWS ECR,
Azure*,
Docker Hub,
GCR*,
GitHub Packages,
GitLab Registry*,
Harbor*,
Quay.

Hvězdičkou jsou označena řešení, která jsou v současné době plně podporována werf. Pro ostatní existuje podpora, ale s omezeními.

Lze vyčlenit dva hlavní problémy:

Některá řešení nepodporují odstranění tagů prostřednictvím Docker Registry API, což brání uživatelům používat automatické čištění implementované ve werf. To platí pro AWS ECR, Docker Hub a GitHub Packages.
Některá řešení nepodporují takzvané nested repositories (Docker Hub, GitHub Packages a Quay) nebo podporují, ale uživatel je musí vytvářet ručně pomocí UI nebo API (AWS ECR).

Tyto a další problémy plánujeme řešit pomocí nativních API těchto řešení. Tato úloha zahrnuje také pokrytí testy celého pracovního cyklu werf pro každé z nich.

Distribuovaná sestava obrazů (↑)

Verze: v1.2 v1.1 (priorita implementace této funkce byla zvýšena)
Termíny: březen-duben březen
Issue

V současnosti lze werf v1.0 a v1.1 používat pouze na jednom dedikovaném hostu pro operace sestavení a publikování obrazů a nasazení aplikace do Kubernetes.

Chcete-li otevřít možnosti distribuované práce werf, kdy jsou sestavení a nasazení aplikací do Kubernetes spuštěny na několika náhodných hostech a tyto hosty si mezi sestaveními uchovávají své stavy (dočasní runner’y), vyžaduje werf implementaci možnosti používání Docker Registry jako úložiště fází.

Dříve, když byl projekt werf ještě nazýván dapp, byla taková možnost. Avšak potýkali jsme se s řadou problémů, které je třeba zohlednit při implementaci této funkce ve werf.

Poznámka. Tato možnost nepředpokládá práci sestavovače uvnitř podů Kubernetes, protože k tomu je nutné zbavit se závislosti na místním Docker serveru (v podu Kubernetes není přístup k místnímu Docker serveru, protože samotný proces je spuštěn v kontejneru, a práce s Docker serverem přes síť werf nepodporuje a nebude podporovat). Podpora práce v Kubernetes bude implementována samostatně.

Oficiální podpora GitHub Actions (NOVINKA)

Verze: v1.1
Termíny: březen
Issue

Zahrnuje dokumentaci werf (části reference a guide), stejně jako oficiální GitHub Action pro práci s werf.

Kromě toho umožní fungování werf na efemérních runnerech.

Mechanika interakce uživatele s CI systémem bude založena na vystavení labelů na pull-requesty pro iniciaci určitých akcí při sestavení/vydání aplikace.

Lokální vývoj a nasazení aplikací s werf (↓)

Verze: v1.1
Termíny: leden-únor duben
Issue

Hlavním cílem je dosáhnout jednotného unifikovaného nastavení pro nasazení aplikací jak lokálně, tak v produkci, bez složitých úkonů, „z krabice“.

Od werf se také vyžaduje takový režim práce, ve kterém bude pohodlné upravovat kód aplikace a okamžitě získat zpětnou vazbu z běžící aplikace pro ladění.

Nový algoritmus čištění (NOVÉ)

Verze: v1.1
Termíny: duben
Issue

V aktuální verzi werf v1.1 v proceduře cleanup není zajištěno čištění obrazů pro schéma označování na základě obsahu (content-based tagging) — tyto obrazy se budou hromadit.

Také v aktuální verzi werf (v1.0 a v1.1) se používají různé politiky čištění pro obrazy publikované podle schémat označování: Git-větve, Git-štítky nebo Git-commity.

Byl navržen nový unifikovaný algoritmus čištění obrazů pro všechna schémata označování na základě historie commitů v Git:

Udržovat maximálně N1 obrazů spojených s N2 posledními commity pro každý git HEAD (větve a štítky).
Udržovat maximálně N1 obrazů-fází spojených s N2 posledními commity pro každý git HEAD (větve a štítky).
Udržovat všechny obrazy, které se používají v jakýchkoli zdrojích clusteru Kubernetes (prohledávají se všechny kube-kontejnerové kontexty souboru konfigurace a namespaces; toto chování lze omezit speciálními možnostmi).
Udržovat všechny obrazy, které se používají v manifestech konfigurace zdrojů uložených v Helm-releases.
Obraz může být odstraněn, pokud není spojen s žádným HEAD z git (například protože příslušný HEAD byl smazán) a není použit v žádném z manifestů v clusteru Kubernetes a v releases Helm.

Paralelní sestavení obrazů (↓)

Verze: v1.1
Termíny: leden-únor duben*

Aktuální verze werf sestavuje obrazy a artefakty, které jsou popsány v werf.yaml, postupně. Je nutné paralelizovat proces sestavení nezávislých fází obrazů a artefaktů, stejně jako zajistit pohodlný a informativní výstup.

* Poznámka: termín byl posunut kvůli zvýšené prioritě realizace distribuovaného sestavení, které přidá více možností pro horizontální škálování a také použití werf s GitHub Actions. Paralelní sestavení je dalším krokem optimalizace, který poskytne vertikální škálovatelnost při sestavování jednoho projektu.

Přechod na Helm 3 (↓)

Verze: v1.2
Termíny: únor-březen květen*

Zahrnuje přechod na novou kódovou základnu Helm 3 a osvědčený, pohodlný způsob migrace existujících instalací.

* Poznámka: přechod na Helm 3 nepřidá zásadní možnosti do werf, protože všechny klíčové funkce Helm 3 (3-way-merge a absence tiller) jsou již v werf implementovány. Navíc má werf další možnosti kromě uvedených. Tento přechod však zůstává v našich plánech a bude realizován.

Jsonnet pro popis konfigurace Kubernetes (↓)

Verze: v1.2
Termíny: leden-únor, duben-květen

Werf bude podporovat popis konfigurace pro Kubernetes ve formátu Jsonnet. Přitom werf zůstane kompatibilní s Helm a bude možnost volby formátu popisu.

Důvodem je skutečnost, že šablony jazyka Go mají podle mnoha lidí vysoký vstupní prah a srozumitelnost kódu těchto šablon také trpí.

Také se zvažuje možnost zavedení dalších systémů popisu konfigurace Kubernetes (např. Kustomize).

Práce uvnitř Kubernetes (↓)

Verze: v1.2
Termíny: duben-květen, květen-červen

Cíl: zajistit sestavení obrazů a dodání aplikace s použitím runnerů v Kubernetes. T.j. sestavení nových obrazů, jejich publikace, čištění a nasazení může probíhat přímo z podů Kubernetes.

K realizaci této možnosti je nejprve potřeba schopnost distribuovaného sestavení obrazů (viz. výše).

Také je potřeba podpora režimu práce sestavovače bez Docker serveru (t.j. sestavení podobné Kaniko nebo sestavení v userspace).

Werf bude podporovat sestavování v Kubernetes nejen pomocí Dockerfile, ale také pomocí svého sestavovače Stapel s inkrementálními přestavbami a Ansible.

Krok směrem k otevřenému vývoji

Milujeme naše společenství (GitHub, Telegram) a chceme, aby čím dál více lidí pomáhalo zlepšovat werf, rozumělo směru, kterým se ubíráme, a účastnilo se vývoje.

Docela nedávno bylo rozhodnuto přejít na GitHub project boards abychom odhalili pracovní proces našeho týmu. Nyní je možné vidět nejbližší plány a také současné práce na následujících oblastech:

Byla odvedena velká práce s issues:

Zrušeny neaktuální.
Existující byly uvedeny do jednotného formátu, dostatečného počtu podrobností a detailů.
Byly přidány nové issues s nápady a návrhy.

Jak zahrnout verzi v1.1

Verze je v současnosti dostupná na kanálu 1.1 ea (v kanálech stable a rock-solid vydání se objeví, jakmile se stabilizují, nicméně ea sama o sobě je již dostatečně stabilní pro použití, protože prošla kanály alpha a beta). Aktivováno přes multiwerf následujícím způsobem:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Závěr

Nová architektura úložiště fází a optimalizace práce sestavovače pro Stapel a Dockerfile sestavovače otevírají možnosti implementovat distribuované a paralelní sestavy v werf. Tyto možnosti se brzy objeví ve stejné verzi v1.1 a budou automaticky dostupné prostřednictvím mechanismu automatických aktualizací (pro uživatele multiwerf).

V této verzi byla přidána strategie tagování podle obsahu obrazů — content-based tagging, — která se stala výchozí strategií. Také byl přepracován log hlavních příkazů: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Dalším významným krokem bude přidání distribuovaných sestav. Distribuované sestavy se od verze v1.0 staly prioritnější úlohou než paralelní sestavy, protože přidávají větší hodnotu werf: vertikální škálování sestavovačů a podpora efemérních sestavovačů v různých CI/CD systémech, jakož i možnost oficiální podpory GitHub Actions. Proto byly termíny realizace paralelních sestav posunuty. Pracujeme však na tom, abychom co nejdříve implementovali obě možnosti.

Sledujte novinky! A nezapomeňte se k nám podívat na GitHub, abyste vytvořili issue, našli již existující a dali mu plus, vytvořili PR nebo jen sledovali vývoj projektu.