je naša utilita GitOps CLI s otvoreným zdrojovým kódom na vytváranie a doručovanie aplikácií do Kubernetes. Ako bolo sľúbené, znamenal začiatok pridávania nových funkcií do werf a revízie tradičných prístupov. Teraz s potešením predstavujeme vydanie v1.1, ktoré je veľkým krokom vo vývoji a základom do budúcnosti zberateľ werf. Verzia je momentálne dostupná v .
Základom vydania je nová architektúra úložiska scény a optimalizácia práce oboch kolektorov (pre Stapel a Dockerfile). Nová architektúra úložiska otvára možnosť implementácie distribuovaných zostáv z viacerých hostiteľov a paralelných zostáv na tom istom hostiteľovi.
Optimalizácia práce zahŕňa zbavenie sa zbytočných výpočtov vo fáze výpočtu signatúr štádia a zmenu mechanizmov na výpočet kontrolných súčtov súborov na efektívnejšie. Táto optimalizácia znižuje priemerný čas zostavovania projektu pomocou werf. A nečinné zostavy, keď všetky fázy existujú vo vyrovnávacej pamäti etapy-ukladanie, sú teraz naozaj rýchle. Vo väčšine prípadov bude reštart zostavy trvať menej ako 1 sekundu! To platí aj pre postupy na overovanie fáz v procese práce tímov. werf deploy и werf run.
Aj v tomto vydaní sa objavila stratégia označovania obrázkov podľa obsahu - označovanie založené na obsahu, ktorá je teraz predvolene povolená a jediná odporúčaná.
Poďme sa bližšie pozrieť na kľúčové inovácie vo werf v1.1 a zároveň si povedať o plánoch do budúcnosti.
Čo sa zmenilo vo werf v1.1?
Nový formát názvov štádií a algoritmus na výber štádií z vyrovnávacej pamäte
Nové pravidlo generovania umeleckých mien. Teraz každá zostava fázy generuje jedinečný názov štádia, ktorý pozostáva z 2 častí: podpis (ako vo verzii 1.0) plus jedinečný dočasný identifikátor.
Úplný názov javiskového obrázka môže vyzerať napríklad takto:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...alebo všeobecne:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
tu:
-
SIGNATUREje podpis fázy, ktorý predstavuje identifikátor obsahu fázy a závisí od histórie úprav v systéme Git, ktoré viedli k tomuto obsahu; -
TIMESTAMP_MILLISECje zaručený jedinečný identifikátor obrázka, ktorý sa generuje v čase vytvorenia nového obrázka.
Algoritmus na výber štádií z vyrovnávacej pamäte je založený na kontrole vzťahu potvrdení Git:
- Werf vypočíta signatúru určitého štádia.
- В etapy-ukladanie Pre daný podpis môže existovať niekoľko fáz. Werf vyberie všetky fázy, ktoré zodpovedajú podpisu.
- Ak je aktuálna fáza prepojená s Git (archiv git, vlastná fáza s opravami Git:
install,beforeSetup,setup; alebo git-latest-patch), potom werf vyberie len tie fázy, ktoré sú spojené s odovzdaním, ktoré je predchodcom aktuálneho odovzdania (pre ktoré sa volá zostava). - Zo zostávajúcich vhodných etáp sa vyberie jedna – najstaršia podľa dátumu vytvorenia.
Stage pre rôzne vetvy Git môže mať rovnaký podpis. Ale werf zabráni použitiu vyrovnávacej pamäte spojenej s rôznymi vetvami medzi týmito vetvami, aj keď sa podpisy zhodujú.
.
Nový algoritmus na vytváranie a ukladanie etáp v úložisku fázy
Ak pri výbere etáp z vyrovnávacej pamäte werf nenájde vhodnú fázu, začne sa proces zostavovania novej fázy.
Všimnite si, že viaceré procesy (na jednom alebo viacerých hostiteľoch) môžu začať budovať rovnakú fázu približne v rovnakom čase. Werf používa optimistický blokovací algoritmus etapy-ukladanie v momente uloženia čerstvo zozbieraného obrázka do etapy-ukladanie. Týmto spôsobom, keď je zostava novej fázy pripravená, bloky werf etapy-ukladanie a uloží tam čerstvo zozbieraný obrázok iba vtedy, ak tam už vhodný obrázok neexistuje (podľa podpisu a ďalších parametrov - pozri nový algoritmus na výber štádií z vyrovnávacej pamäte).
Je zaručené, že čerstvo zostavený obrázok bude mať jedinečný identifikátor TIMESTAMP_MILLISEC (pozrite si nový formát pomenovávania). V prípade, že v etapy-ukladanie nájde sa vhodný obrázok, werf zahodí čerstvo zostavený obrázok a použije obrázok z vyrovnávacej pamäte.
Inými slovami: prvý proces na dokončenie vytvárania obrazu (najrýchlejší) získa právo na jeho uloženie v etapách (a potom je to tento jediný obraz, ktorý sa použije pre všetky zostavenia). Pomalý proces zostavovania nikdy nezablokuje rýchlejšiemu procesu uloženie výsledkov zostavenia aktuálnej fázy a prechod na ďalšiu zostavu.
.
Vylepšený výkon nástroja na tvorbu súborov Dockerfile
V súčasnosti sa reťazec fáz pre obrázok vytvorený z Dockerfile skladá z jednej fázy – dockerfile. Pri výpočte podpisu sa vypočíta kontrolný súčet súborov context, ktorý sa použije pri montáži. Pred týmto vylepšením werf rekurzívne prechádzal všetkými súbormi a získal kontrolný súčet sčítaním kontextu a režimu každého súboru. Počnúc verziou 1.1 môže werf používať vypočítané kontrolné súčty uložené v úložisku Git.
Algoritmus je založený na . Algoritmus berie do úvahy záznamy v .dockerignore a rekurzívne prechádza stromom súborov iba v prípade potreby. Oddelili sme sa teda od čítania súborového systému a závislosti algoritmu od veľkosti context nie je významný.
Algoritmus tiež kontroluje nesledované súbory a v prípade potreby ich zohľadňuje v kontrolnom súčte.
Vylepšený výkon pri importovaní súborov
Verzie werf v1.1 používajú server rsync, keď . Predtým sa import robil v dvoch krokoch pomocou pripojenia adresára z hostiteľského systému.
Výkon importu v systéme macOS už nie je obmedzený objemami Docker a importy sú dokončené za rovnaký čas ako Linux a Windows.
Označovanie založené na obsahu
Werf v1.1 podporuje takzvané označovanie podľa obsahu obrázka - označovanie založené na obsahu. Značky výsledných obrázkov Docker závisia od obsahu týchto obrázkov.
Pri spustení príkazu werf publish --tags-by-stages-signature alebo werf ci-env --tagging-strategy=stages-signature zverejnené snímky tzv javiskový podpis obrázok. Každý obrázok je označený vlastným podpisom fáz tohto obrázka, ktorý sa vypočíta podľa rovnakých pravidiel ako bežný podpis každého štádia samostatne, ale je všeobecným identifikátorom obrázka.
Podpis fáz obrazu závisí od:
- obsah tohto obrázku;
- histórie zmien Git, ktoré viedli k tomuto obsahu.
Úložisko Git má vždy fiktívne odovzdania, ktoré nemenia obsah súborov obrázkov. Napríklad potvrdenia iba s komentármi alebo zlúčené potvrdenia alebo potvrdenia, ktoré zmenia tie súbory v Gite, ktoré sa neimportujú do obrazu.
Pri používaní tagovania založeného na obsahu sú vyriešené problémy so zbytočným reštartovaním aplikačných modulov v Kubernetes kvôli zmenám v názve obrázka, aj keď sa obsah obrázka nezmenil. Mimochodom, toto je jeden z dôvodov, ktorý bráni ukladaniu mnohých mikroslužieb jednej aplikácie do jedného úložiska Git.
Označovanie založené na obsahu je tiež spoľahlivejšou metódou značkovania ako značkovanie na vetvách Git, pretože obsah výsledných obrázkov nezávisí od poradia, v ktorom sa v systéme CI vykonávajú pipeline na zostavenie viacerých odovzdaní rovnakej vetvy.
Je to dôležité,: odteraz etapy-podpis - je jediná odporúčaná stratégia značkovania. Štandardne sa použije v príkaze werf ci-env (pokiaľ výslovne nešpecifikujete inú schému označovania).
. Tejto funkcii bude venovaná aj samostatná publikácia. AKTUALIZOVANÉ (3. apríla): Článok s podrobnosťami .
Úrovne protokolovania
Používateľ má teraz možnosť ovládať výstup, nastaviť úroveň protokolovania a pracovať s informáciami o ladení. Možnosti boli pridané --log-quiet, --log-verbose, --log-debug.
Výstup štandardne obsahuje minimálne informácie:
Pri použití podrobného výstupu (--log-verbose) môžete vidieť, ako funguje werf:
Podrobný výstup (--log-debug), okrem informácií o ladení werf obsahuje aj protokoly použitých knižníc. Môžete napríklad vidieť, ako prebieha interakcia s registrom Docker, a tiež zaznamenať miesta, kde trávite značné množstvo času:
Ďalšie plány
Varovanie! Možnosti popísané nižšie sú označené v1.1 budú dostupné v tejto verzii, mnohé z nich v blízkej budúcnosti. Aktualizácie budú prebiehať prostredníctvom automatických aktualizácií . Tieto vlastnosti neovplyvňujú stabilnú časť funkcií v1.1, ich vzhľad nebude vyžadovať manuálny zásah používateľa do existujúcich konfigurácií.
Plná podpora pre rôzne implementácie Docker Registry (NOVINKA)
- Verzia: v1.1
- Termíny: marec
Cieľom je, aby používateľ pri používaní werf používal vlastnú implementáciu bez obmedzení.
V súčasnosti sme identifikovali nasledujúcu sadu riešení, pre ktoré budeme garantovať plnú podporu:
- Predvolené (knižnica/register)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- Balíky GitHub
- register GitLab*,
- prístav*,
- Quay.
Riešenia, ktoré v súčasnosti plne podporuje werf, sú označené hviezdičkou. Pre ostatných existuje podpora, ale s obmedzeniami.
Možno identifikovať dva hlavné problémy:
- Niektoré riešenia nepodporujú odstraňovanie značiek pomocou rozhrania Docker Registry API, čo bráni používateľom používať automatické čistenie werf. Platí to pre balíky AWS ECR, Docker Hub a GitHub.
- Niektoré riešenia nepodporujú takzvané vnorené úložiská (Docker Hub, GitHub Packages a Quay) alebo podporujú, ale používateľ si ich musí vytvoriť manuálne pomocou používateľského rozhrania alebo API (AWS ECR).
Tieto a ďalšie problémy budeme riešiť pomocou natívnych API riešení. Táto úloha zahŕňa aj pokrytie celého cyklu prevádzky werf testami pre každý z nich.
Vytvorenie distribuovaného obrázka (↑)
- Verzia: v1.2 v1.1 (priorita implementácie tejto funkcie bola zvýšená)
- Termíny: marec-apríl marec
V súčasnosti je možné použiť werf v1.0 a v1.1 iba na jednom vyhradenom hostiteľovi na operácie vytvárania a publikovania obrázkov a nasadzovania aplikácie do Kubernetes.
Na otvorenie možností distribuovanej práce werf, keď je zostavovanie a nasadzovanie aplikácií v Kubernetes spustené na niekoľkých ľubovoľných hostiteľoch a títo hostitelia neukladajú svoj stav medzi zostaveniami (dočasné bežce), je potrebné, aby werf implementoval schopnosť používať Docker Registry ako úložisko fázy.
Predtým, keď sa projekt werf ešte volal dapp, mal takúto príležitosť. Stretli sme sa však s množstvom problémov, ktoré je potrebné vziať do úvahy pri implementácii tejto funkcionality vo werf.
Poznámka. Táto funkcia nevyžaduje, aby zberač pracoval vo vnútri modulov Kubernetes, pretože Ak to chcete urobiť, musíte sa zbaviť závislosti na lokálnom serveri Docker (v Kubernetes pod nie je prístup k lokálnemu serveru Docker, pretože samotný proces beží v kontajneri a werf nepodporuje a nebude podporovať práca so serverom Docker cez sieť). Podpora spustenia Kubernetes bude implementovaná samostatne.
Oficiálna podpora pre akcie GitHub (NOVINKA)
- Verzia: v1.1
- Termíny: marec
Zahŕňa dokumentáciu werf (oddiely odkaz и sprievodca), ako aj oficiálnu akciu GitHub pre prácu s werfom.
Okrem toho umožní werf pracovať na efemérnych bežcoch.
Mechanika interakcie používateľa so systémom CI bude založená na umiestnení štítkov na žiadosti o stiahnutie na spustenie určitých akcií na zostavenie/spustenie aplikácie.
Lokálny vývoj a nasadenie aplikácií s werf (↓)
- Verzia: v1.1
- Termíny: január-február apríl
Hlavným cieľom je dosiahnuť jedinú zjednotenú konfiguráciu pre lokálne aj produkčné nasadenie aplikácií bez zložitých akcií hneď po vybalení.
werf je tiež povinný mať prevádzkový režim, v ktorom bude pohodlné upravovať kód aplikácie a okamžite dostávať spätnú väzbu od spustenej aplikácie na ladenie.
Nový čistiaci algoritmus (NOVINKA)
- Verzia: v1.1
- Termíny: apríl
V aktuálnej verzii werf v1.1 v postupe cleanup Neexistuje žiadne ustanovenie na čistenie obrázkov pre schému označovania podľa obsahu – tieto obrázky sa budú hromadiť.
Aktuálna verzia werf (v1.0 a v1.1) tiež používa rôzne politiky čistenia pre obrázky publikované podľa schém označovania: vetva Git, značka Git alebo odovzdanie Git.
Bol vynájdený nový algoritmus na čistenie obrázkov založený na histórii commitov v Git, zjednotený pre všetky schémy označovania:
- Pre každý git HEAD (vetvy a značky) neuchovávajte viac ako N1 obrázkov spojených s najnovšími potvrdeniami N2.
- Pre každý git HEAD (vetvy a značky) neukladajte viac obrázkov štádia ako N1 spojených s najnovšími potvrdeniami N2.
- Uložte všetky obrázky, ktoré sa používajú v akýchkoľvek prostriedkoch klastra Kubernetes (skontrolujú sa všetky kontexty kube konfiguračného súboru a priestory názvov; toto správanie môžete obmedziť pomocou špeciálnych možností).
- Uložte všetky obrázky, ktoré sa používajú v manifestoch konfigurácie prostriedkov uložených vo vydaniach Helm.
- Obrázok je možné odstrániť, ak nie je priradený k žiadnemu HEAD z git (napríklad preto, že príslušný HEAD samotný bol odstránený) a nie je použitý v žiadnych manifestoch v klastri Kubernetes a vo vydaniach Helm.
Vytváranie paralelného obrazu (↓)
- Verzia: v1.1
- Termíny: január-február apríl*
Aktuálna verzia werf zhromažďuje obrázky a artefakty opísané v werf.yaml, postupne. Je potrebné paralelizovať proces zostavovania nezávislých fáz obrázkov a artefaktov, ako aj poskytnúť pohodlný a informatívny výstup.
* Poznámka: Termín bol posunutý z dôvodu zvýšenej priority pre implementáciu distribuovaného zostavovania, ktoré pridá viac možností horizontálneho škálovania, ako aj použitie werf s akciami GitHub. Paralelná montáž je ďalším optimalizačným krokom, ktorý poskytuje vertikálnu škálovateľnosť pri montáži jedného projektu.
Prechod na Helm 3 (↓)
- Verzia: v1.2
- Termíny: február-marec máj*
Zahŕňa migráciu na novú kódovú základňu a osvedčený, pohodlný spôsob migrácie existujúcich inštalácií.
* Poznámka: Prechod na Helm 3 nepridá do werf žiadne významné funkcie, pretože všetky kľúčové vlastnosti Helm 3 (3-smerné zlúčenie a žiadne kormidlo) sú už implementované vo werf. Okrem toho má werf okrem uvedených. Tento prechod však zostáva v našich plánoch a bude realizovaný.
Jsonnet na popis konfigurácie Kubernetes (↓)
- Verzia: v1.2
- Termíny: január-február apríl-máj
Werf bude podporovať popisy konfigurácie pre Kubernetes vo formáte Jsonnet. Werf zároveň zostane kompatibilný s Helmom a bude možnosť výberu formátu popisu.
Dôvodom je, že šablóny Go majú podľa mnohých ľudí vysokú vstupnú bariéru a tým trpí aj zrozumiteľnosť kódu týchto šablón.
Zvažuje sa aj možnosť zavedenia ďalších systémov na popis konfigurácie Kubernetes (napríklad Kustomize).
Práca v Kubernetes (↓)
- Verzia: v1.2
- Termíny: apríl-máj máj-jún
Cieľ: Zabezpečte, aby sa obrázky vytvorili a aplikácia sa doručila pomocou bežcov v Kubernetes. Tie. Nové obrázky je možné vytvárať, publikovať, čistiť a nasadzovať priamo z modulov Kubernetes.
Ak chcete implementovať túto schopnosť, musíte byť najprv schopní vytvoriť distribuované obrazy (pozri bod vyššie).
Vyžaduje tiež podporu pre prevádzkový režim tvorcu bez servera Docker (t. j. zostava podobná Kaniko alebo zostava v používateľskom priestore).
Werf bude podporovať stavanie na Kubernetes nielen s Dockerfile, ale aj s jeho Stapel builderom s postupnými prestavbami a Ansible.
Krok k otvorenému rozvoju
Milujeme našu komunitu (, ) a chceme, aby stále viac ľudí pomáhalo zlepšovať werf, chápali smer, ktorým sa uberáme, a podieľali sa na rozvoji.
Pomerne nedávno sa rozhodlo o prechode na s cieľom odhaliť pracovný proces nášho tímu. Teraz môžete vidieť okamžité plány, ako aj súčasnú prácu v nasledujúcich oblastiach:
- ;
- ;
- ;
- .
Veľa práce sa urobilo s problémami:
- Nerelevantné boli odstránené.
- Tie existujúce sú dovedené do jednotného formátu s dostatočným množstvom detailov a detailov.
- Boli pridané nové čísla s nápadmi a návrhmi.
Ako povoliť verziu v1.1
Verzia je momentálne dostupná v (v kanáloch stabilný и pevný ako skala uvoľnenia sa však objavia, keď dôjde k stabilizácii ea sám o sebe je už dostatočne stabilný na použitie, pretože prešiel cez kanály alfa и beta). Aktivované nasledujúcim spôsobom:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Záver
Nová architektúra úložiska štádia a optimalizácie staviteľov pre staviteľov Stapel a Dockerfile otvárajú možnosť implementácie distribuovaných a paralelných verzií vo werf. Tieto funkcie sa čoskoro objavia v rovnakom vydaní v1.1 a budú automaticky dostupné prostredníctvom mechanizmu automatických aktualizácií (pre používateľov ).
V tomto vydaní bola pridaná stratégia označovania založená na obsahu obrázkov – označovanie založené na obsahu, ktorá sa stala predvolenou stratégiou. Hlavný protokol príkazov bol tiež prepracovaný: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Ďalším dôležitým krokom je pridanie distribuovaných zostáv. Distribuované zostavy sa od verzie 1.0 stali vyššou prioritou ako paralelné zostavy, pretože pridávajú väčšiu hodnotu werf: vertikálne škálovanie zostavovateľov a podpora efemérnych zostavovateľov v rôznych systémoch CI/CD, ako aj možnosť oficiálne podporovať akcie GitHub. . Preto sa termíny realizácie paralelných montáží posunuli. Pracujeme však na tom, aby sme obe možnosti implementovali čo najskôr.
Sledujte novinky! A nezabudnite nás navštíviť na vytvoriť problém, nájsť existujúci a pridať plus, vytvoriť PR alebo jednoducho sledovať vývoj projektu.
PS
Prečítajte si aj na našom blogu:
- «»
- «»;
- Séria poznámok o inováciách vo werf:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com