je náš open source nástroj GitOps CLI pro vytváření a dodávání aplikací do Kubernetes. Jak slíbil, znamenalo začátek přidávání nových funkcí do werf a revize tradičních přístupů. Nyní s potěšením představujeme vydání v1.1, které je velkým krokem ve vývoji a základem pro budoucnost kolektor werf. Verze je aktuálně dostupná v .
Základem vydání je nová architektura úložiště stage a optimalizace práce obou kolektorů (pro Stapel a Dockerfile). Nová architektura úložiště otevírá možnost implementace distribuovaných sestavení z více hostitelů a paralelních sestavení na stejném hostiteli.
Optimalizace práce zahrnuje zbavení se zbytečných výpočtů ve fázi výpočtu signatur fáze a změnu mechanismů pro výpočet kontrolních součtů souborů na efektivnější. Tato optimalizace snižuje průměrnou dobu sestavení projektu pomocí werf. A nečinná sestavení, když všechny fáze existují v mezipaměti etapy-sklad, jsou nyní opravdu rychlé. Ve většině případů bude restartování trvat méně než 1 sekundu! To platí i pro postupy pro ověřování fází v procesu týmové práce. werf deploy и werf run.
V této verzi se také objevila strategie označování obrázků podle obsahu - značkování založené na obsahu, která je nyní ve výchozím nastavení povolena a jediná doporučená.
Pojďme se blíže podívat na klíčové novinky ve werf v1.1 a zároveň si říct o plánech do budoucna.
Co se změnilo ve werf v1.1?
Nový formát pojmenování etap a algoritmus pro výběr etap z mezipaměti
Nové pravidlo generování uměleckých jmen. Nyní každé sestavení fáze generuje jedinečný název fáze, který se skládá ze 2 částí: podpisu (jako tomu bylo ve verzi 1.0) a jedinečného dočasného identifikátoru.
Například celý název jeviště může vypadat takto:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...nebo obecně:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Zde:
-
SIGNATUREje signatura fáze, která představuje identifikátor obsahu fáze a závisí na historii úprav v Gitu, které vedly k tomuto obsahu; -
TIMESTAMP_MILLISECje zaručený jedinečný identifikátor obrázku, který je generován v době vytváření nového obrázku.
Algoritmus pro výběr fází z mezipaměti je založen na kontrole vztahu potvrzení Git:
- Werf vypočítá signaturu určité fáze.
- В etapy-sklad Pro daný podpis může existovat několik fází. Werf vybere všechny fáze, které odpovídají podpisu.
- Pokud je aktuální fáze propojena s Git (archiv git, vlastní fáze s opravami Git:
install,beforeSetup,setup; nebo git-latest-patch), pak werf vybere pouze ty fáze, které jsou spojeny s odevzdáním, které je předkem aktuálního odevzdání (pro nějž se sestavení volá). - Ze zbývajících vhodných etap je vybrána jedna – nejstarší podle data vytvoření.
Stage pro různé větve Git může mít stejný podpis. Ale werf zabrání použití mezipaměti spojené s různými větvemi mezi těmito větvemi, i když se signatury shodují.
.
Nový algoritmus pro vytváření a ukládání fází v úložišti scény
Pokud werf při výběru stupňů z cache nenajde vhodný stupeň, je zahájen proces sestavení nového stupně.
Všimněte si, že více procesů (na jednom nebo více hostitelích) může začít budovat stejnou fázi přibližně ve stejnou dobu. Werf používá optimistický blokovací algoritmus etapy-sklad v okamžiku uložení čerstvě nasbíraného obrázku do etapy-sklad. Tímto způsobem, až bude nová fáze připravena, budou werf bloky etapy-sklad a uloží tam čerstvě shromážděný obrázek pouze v případě, že tam vhodný obrázek již neexistuje (podle podpisu a dalších parametrů – viz nový algoritmus pro výběr fází z mezipaměti).
Je zaručeno, že čerstvě sestavený obrázek bude mít jedinečný identifikátor TIMESTAMP_MILLISEC (viz nový formát pojmenování). V případě v etapy-sklad bude nalezen vhodný obrázek, werf zahodí čerstvě zkompilovaný obrázek a použije obrázek z mezipaměti.
Jinými slovy: první proces, který dokončí vytváření obrazu (ten nejrychlejší), získá právo jej uložit ve fázích (a pak je to tento jediný obraz, který bude použit pro všechna sestavení). Pomalý proces sestavení nikdy nezabrání rychlejšímu procesu v uložení výsledků sestavení aktuální fáze a přechodu na další sestavení.
.
Vylepšený výkon stavitele Dockerfile
V současné době se řetězec fází pro obraz vytvořený z Dockerfile skládá z jedné fáze – dockerfile. Při výpočtu podpisu se vypočítá kontrolní součet souborů context, který bude použit při montáži. Před tímto vylepšením werf rekurzivně procházel všemi soubory a získal kontrolní součet sečtením kontextu a režimu každého souboru. Počínaje verzí 1.1 může werf používat vypočítané kontrolní součty uložené v úložišti Git.
Algoritmus je založen na . Algoritmus bere v úvahu záznamy v .dockerignore a rekurzivně prochází strom souborů pouze v případě potřeby. Tím jsme oddělili čtení systému souborů a závislost algoritmu na velikosti context není významný.
Algoritmus také kontroluje nesledované soubory a v případě potřeby je zohledňuje v kontrolním součtu.
Vylepšený výkon při importu souborů
Verze werf v1.1 používají server rsync, když . Dříve se import prováděl ve dvou krocích pomocí připojení adresáře z hostitelského systému.
Výkon importu na macOS již není omezen objemy Dockeru a importy jsou dokončeny za stejnou dobu jako Linux a Windows.
Označování založené na obsahu
Werf v1.1 podporuje tzv. značkování podle obsahu obrázku - značkování založené na obsahu. Tagy výsledných obrázků Docker závisí na obsahu těchto obrázků.
Při spuštění příkazu werf publish --tags-by-stages-signature nebo werf ci-env --tagging-strategy=stages-signature zveřejněné snímky tzv jevištní podpis obraz. Každý obrázek je označen vlastním podpisem fází tohoto obrázku, který se vypočítává podle stejných pravidel jako běžný podpis každé fáze zvlášť, ale je obecným identifikátorem obrázku.
Podpis fází obrazu závisí na:
- obsah tohoto obrázku;
- historie změn Gitu, které vedly k tomuto obsahu.
Úložiště Git má vždy fiktivní potvrzení, která nemění obsah souborů obrázků. Například potvrzení pouze s komentáři nebo sloučení potvrzení nebo potvrzení, která změní ty soubory v Gitu, které nebudou importovány do obrazu.
Při použití tagování založeného na obsahu jsou vyřešeny problémy se zbytečným restartováním aplikačních modulů v Kubernetes kvůli změnám v názvu obrázku, i když se obsah obrázku nezměnil. To je mimochodem jeden z důvodů, který brání ukládání mnoha mikroslužeb jedné aplikace do jediného úložiště Git.
Tagování založené na obsahu je také spolehlivější metodou tagování než tagování na větvích Git, protože obsah výsledných obrázků nezávisí na pořadí, ve kterém jsou v systému CI spouštěny kanály pro sestavení více odevzdání stejné větve.
Je to důležité,: od nynějška etapy-podpis - Je jediná doporučená strategie značkování. Ve výchozím nastavení se použije v příkazu werf ci-env (pokud výslovně neurčíte jiné schéma označování).
. Této funkci bude také věnována samostatná publikace. AKTUALIZOVÁNO (3. dubna): Článek s podrobnostmi .
Úrovně protokolování
Uživatel má nyní možnost ovládat výstup, nastavovat úroveň logování a pracovat s ladícími informacemi. Možnosti přidány --log-quiet, --log-verbose, --log-debug.
Ve výchozím nastavení výstup obsahuje minimální informace:
Při použití podrobného výstupu (--log-verbose) můžete vidět, jak werf funguje:
Podrobný výstup (--log-debug), kromě informací o ladění werf obsahuje také protokoly použitých knihoven. Můžete například vidět, jak probíhá interakce s registrem Docker, a také zaznamenat místa, kde trávíte značné množství času:
Další plány
Varování! Níže popsané možnosti jsou označeny v1.1 bude k dispozici v této verzi, mnoho z nich v blízké budoucnosti. Aktualizace budou probíhat prostřednictvím automatických aktualizací . Tyto vlastnosti nemají vliv na stabilní část funkcí v1.1, jejich vzhled nebude vyžadovat ruční zásah uživatele do stávajících konfigurací.
Plná podpora pro různé implementace registru Docker (NOVINKA)
- Verze: v1.1
- Termíny: březen
Cílem je, aby uživatel při používání werf používal vlastní implementaci bez omezení.
V současné době jsme identifikovali následující sadu řešení, pro která budeme garantovat plnou podporu:
- Výchozí (knihovna/registr)*,
- AWS ECR
- Blankyt*,
- Docker Hub
- GCR*,
- Balíčky GitHub
- Registr GitLab*,
- Přístav*,
- Nábřeží.
Řešení, která jsou v současné době plně podporována werf, jsou označena hvězdičkou. Pro ostatní existuje podpora, ale s omezeními.
Lze identifikovat dva hlavní problémy:
- Některá řešení nepodporují odstranění značek pomocí rozhraní API Docker Registry, což uživatelům brání v použití automatického čištění werf. To platí pro balíčky AWS ECR, Docker Hub a GitHub.
- Některá řešení nepodporují tzv. vnořená úložiště (Docker Hub, GitHub Packages a Quay) nebo ano, ale uživatel je musí vytvořit ručně pomocí uživatelského rozhraní nebo API (AWS ECR).
Tyto a další problémy budeme řešit pomocí nativních API řešení. Tento úkol také zahrnuje pokrytí celého cyklu provozu werf s testy pro každý z nich.
Distribuované sestavení obrazu (↑)
- Verze: v1.2 v1.1 (priorita implementace této funkce byla zvýšena)
- Termíny: březen-duben březen
V tuto chvíli lze werf v1.0 a v1.1 používat pouze na jednom vyhrazeném hostiteli pro operace vytváření a publikování obrázků a nasazování aplikace do Kubernetes.
Aby se otevřely možnosti distribuované práce werf, když se sestavování a nasazování aplikací v Kubernetes spouští na několika libovolných hostitelích a tito hostitelé neukládají svůj stav mezi sestaveními (dočasní běžci), je nutné, aby werf implementoval schopnost používat registr Docker jako úložiště fáze.
Dříve, když se projekt werf ještě jmenoval dapp, takovou příležitost měl. Narazili jsme však na řadu problémů, které je třeba vzít v úvahu při implementaci této funkce ve werf.
Poznámka. Tato funkce nevyžaduje, aby kolektor pracoval uvnitř modulů Kubernetes, protože Chcete-li to provést, musíte se zbavit závislosti na místním serveru Docker (v podu Kubernetes není přístup k místnímu serveru Docker, protože samotný proces běží v kontejneru a werf nepodporuje a nebude podporovat práce se serverem Docker přes síť). Podpora pro běh Kubernetes bude implementována samostatně.
Oficiální podpora pro GitHub Actions (NOVINKA)
- Verze: v1.1
- Termíny: březen
Zahrnuje dokumentaci werf (oddíly reference и průvodce), stejně jako oficiální akci GitHub pro práci s werf.
Kromě toho umožní werf pracovat na efemérních běžcích.
Mechanika interakce uživatele se systémem CI bude založena na umístění štítků na žádosti o stažení, které iniciují určité akce pro sestavení/zavedení aplikace.
Lokální vývoj a nasazení aplikací s werf (↓)
- Verze: v1.1
- Termíny: leden-únor duben
Hlavním cílem je dosáhnout jediné sjednocené konfigurace pro nasazení aplikací jak lokálně, tak produkčně, bez složitých akcí, hned po vybalení.
werf musí mít také provozní režim, ve kterém bude pohodlné upravovat kód aplikace a okamžitě přijímat zpětnou vazbu od běžící aplikace pro ladění.
Nový čistící algoritmus (NOVINKA)
- Verze: v1.1
- Termíny: duben
V aktuální verzi werf v1.1 v postupu cleanup Neexistuje žádné ustanovení pro čištění obrázků pro schéma značkování založeného na obsahu - tyto obrázky se budou hromadit.
Aktuální verze werf (v1.0 a v1.1) také používá různé zásady čištění pro obrázky publikované podle schémat označování: větev Git, značka Git nebo potvrzení Git.
Byl vynalezen nový algoritmus pro čištění obrázků založený na historii odevzdání v Gitu, sjednocený pro všechna schémata označování:
- Pro každý git HEAD (větve a značky) neponechávejte více než N1 obrázků spojených s nejnovějšími potvrzeními N2.
- Pro každý git HEAD (větve a značky) neukládejte více než obrazy fáze N1 spojené s nejnovějšími potvrzeními N2.
- Uložte všechny obrázky, které se používají v libovolných prostředcích clusteru Kubernetes (všechny kontexty kube konfiguračního souboru a obory názvů jsou kontrolovány; toto chování můžete omezit pomocí speciálních možností).
- Uložte všechny obrázky, které se používají v manifestech konfigurace prostředků uložených ve vydáních Helm.
- Obrázek lze odstranit, pokud není přidružen k žádnému HEAD z git (například proto, že byl odstraněn samotný odpovídající HEAD) a není použit v žádných manifestech v clusteru Kubernetes a ve vydáních Helm.
Paralelní vytváření obrazu (↓)
- Verze: v1.1
- Termíny: leden-únor duben*
Aktuální verze werf shromažďuje obrázky a artefakty popsané v werf.yaml, postupně. Je nutné paralelizovat proces sestavování nezávislých fází obrázků a artefaktů a také poskytovat pohodlný a informativní výstup.
* Poznámka: Termín byl posunut kvůli zvýšené prioritě implementace distribuovaného sestavení, která přidá více možností horizontálního škálování, a také použití werf s akcemi GitHub. Paralelní montáž je dalším optimalizačním krokem, který poskytuje 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 migraci na novou kódovou základnu a osvědčený a pohodlný způsob migrace stávajících instalací.
* Poznámka: Přepnutí na Helm 3 nepřidá do werf významné funkce, protože všechny klíčové vlastnosti Helm 3 (3-cestné sloučení a žádná kormidla) jsou již implementovány ve werf. Kromě toho má werf 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 popisy konfigurace pro Kubernetes ve formátu Jsonnet. Werf zároveň zůstane kompatibilní s Helmem a bude na výběr formát popisu.
Důvodem je, že šablony Go mají podle mnoha lidí vysokou vstupní bariéru a také tím trpí srozumitelnost kódu těchto šablon.
Zvažuje se také možnost zavedení dalších systémů pro popis konfigurace Kubernetes (například Kustomize).
Práce uvnitř Kubernetes (↓)
- Verze: v1.2
- Termíny: duben-květen květen-červen
Cíl: Zajistit, aby byly vytvořeny obrázky a aplikace byla dodána pomocí běžců v Kubernetes. Tito. Nové obrázky lze vytvářet, publikovat, čistit a nasazovat přímo z modulů Kubernetes.
Chcete-li implementovat tuto schopnost, musíte být nejprve schopni vytvářet distribuované obrazy (viz bod výše).
Vyžaduje také podporu pro provozní režim stavitele bez serveru Docker (tj. sestavení podobné Kaniko nebo sestavení v uživatelském prostoru).
Werf bude podporovat stavění na Kubernetes nejen s Dockerfile, ale také s jeho Stapel builderem s inkrementálními přestavbami a Ansible.
Krok k otevřenému rozvoji
Milujeme naši komunitu (, ) a chceme, aby stále více lidí pomáhalo zlepšovat werf, chápali směr, kterým se ubíráme, a podíleli se na rozvoji.
Poměrně nedávno bylo rozhodnuto přejít na abychom odhalili pracovní proces našeho týmu. Nyní můžete vidět okamžité plány a aktuální práci v následujících oblastech:
- ;
- ;
- ;
- .
Hodně práce se udělalo s problémy:
- Nepodstatné byly odstraněny.
- Stávající jsou uvedeny do jednotného formátu s dostatečným množstvím detailů a detailů.
- Byly přidány nové problémy s nápady a návrhy.
Jak povolit verzi v1.1
Verze je aktuálně dostupná v (v kanálech stabilní и tvrdé jak kámen uvolnění se však objeví, jakmile dojde ke stabilizaci ea sám je již dostatečně stabilní pro použití, protože prošel kanály alfa и beta). Aktivováno následujícím způsobem:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Závěr
Nová architektura úložiště etap a optimalizace tvůrců pro stavitele Stapel a Dockerfile otevírají možnost implementace distribuovaných a paralelních sestavení ve werf. Tyto funkce se brzy objeví ve stejném vydání v1.1 a budou automaticky dostupné prostřednictvím mechanismu automatických aktualizací (pro uživatele ).
V této verzi byla přidána strategie označování založená na obsahu obrázků – značkování založené na obsahu, která se stala výchozí strategií. Hlavní protokol příkazů byl také přepracován: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Dalším významným krokem je přidání distribuovaných sestav. Distribuovaná sestavení se od verze 1.0 stala vyšší prioritou než paralelní sestavení, protože přidávají větší hodnotu werf: vertikální škálování stavitelů a podpora pomíjivých stavitelů v různých systémech CI/CD, stejně jako možnost vytvořit oficiální podporu pro akce GitHub. . Proto byly posunuty termíny realizace paralelních montáží. Pracujeme však na tom, abychom obě možnosti co nejdříve realizovali.
Sledujte novinky! A nezapomeňte nás navštívit na vytvořit problém, najít stávající a přidat plus, vytvořit PR nebo jednoduše sledovat vývoj projektu.
PS
Přečtěte si také na našem blogu:
- «»
- «";
- Řada poznámek o inovacích ve werf:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com