— náš GitOps CLI nástroj s otvoreným zdrojovým kódom na zostavenie a dodanie aplikácií do Kubernetes. Ako sme sľúbili, znamenalo začiatok pridávania nových funkcií do werf a prehodnotenie bežných prístupov. Teraz s radosťou predstavujeme vydanie v1.1, ktoré je veľkým krokom vpred a základom pre budúcnosť stavača werf. Verzia je momentálne k dispozícii na .
Základom vydania je nová architektúra úložiska fáz a optimalizácia práce oboch stavačov (pre Stapel a Dockerfile). Nová architektúra úložiska otvára možnosti pre realizáciu distribuovaných zostavení z viacerých hostiteľov a paralelné zostavenia na jednom hostiteľovi.
Optimalizácia práce zahŕňa zbavenie sa zbytočných výpočtov v etape výpočtu podpisov fáz a zmenu mechanizmov výpočtu kontrolných súčtov súborov na efektívnejšie. Táto optimalizácia znižuje priemerný čas zostavení projektu pomocou werf. A prázdne zostavenia, keď všetky fázy existujú v cache stages-storage, sú teraz skutočne rýchle. V väčšine prípadov opakované spustenie zostavenia prebehne rýchlejšie ako za 1 sekundu! To sa tiež týka procedúr overovania fáz počas práce tímov werf deploy a werf run.
Taktiež v tomto vydaní pribudla stratégia tagovania obrazov na základe obsahu — content-based tagging, ktorá je teraz zapnutá ako predvolená a je jedinou odporúčanou.
Pozrime sa podrobnejšie na kľúčové novinky v werf v1.1 a zároveň sa podelíme o plány do budúcnosti.
Čo sa zmenilo vo werf v1.1?
Nový formát názvov fáz a algoritmus výberu fáz z cache
Nové pravidlo generovania názvu fázy. Teraz každé zostavenie fázy generuje unikátne meno fázy, ktoré sa skladá z 2 častí: podpis (ako to bolo vo v1.0) plus unikátny časový identifikátor.
Napríklad, plné meno obrazu fázy môže vyzerať takto:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… alebo vo všeobecnom formáte:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Tu:
-
SIGNATURE— to je podpis fázy, ktorý predstavuje identifikátor obsahu fázy a závisí od histórie zmien v Git, ktoré viedli k tomuto obsahu; -
TIMESTAMP_MILLISEC— to je zaručene unikátna identifikácia obrazu, ktorá sa generuje v okamihu zostavenia nového obrazu.
Algoritmus výberu fáz z cache je založený na kontrole príbuznosti Git commitov:
- Werf určuje signatúru určitej fázy.
- V stages-storage Môže existovať niekoľko fáz na základe tejto signatúry. Werf vyberá všetky vhodné fázy podľa signatúry.
- Ak je aktuálna fáza spojená s Git (git-archive, používateľská fáza s Git-patchmi:
install,beforeSetup,setup; alebo git-latest-patch), werf vyberá iba tie fázy, ktoré súvisia s commitom, ktorý je predkom aktuálneho commitu (pre ktorý bola zvolaná zostava). - Z zostávajúcich vhodných fáz sa vyberie jedna — najstaršia podľa dátumu vytvorenia.
Fáza pre rôzne Git vetvy môže mať rovnakú signatúru. Ale werf zabráni používaniu cache súvisiacej s rôznymi vetvami medzi týmito vetvami, aj keby sa signatúry zhodovali.
.
Nový algoritmus pre vytváranie a ukladanie fáz v úložisku fáz
Ak počas vyhľadávania fáz z cache werf nenájde vhodnú fázu, iniciuje sa proces vytvorenia novej fázy.
Všimnite si, že niekoľko procesov (na jednom alebo viacerých hostiteľoch) môže začať zostavovať rovnakú fázu približne v rovnakom čase. Werf používa algoritmus optimistickej blokácie stages-storage v čase ukladaní čerstvo zostaveného obrazu do stages-storage. Takže, keď bude zostavená nová fáza, werf zablokuje stages-storage a uloží tam čerstvo zostavený obraz len v prípade, ak tam už neexistuje vhodný obraz (podľa signatúry a iných parametrov — pozri nový algoritmus vyhľadávania fáz z cache).
Čerstvo zostavený obraz bude mať zaručene unikátne identifikátor podľa TIMESTAMP_MILLISEC (pozri nový formát pomenovania fáz). V prípade, že v stages-storage bude nájdený vhodný obraz, werf odmietne čerstvo zostavený obraz a použije obraz z cache.
Inými slovami: prvý proces, ktorý dokončí zostavovanie obrazu (najrýchlejší), získava právo uložiť ho do stages-storage (a potom tento jediný obraz bude použitý pre všetky zostavy). Pomalý proces zostavovania nikdy nezablokuje rýchlejší proces pred uložením výsledkov zostavovania aktuálnej fázy a prechodom k zostaveniu ďalšej.
.
Vylepšený výkon zostavovača Dockerfile
V súčasnosti je potrubie fáz pre obraz zostavovaný z Dockerfile zložené z jednej fázy — dockerfile. Pri výpočte signatúry sa berie do úvahy kontrolná suma súborov context, ktoré sa budú používať pri zostavovaní. Pred týmto vylepšením werf rekurzívne prechádzal všetkými súbormi a získaval kontrolný súčet, sčítať kontext a mod každého súboru. Od verzií v1.1 môže werf používať vypočítané kontrolné súčty uložené v Git repozitári.
Základ algoritmu je . Algoritmus zohľadňuje záznamy v .dockerignore a prechádza rekurzívne po strome súborov iba v prípade potreby. Takto sme sa oslobodili od čítania súborového systému, a závislosť algoritmu od veľkosti context nie je významná.
Algoritmus tiež kontroluje untracked súbory a v prípade potreby ich zohľadňuje v kontrolnom súčte.
Vylepšený výkon pri importovaní súborov
Vo verziách werf v1.1 sa používa rsync server pri . Predtým sa importovanie realizovalo v dvoch krokoch s použitím montovania adresára z hostiteľského systému.
Výkon importov na macOS už nie je obmedzený Docker volumes, a importy sa vykonávajú za rovnaký čas ako v Linuxe a Windows.
Tagovanie na základe obsahu
Werf v1.1 podporuje tzv. tagovanie na základe obsahu obrazu — content-based tagging. Tagy výsledných Docker obrazov závisia od obsahu týchto obrazov.
Pri spustení príkazu werf publish --tags-by-stages-signature alebo werf ci-env --tagging-strategy=stages-signature budú označené publikované obrazy tzv. podpisom etáp obrazu. Každý obraz je označený svojou vlastnou etapu podpisu tohto obrazu, ktorá sa vypočítava podľa rovnakých pravidiel ako bežný podpis každej zo štádií jednotlivo, ale je zovšeobecneným identifikátorom obrazu.
Podpis etáp obrazu závisí od:
- obsahu tohto obrazu;
- histórie úprav v Git, ktoré viedli k tomuto obsahu.
V Git repozitári sú vždy prázdne commit-y, ktoré nemenia obsah súborov obrazu. Napríklad, commit-y len s komentármi, alebo merge commit-y, alebo commit-y, ktoré menia tie súbory v Gite, ktoré nebudú importované do obrazu.
Pri použití tagovania na základe obsahu sa riešia problémy s nadbytočnými reštartami pod-ov aplikácie v Kubernetes kvôli zmenám názvu obrazu, aj keď sa obsah obrazu nezmenil. Mimochodom, to je jedna z príčin, ktoré bránia uchovávaniu mnohých mikroslužieb jedného aplikácie v jednom Git repozitári.
Content-based tagging je spoľahlivejší spôsob tagovania ako tagovanie podľa Git vetiev, pretože obsah výsledných obrazov nezávisí od poradia vykonávania pipeline'ov v CI systéme na zostavenie viacerých commitov z tej istej vetvy.
Dôležité: od tejto chvíle stages-signature — sú jediná odporúčaná stratégia tagovania. Práve táto stratégia sa bude používať ako predvolená v tíme werf ci-env (pokiaľ nie je výslovne uvedená iná schéma tagovania).
. Táto funkcia bude mať tiež svoj vlastný článok. AKTUALIZOVANÉ (3. apríla): Článok s detailami .
Úrovne logovania
Používateľ má teraz možnosť ovládať výstup, nastaviť úroveň logovania a pracovať s diagnostickými informáciami. Pridali sa možnosti --log-quiet, --log-verbose, --log-debug.
Predvolené nastavenie obsahuje minimum informácií:
Pri použití podrobného výstupu (--log-verbose) je možné sledovať, ako funguje werf:
Podrobný výstup (--log-debug), okrem diagnostických informácií werf, obsahuje aj logy používaných knižníc. Napríklad je možné vidieť, ako prebieha interakcia s Docker Registry a zaznamenať miesta, kde sa trávi značný čas:
Ďalšie plány
Pozor! Možnosti uvedené nižšie s označením v1.1 budú k dispozícii už v tejto verzii, mnohé z nich — čoskoro. Aktualizácie prídu prostredníctvom automatických aktualizácií . Tieto možnosti neovplyvňujú stabilnú časť funkcií v1.1, ich zavedenie si nevyžaduje ručné zásahy používateľa do už existujúcich konfigurácií.
Úplná podpora rôznych realizácií Docker Registry (NOVÉ)
- Verzia: v1.1
- Termíny: marec
Cieľ — používateľ by mal mať možnosť používať ľubovoľnú realizáciu bez obmedzení pri používaní werf.
V súčasnosti sme vyčlenili nasledujúcu sadu riešení, pre ktoré máme v úmysle garantovať plnú podporu:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Hvezdičkou sú označené riešenia, ktoré sú v súčasnosti úplne podporované werf. Pre ostatné je podpora, ale s obmedzeniami.
Môžeme identifikovať dva hlavné problémy:
- Niektoré riešenia nepodporujú odstraňovanie tagov pomocou Docker Registry API, čo neumožňuje používateľom využívať automatické čistenie implementované v werf. Toto platí pre AWS ECR, Docker Hub a GitHub Packages.
- Nie všetky riešenia podporujú takzvané nested repositories (Docker Hub, GitHub Packages a Quay) alebo ich podporujú, ale používateľ ich musí vytvoriť manuálne pomocou UI alebo API (AWS ECR).
These and other issues we plan to address using native APIs of the solutions. This task also includes covering the entire lifecycle tests of werf for each of them.
Distribuované zostavenie obrazov (↑)
- Verzia: v1.2 v1.1 (priorita pre implementáciu tejto funkcie bola zvýšená)
- Termíny: marec-apríl marec
V súčasnosti je možné používať werf v1.0 a v1.1 iba na jednom vyhradenom hostiteľovi na operácie zostavenia a publikovania obrazov a nasadenia aplikácií v Kubernetes.
Aby sa otvorili možnosti distribuovanej práce werf, keď sa zisťovanie a nasadenie aplikácií v Kubernetes spúšťajú na viacerých ľubovoľných hostiteľoch a tieto hostitelia si medzi zostaveniami neuchovávajú svoje stavy (dočasné runner’y), werf vyžaduje realizáciu možnosti používania Docker Registry ako úložiska krokov.
Predtým, keď sa projekt werf ešte volal dapp, mala táto funkcia. Narazili sme však na niekoľko problémov, ktoré je potrebné zohľadniť pri implementácii tejto funkcie do werf.
Poznámka. Táto funkcia nepredpokladá prácu zostavovača v pod’och Kubernetes, pretože je potrebné sa zbaviť závislosti od lokálneho Docker-servera (v pod’e Kubernetes nemáte prístup k lokálnemu Docker-serveru, pretože samotný proces beží v kontajneri, a práca s Docker-serverom cez sieť werf nepodporuje a nebude podporovať). Podpora práce v Kubernetes bude implementovaná samostatne.
Oficiálna podpora GitHub Actions (NOVINKA)
- Verzia: v1.1
- Termíny: marec
Zahŕňa dokumentáciu werf (sekcie reference a guide), ako aj oficiálny GitHub Action pre prácu s werf.
Okrem toho umožní pracovať werf na efemérnych runner’och.
Mechanika interakcie používateľa s CI systémom bude založená na označovaní pull-request’ov pre iniciovanie určitých akcií pri zostavení/vydaní 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ť jednotný unifikovaný konfiguráčný súbor pre nasadenie aplikácií ako lokálne, tak aj v produkcii, bez zložitých krokov, "z krabice".
Od werf je potrebný aj taký režim, v ktorom bude pohodlné upravovať kód aplikácie a okamžite získavať spätnú väzbu od funkčnej aplikácie na ladenie.
Nový algoritmus čistenia (NOVÉ)
- Verzia: v1.1
- Termíny: apríl
V aktuálnej verzii werf v1.1 nie je v procese cleanup predpokladaná činnosť čistenia obrazov pre schému označovania na základe obsahu (content-based tagging) — tieto obrazy sa budú hromadiť.
Taktiež v aktuálnej verzii werf (v1.0 a v1.1) sa používajú rôzne politiky čistenia pre obrazy, ktoré boli zverejnené podľa schém označovania: Git-vetva, Git-označenie alebo Git-komit.
Bol vymyslený nový unifikovaný algoritmus čistenia obrazov pre všetky schémy označovania na základe histórie komitov v Gite:
- Udržiavať maximálne N1 obrazov súvisiacich s N2 poslednými komitmi pre každého z git HEAD (vetvy a tagy).
- Udržiavať maximálne N1 obrazov-stádií, súvisiacich s N2 poslednými komitmi pre každého z git HEAD (vetvy a tagy).
- Udržiavať všetky obrazy, ktoré sa používajú v akýchkoľvek zdrojoch klastru Kubernetes (skenujú sa všetky kube-kontexty konfiguračného súboru a namespace'y; toto správanie je možné obmedziť špeciálnymi možnosťami).
- Udržiavať všetky obrazy, ktoré sa používajú v manifestoch konfigurácie zdrojov, uložených v Helm-vydaniach.
- Obraz môže byť odstránený, ak nie je spojený s žiadnym HEAD zo gitu (napríklad preto, že príslušný HEAD bol odstránený) a nie je používaný v žiadnom z manifestov v klastru Kubernetes a v vydaniach Helm.
Paralelné zostavovanie obrazov (↓)
- Verzia: v1.1
- Termíny: január-február apríl*
Aktuálna verzia werf zostavuje obrazy a artefakty, ktoré sú opísané v werf.yaml, po sebe. Je potrebné sprístupniť proces zostavovania nezávislých štádií obrazov a artefaktov, ako aj zabezpečiť pohodlný a informatívny výstup.
* Poznámka: termín bol posunutý z dôvodu zvýšenej priority na realizáciu distribuovanej zostavy, ktorá pridá viac možností pre horizontálne škálovanie, ako aj pre použitie werf s GitHub Actions. Paralelné zostavovanie je ďalším krokom optimalizácie, ktorý prináša vertikálnu škálovateľnosť pri zostavovaní jedného projektu.
Prechod na Helm 3 (↓)
- Verzia: v1.2
- Termíny: február-marec máj*
Zahŕňa prechod na novú kódovú základňu a overený, pohodlný spôsob migrácie existujúcich inštalácií.
* Poznámka: prechod na Helm 3 neprinesie významné nové možnosti do werf, pretože všetky kľúčové funkcie Helm 3 (3-way-merge a absencia tiller) sú už implementované v werf. Navyše, werf má okrem uvedených. Avšak tento prechod zostáva v našich plánoch a bude realizovaný.
Jsonnet na opis konfigurácie Kubernetes (↓)
- Verzia: v1.2
- Termíny: január-február apríl-máj
Werf bude podporovať opis konfigurácie pre Kubernetes vo formáte Jsonnet. Zároveň zostane werf kompatibilný s Helm a bude možnosť výberu formátu opisu.
Príčinou je fakt, že šablóny jazyka Go, podľa názoru mnohých, majú vysokú prahovú hodnotu pre vstup a prehľadnosť kódu týchto šablón tiež trpí.
Taktiež sa zvažuje implementácia iných systémov na opis konfigurácie Kubernetes (napríklad Kustomize).
Práca v rámci Kubernetes (↓)
- Verzia: v1.2
- Termíny: apríl-máj máj-jún
Cieľ: zabezpečiť zostavenie obrazov a dodávku aplikácie pomocou runnerov v Kubernetes. T.j. zostavenie nových obrazov, ich publikácia, čistenie a nasadenie môžu prebiehať priamo z podov Kubernetes.
Na realizáciu tejto možnosti je najprv potrebná možnosť distribuovaného zostavenia obrazov (pozri vyššie).
Taktiež je potrebná podpora režimu práce zostavovača bez Docker servera (t.j. Kaniko-podobné zostavenie alebo zostavenie v userspace).
Werf bude podporovať zostavenie v Kubernetes nielen pomocou Dockerfile, ale aj pomocou svojho zostavovača Stapel s inkrementálnymi prebudovaniami a Ansible.
Krok smerom k otvorenému vývoju
Milujeme našu komunitu (, ) a chceme, aby čoraz viac ľudí pomáhalo zlepšiť werf, chápalo, ktorým smerom sa uberáme, a zúčastňovalo sa na vývoji.
Prednedávnom bolo rozhodnuté prejsť na aby sme otvorili pracovný proces našej tímu. Teraz je možné vidieť najbližšie plány a aktuálne práce v nasledujúcich oblastiach:
- ;
- ;
- ;
- .
Bola vykonaná veľká práca s issues:
- Nevhodné boli odstránené.
- Existujúce boli uvedené do jednotného formátu, dostatočného počtu detailov a podrobností.
- Boli pridané nové issues s nápadmi a návrhmi.
Ako zapnúť verziu v1.1
Verzia je momentálne dostupná v (v kanáloch stable a rock-solid release sa objavia, keď sa stabilizujú, avšak ea sama o sebe je už dosť stabilná na používanie, pretože prešla kanálmi alpha a beta). Aktivuje sa nasledujúcim spôsobom:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Záver
Nová architektúra ukladania fáz a optimalizácia práce zostavovateľa pre Stapel a Dockerfile zostavovateľov otvára možnosti realizovať distribuované a paralelné zostavenia v werf. Tieto možnosti čoskoro pribudnú v tej istej verzii v1.1 a budú automaticky dostupné cez mechanizmus automatických aktualizácií (pre používateľov ).
V tejto verzii bola pridaná stratégia tagovania podľa obsahu obrazov — content-based tagging, — ktorá sa stala predvolenou stratégiou. A bol prepracovaný log základných príkazov: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Ďalším významným krokom bude pridaní distribuovaných zostavení. Distribuované zostavovania sa od verzie v1.0 stali prioritnejšou úlohou, než paralelné zostavovania, pretože pridávajú väčšiu hodnotu werf: vertikálne škálovanie zostavovateľov a podpora efemérnych zostavovateľov v rôznych CI/CD systémoch, ako aj možnosť oficiálnej podpory pre GitHub Actions. Preto sa termíny realizácie paralelných zostavení posunuli. Avšak pracujeme na tom, aby sme čoskoro implementovali obe možnosti.
Sledujte novinky! A nezabudnite sa k nám prísť pozrieť na , aby ste vytvorili issue, našli už existujúce a dali plus, vytvorili PR alebo len sledovali rozvoj projektu.
P.S.
Prečítajte si tiež na našom blogu:
- «»
- «»;
- Cyklus poznámok o novinkách vo werfe:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
