🥇Lëshimi i Werf 1.1: përmirësime në koleksionist sot dhe planet për të ardhmen

werf është mjeti ynë me burim të hapur GitOps CLI për ndërtimin dhe dërgimin e aplikacioneve në Kubernetes. Siç kishte premtuar, lëshimi i versionit v1.0 shënoi fillimin e shtimit të veçorive të reja në werf dhe rishikimin e qasjeve tradicionale. Tani jemi të kënaqur të prezantojmë versionin 1.1, i cili është një hap i madh në zhvillim dhe një themel për të ardhmen koleksionist werf. Versioni është aktualisht i disponueshëm në kanali 1.1 ea.

Baza e publikimit është arkitektura e re e ruajtjes së skenës dhe optimizimi i punës së të dy koleksionistëve (për Stapel dhe Dockerfile). Arkitektura e re e ruajtjes hap mundësinë e zbatimit të asambleve të shpërndara nga hoste të shumtë dhe asambletë paralele në të njëjtin host.

Optimizimi i punës përfshin heqjen e llogaritjeve të panevojshme në fazën e llogaritjes së nënshkrimeve të fazës dhe ndryshimin e mekanizmave për llogaritjen e shumave të kontrollit të skedarëve në ato më efikase. Ky optimizim zvogëlon kohën mesatare të ndërtimit të projektit duke përdorur werf. Dhe ndërtimet boshe, kur të gjitha fazat ekzistojnë në cache faza-ruajtje, tani janë vërtet të shpejtë. Në shumicën e rasteve, rinisja e ndërtimit do të marrë më pak se 1 sekondë! Kjo vlen edhe për procedurat për verifikimin e fazave në procesin e punës së ekipeve. werf deploy и werf run.

Gjithashtu në këtë version, u shfaq një strategji për etiketimin e imazheve sipas përmbajtjes - etiketimi i bazuar në përmbajtje, e cila tani është e aktivizuar si parazgjedhje dhe e vetmja e rekomanduar.

Le të hedhim një vështrim më të afërt në risitë kryesore në werf v1.1 dhe në të njëjtën kohë t'ju tregojmë për planet për të ardhmen.

Çfarë ka ndryshuar në werf v1.1?

Formati dhe algoritmi i ri i emërtimit të fazave për zgjedhjen e fazave nga cache

Rregulli i ri i gjenerimit të emrave të skenës. Tani çdo ndërtim i fazës gjeneron një emër unik skenik, i cili përbëhet nga 2 pjesë: një nënshkrim (siç ishte në v1.0) plus një identifikues unik të përkohshëm.

Për shembull, emri i imazhit të plotë të skenës mund të duket kështu:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...ose në përgjithësi:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

këtu:

SIGNATURE është një nënshkrim skenik, i cili përfaqëson identifikuesin e përmbajtjes skenike dhe varet nga historiku i modifikimeve në Git që çuan në këtë përmbajtje;
TIMESTAMP_MILLISEC është një identifikues unik i imazhit i garantuar që krijohet në kohën kur ndërtohet një imazh i ri.

Algoritmi për zgjedhjen e fazave nga cache bazohet në kontrollimin e marrëdhënies së kryerjes së Git:

Werf llogarit nënshkrimin e një faze të caktuar.
В faza-ruajtje Mund të ketë disa faza për një nënshkrim të caktuar. Werf zgjedh të gjitha fazat që përputhen me nënshkrimin.
Nëse faza aktuale është e lidhur me Git (git-archive, faza e personalizuar me arna Git: install, beforeSetup, setup; ose git-latest-patch), atëherë werf zgjedh vetëm ato faza që lidhen me një commit që është një paraardhës i commit-it aktual (për të cilin thirret ndërtimi).
Nga fazat e mbetura të përshtatshme, zgjidhet një - më e vjetra sipas datës së krijimit.

Një skenë për degë të ndryshme Git mund të ketë të njëjtin nënshkrim. Por werf do të parandalojë përdorimin e cache-it të lidhur me degë të ndryshme midis këtyre degëve, edhe nëse nënshkrimet përputhen.

→ Dokumentacioni.

Algoritëm i ri për krijimin dhe ruajtjen e fazave në ruajtjen e skenës

Nëse, gjatë zgjedhjes së fazave nga cache, werf nuk gjen një fazë të përshtatshme, atëherë fillon procesi i montimit të një faze të re.

Vini re se procese të shumta (në një ose më shumë host) mund të fillojnë të ndërtojnë të njëjtën fazë në afërsisht të njëjtën kohë. Werf përdor një algoritëm bllokues optimist faza-ruajtje në momentin e ruajtjes së imazhit të sapo mbledhur në faza-ruajtje. Në këtë mënyrë, kur ndërtimi i fazës së re të jetë gati, blloqet werf faza-ruajtje dhe ruan një imazh të sapo mbledhur atje vetëm nëse një imazh i përshtatshëm nuk ekziston më atje (sipas nënshkrimit dhe parametrave të tjerë - shihni algoritmin e ri për zgjedhjen e fazave nga cache).

Një imazh i sapomontuar garantohet të ketë një identifikues unik nga TIMESTAMP_MILLISEC (shiko formatin e ri të emërtimit të skenës). Në rast se në faza-ruajtje do të gjendet një imazh i përshtatshëm, werf do të heqë imazhin e sapo përpiluar dhe do të përdorë imazhin nga cache.

Me fjalë të tjera: procesi i parë për të përfunduar ndërtimin e imazhit (më i shpejti) do të marrë të drejtën për ta ruajtur atë në faza-ruajtje (dhe më pas është ky imazh i vetëm që do të përdoret për të gjitha ndërtimet). Një proces i ngadaltë ndërtimi nuk do të bllokojë kurrë një proces më të shpejtë nga ruajtja e rezultateve të ndërtimit të fazës aktuale dhe kalimi në ndërtimin tjetër.

→ Dokumentacioni.

Performanca e përmirësuar e ndërtuesit të Dockerfile

Për momentin, tubacioni i fazave për një imazh të ndërtuar nga një Dockerfile përbëhet nga një fazë - dockerfile. Gjatë llogaritjes së nënshkrimit, llogaritet shuma e kontrollit të skedarëve context, i cili do të përdoret gjatë montimit. Përpara këtij përmirësimi, werf kaloi në mënyrë rekursive nëpër të gjithë skedarët dhe mori një shumë kontrolli duke përmbledhur kontekstin dhe mënyrën e secilit skedar. Duke filluar me v1.1, werf mund të përdorë kontrolle të llogaritura të ruajtura në një depo Git.

Algoritmi bazohet në git ls-pema. Algoritmi merr parasysh të dhënat në .dockerignore dhe përshkon pemën e skedarit në mënyrë rekursive vetëm kur është e nevojshme. Kështu, ne kemi shkëputur nga leximi i sistemit të skedarëve dhe varësia e algoritmit nga madhësia context nuk është domethënëse.

Algoritmi gjithashtu kontrollon skedarët e pa gjurmuar dhe, nëse është e nevojshme, i merr ato parasysh në shumën e kontrollit.

Performanca e përmirësuar kur importoni skedarë

Versionet e werf v1.1 përdorin një server rsync kur importimi i skedarëve nga objektet dhe imazhet. Më parë, importimi bëhej në dy hapa duke përdorur një montim direktoriumi nga sistemi pritës.

Performanca e importit në macOS nuk kufizohet më nga vëllimet e Docker dhe importet përfundojnë në të njëjtën kohë si Linux dhe Windows.

Etiketimi i bazuar në përmbajtje

Werf v1.1 mbështet të ashtuquajturën etiketim sipas përmbajtjes së imazhit - etiketimi i bazuar në përmbajtje. Etiketat e imazheve të Docker-it që rezultojnë varen nga përmbajtja e atyre imazheve.

Gjatë ekzekutimit të komandës werf publish --tags-by-stages-signature ose werf ci-env --tagging-strategy=stages-signature publikuar imazhe të të ashtuquajturit nënshkrimi skenik imazh. Çdo imazh është etiketuar me nënshkrimin e vet të fazave të këtij imazhi, i cili llogaritet sipas të njëjtave rregulla si nënshkrimi i rregullt i çdo faze veç e veç, por është një identifikues i përgjithshëm i imazhit.

Nënshkrimi i fazave të imazhit varet nga:

përmbajtja e këtij imazhi;
historitë e ndryshimeve të Git që çuan në këtë përmbajtje.

Një depo Git ka gjithmonë detyrime të rreme që nuk ndryshojnë përmbajtjen e skedarëve të imazhit. Për shembull, angazhohet vetëm me komente ose bashkime, ose kryerje që ndryshojnë ato skedarë në Git që nuk do të importohen në imazh.

Kur përdorni etiketimin e bazuar në përmbajtje, problemet e rifillimit të panevojshëm të pod-eve të aplikacionit në Kubernetes për shkak të ndryshimeve në emrin e imazhit zgjidhen, edhe nëse përmbajtja e imazhit nuk ka ndryshuar. Nga rruga, kjo është një nga arsyet që pengon ruajtjen e shumë mikroshërbimeve të një aplikacioni në një depo të vetme Git.

Gjithashtu, etiketimi i bazuar në përmbajtje është një metodë më e besueshme etiketimi sesa etiketimi në degët e Git, sepse përmbajtja e imazheve që rezultojnë nuk varet nga rendi në të cilin ekzekutohen tubacionet në sistemin CI për montimin e shumëfishta të kryerjes së së njëjtës degë.

Është e rëndësishme: duke filluar nga tani faza-nënshkrimi - A e vetmja strategji e rekomanduar e etiketimit. Do të përdoret si parazgjedhje në komandë werf ci-env (nëse nuk specifikoni në mënyrë eksplicite një skemë tjetër etiketimi).

→ Dokumentacioni. Një botim i veçantë do t'i kushtohet gjithashtu kësaj veçorie. I PËRDITËSUAR (3 prill): Artikull me detaje botuar.

Nivelet e regjistrimit

Përdoruesi tani ka mundësinë të kontrollojë daljen, të vendosë nivelin e regjistrimit dhe të punojë me informacionin e korrigjimit. Opsionet u shtuan --log-quiet, --log-verbose, --log-debug.

Si parazgjedhje, dalja përmban informacionin minimal:

Kur përdorni daljen me fjalë (--log-verbose) mund të shihni se si funksionon werf:

Prodhimi i detajuar (--log-debug), përveç informacionit të korrigjimit të werf, përmban gjithashtu regjistrat e bibliotekave të përdorura. Për shembull, mund të shihni se si ndodh ndërveprimi me Regjistrin Docker, dhe gjithashtu të regjistroni vendet ku shpenzohet një sasi e konsiderueshme kohe:

Planet e mëtutjeshme

Kujdes! Opsionet e përshkruara më poshtë janë shënuar v1.1 do të bëhen të disponueshme në këtë version, shumë prej tyre në të ardhmen e afërt. Përditësimet do të vijnë nëpërmjet përditësimeve automatike kur përdorni multiwerf. Këto veçori nuk ndikojnë në pjesën e qëndrueshme të funksioneve v1.1; pamja e tyre nuk do të kërkojë ndërhyrje manuale të përdoruesit në konfigurimet ekzistuese.

Mbështetje e plotë për implementime të ndryshme të Regjistrit Docker (NEW)

Versioni: v1.1
Datat: Mars
Çështje

Qëllimi është që përdoruesi të përdorë një zbatim të personalizuar pa kufizime kur përdor werf.

Aktualisht, ne kemi identifikuar grupin e mëposhtëm të zgjidhjeve për të cilat do të garantojmë mbështetje të plotë:

Parazgjedhja (biblioteka/regjistri)*,
AWS ECR
Azure*,
Docker Hub
GCR*,
Paketat GitHub
Regjistri GitLab*,
Port*,
Kalaja.

Zgjidhjet që aktualisht mbështeten plotësisht nga werf shënohen me një yll. Për të tjerët ka mbështetje, por me kufizime.

Dy probleme kryesore mund të identifikohen:

Disa zgjidhje nuk mbështesin heqjen e etiketave duke përdorur Docker Registry API, duke i penguar përdoruesit të përdorin pastrimin automatik të werf. Kjo është e vërtetë për paketat AWS ECR, Docker Hub dhe GitHub.
Disa zgjidhje nuk mbështesin të ashtuquajturat depo të mbivendosur (Docker Hub, GitHub Packages dhe Quay), por përdoruesi duhet t'i krijojë ato manualisht duke përdorur UI ose API (AWS ECR).

Ne do t'i zgjidhim këto dhe probleme të tjera duke përdorur API-të vendase të zgjidhjeve. Kjo detyrë përfshin gjithashtu mbulimin e ciklit të plotë të funksionimit të werf-it me teste për secilën prej tyre.

Ndërtimi i imazhit të shpërndarë (↑)

Versioni: v1.2 v1.1 (përparësia për zbatimin e kësaj veçorie është rritur)
Datat: Mars-Prill Mars
Çështje

Për momentin, werf v1.0 dhe v1.1 mund të përdoren vetëm në një host të dedikuar për operacionet e ndërtimit dhe publikimit të imazheve dhe vendosjen e aplikacionit në Kubernetes.

Për të hapur mundësitë e punës së shpërndarë të werf-it, kur ndërtimi dhe vendosja e aplikacioneve në Kubernetes lançohen në disa hoste arbitrare dhe këta host nuk e ruajnë gjendjen e tyre midis ndërtimeve (vrapues të përkohshëm), werf kërkohet të zbatojë aftësinë për të përdorur Docker Registry si një dyqan skenash.

Më parë, kur projekti werf quhej ende dapp, ai kishte një mundësi të tillë. Megjithatë, ne kemi hasur në një sërë çështjesh që duhet të merren parasysh gjatë zbatimit të këtij funksioni në werf.

Shënim. Kjo veçori nuk kërkon që kolektori të punojë brenda pods Kubernetes, sepse Për ta bërë këtë, duhet të heqësh qafe varësinë nga serveri lokal Docker (në pod Kubernetes nuk ka qasje në serverin lokal Docker, sepse vetë procesi po funksionon në një kontejner, dhe werf nuk e mbështet dhe nuk do të mbështesë duke punuar me serverin Docker në rrjet). Mbështetja për ekzekutimin e Kubernetes do të zbatohet veçmas.

Mbështetje zyrtare për GitHub Actions (E RE)

Versioni: v1.1
Datat: Mars
Çështje

Përfshin dokumentacionin (seksionet referim и udhëzojë), si dhe Aksioni zyrtar GitHub për të punuar me werf.

Përveç kësaj, do të lejojë që werf të punojë në vrapues kalimtarë.

Mekanika e ndërveprimit të përdoruesit me sistemin CI do të bazohet në vendosjen e etiketave në kërkesat e tërheqjes për të iniciuar veprime të caktuara për të ndërtuar/hapur aplikacionin.

Zhvillimi lokal dhe vendosja e aplikacioneve me werf (↓)

Versioni: v1.1
Datat: Janar-Shkurt Prill
Çështje

Qëllimi kryesor është të arrihet një konfigurim i vetëm i unifikuar për vendosjen e aplikacioneve si në nivel lokal ashtu edhe në prodhim, pa veprime komplekse, jashtë kutisë.

Werf gjithashtu kërkohet të ketë një modalitet funksionimi në të cilin do të jetë i përshtatshëm për të redaktuar kodin e aplikacionit dhe për të marrë menjëherë reagime nga aplikacioni i ekzekutuar për korrigjimin e gabimeve.

Algoritmi i ri i pastrimit (I RI)

Versioni: v1.1
Datat: Prill
Çështje

Në versionin aktual të werf v1.1 në procedurë cleanup Nuk ka asnjë dispozitë për pastrimin e imazheve për skemën e etiketimit të bazuar në përmbajtje - këto imazhe do të grumbullohen.

Gjithashtu, versioni aktual i werf (v1.0 dhe v1.1) përdor politika të ndryshme pastrimi për imazhet e publikuara sipas skemave të etiketimit: dega Git, etiketa Git ose Git commit.

Është shpikur një algoritëm i ri për pastrimin e imazheve bazuar në historikun e kryerjeve në Git, i unifikuar për të gjitha skemat e etiketimit:

Mbani jo më shumë se imazhe N1 të lidhura me kryerjet më të fundit N2 për çdo git HEAD (degë dhe etiketa).
Ruani jo më shumë se imazhe të fazës N1 të lidhura me angazhimet më të fundit N2 për çdo Git HEAD (degë dhe etiketa).
Ruani të gjitha imazhet që përdoren në çdo burim grupi Kubernetes (të gjitha kontekstet kube të skedarit të konfigurimit dhe hapësirat e emrave janë skanuar; mund ta kufizoni këtë sjellje me opsione të veçanta).
Ruani të gjitha imazhet që përdoren në manifestet e konfigurimit të burimeve të ruajtura në versionet e Helm.
Një imazh mund të fshihet nëse nuk është i lidhur me asnjë HEAD nga git (për shembull, sepse vetë HEAD-i përkatës u fshi) dhe nuk përdoret në asnjë manifestim në grupin Kubernetes dhe në lëshimet e Helm.

Ndërtimi i imazhit paralel (↓)

Versioni: v1.1
Datat: Janar-Shkurt Prill*

Versioni aktual i werf mbledh imazhet dhe artefaktet e përshkruara në werf.yaml, në mënyrë sekuenciale. Është e nevojshme të paralelizohet procesi i montimit të fazave të pavarura të imazheve dhe objekteve, si dhe të sigurohet një rezultat i përshtatshëm dhe informues.

* Shënim: afati është zhvendosur për shkak të rritjes së prioritetit për zbatimin e montimit të shpërndarë, i cili do të shtojë më shumë aftësi të shkallëzimit horizontal, si dhe përdorimin e werf me GitHub Actions. Montimi paralel është hapi tjetër i optimizimit, duke siguruar shkallëzim vertikal kur montoni një projekt.

Kalimi në Helm 3 (↓)

Versioni: v1.2
Datat: shkurt-mars maj*

Përfshin migrimin në bazën e re të kodit Helm 3 dhe një mënyrë e provuar dhe e përshtatshme për të migruar instalimet ekzistuese.

* Shënim: kalimi në Helm 3 nuk do të shtojë veçori të rëndësishme në werf, sepse të gjitha tiparet kryesore të Helm 3 (bashkimi me 3 drejtime dhe pa mbajtës) janë zbatuar tashmë në werf. Për më tepër, werf ka veçori shtesë përveç atyre të treguara. Megjithatë, ky tranzicion mbetet në planet tona dhe do të zbatohet.

Jsonnet për përshkrimin e konfigurimit të Kubernetes (↓)

Versioni: v1.2
Datat: Janar-Shkurt Prill-Maj

Werf do të mbështesë përshkrimet e konfigurimit për Kubernetes në formatin Jsonnet. Në të njëjtën kohë, werf do të mbetet i pajtueshëm me Helm dhe do të ketë një zgjedhje të formatit të përshkrimit.

Arsyeja është se shabllonet Go, sipas shumë njerëzve, kanë një pengesë të lartë hyrëse, dhe kuptueshmëria e kodit të këtyre shablloneve gjithashtu vuan.

Gjithashtu po shqyrtohet mundësia e prezantimit të sistemeve të tjera të përshkrimit të konfigurimit Kubernetes (për shembull, Kustomize).

Duke punuar brenda Kubernetes (↓)

Versioni: v1.2
Datat: Prill-Maj-Qershor

Qëllimi: Sigurohuni që imazhet të jenë ndërtuar dhe aplikacioni të dorëzohet duke përdorur runners në Kubernetes. Ato. Imazhet e reja mund të ndërtohen, publikohen, pastrohen dhe vendosen direkt nga pods Kubernetes.

Për të zbatuar këtë aftësi, së pari duhet të jeni në gjendje të ndërtoni imazhe të shpërndara (shih pikën e mësipërme).

Ai gjithashtu kërkon mbështetje për mënyrën e funksionimit të ndërtuesit pa një server Docker (d.m.th. ndërtim ose ndërtim i ngjashëm me Kaniko në hapësirën e përdoruesit).

Werf do të mbështesë ndërtimin në Kubernetes jo vetëm me Dockerfile, por edhe me ndërtuesin e tij Stapel me rindërtime në rritje dhe Ansible.

Një hap drejt zhvillimit të hapur

Ne e duam komunitetin tonë (GitHub, Telegram) dhe ne duam që gjithnjë e më shumë njerëz të ndihmojnë për ta bërë werf më të mirë, të kuptojnë drejtimin në të cilin po lëvizim dhe të marrin pjesë në zhvillim.

Kohët e fundit u vendos që të kaloni në Bordet e projektit GitHub për të zbuluar procesin e punës së ekipit tonë. Tani mund të shihni planet e menjëhershme, si dhe punën aktuale në fushat e mëposhtme:

Është bërë shumë punë me çështjet:

U hoqën të parëndësishmet.
Ato ekzistuese janë sjellë në një format të vetëm, me një numër të mjaftueshëm detajesh dhe detajesh.
Janë shtuar çështje të reja me ide dhe sugjerime.

Si të aktivizoni versionin v1.1

Versioni është aktualisht i disponueshëm në kanali 1.1 ea (në kanale i qëndrueshëm и Gure te qendrueshem megjithatë, lëshimet do të shfaqen kur të ndodhë stabilizimi ea në vetvete është tashmë mjaft e qëndrueshme për përdorim, sepse kaloi nëpër kanale alfa и beta). Aktivizuar nëpërmjet multiwerf në mënyrën e mëposhtme:

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

Përfundim

Arkitektura e re e ruajtjes së skenës dhe optimizimet e ndërtuesve për ndërtuesit e Stapel dhe Dockerfile hapin mundësinë e zbatimit të ndërtimeve të shpërndara dhe paralele në werf. Këto veçori do të shfaqen së shpejti në të njëjtin version v1.1 dhe do të bëhen automatikisht të disponueshme përmes mekanizmit të përditësimit automatik (për përdoruesit multiwerf).

Në këtë version, është shtuar një strategji etiketimi bazuar në përmbajtjen e imazhit - etiketimi i bazuar në përmbajtje, e cila është bërë strategjia e paracaktuar. Regjistri kryesor i komandave është ripunuar gjithashtu: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Hapi tjetër i rëndësishëm është shtimi i asambleve të shpërndara. Ndërtimet e shpërndara janë bërë një prioritet më i lartë se ndërtimet paralele që nga v1.0 sepse i shtojnë më shumë vlerë werf: shkallëzimi vertikal i ndërtuesve dhe mbështetja për ndërtuesit kalimtar në sisteme të ndryshme CI/CD, si dhe aftësia për të bërë mbështetje zyrtare për GitHub Actions . Prandaj, afatet e zbatimit për asambletë paralele u zhvendosën. Megjithatë, ne po punojmë që të dy mundësitë t'i zbatojmë sa më shpejt që të jetë e mundur.

Ndiqni lajmet! Dhe mos harroni të na vizitoni në GitHubpër të krijuar një problem, për të gjetur një ekzistues dhe për të shtuar një plus, për të krijuar një PR ose thjesht për të parë zhvillimin e projektit.

PS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Verf 1.1 version: përmirësime për ndërtuesin sot dhe planet për të ardhmen