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

werf — mjeti ynë CLI GitOps me kod të hapur për ndërtimin dhe dërgimin e aplikacioneve në Kubernetes. Ashtu siç e premtuam, dalja e versionit v1.0 shënoi fillimin e shtimit të mundësive të reja në werf dhe rishikimin e qasjeve të zakonshme. Tani jemi të gëzuar të paraqesim lëshimin v1.1, i cili është një hap i madh në zhvillim dhe një frymëzim për të ardhmen ndërtuesit werf. Versioni është i disponueshëm tani në kanalin 1.1 ea.

Thelbi i lëshimit është arkitektura e re e magazinës për fazat dhe optimizimi i funksionimit të të dy ndërtuesve (për Stapel dhe Dockerfile). Arkitektura e re e magazinës hap mundësi për realizimin e ndërtimeve të shpërndara nga disa hostë dhe ndërtimeve paralele në një host.

Optimizimi i funksionimit përfshin heqjen e llogaritjeve të panevojshme në fazën e llogaritjes së nënshkrimeve të fazave dhe ndryshimin e mekanizmave të llogaritjes së kontrollit të shumave të skedarëve në më efikas. Kjo optimizim zvogëlon kohën mesatare të ndërtimeve të projektit duke përdorur werf. Edhe ndërtimet e zbrazta, kur të gjitha fazat ekzistojnë në cache stages-storage, tani janë vërtet të shpejta. Në shumicën e rasteve, rinisja e ndërtimit do të kalojë më shpejt se 1 sekondë! Kjo vlen gjithashtu për procedurat e verifikimit të fazave gjatë punës së ekipeve werf deploy dhe werf run.

Gjithashtu në këtë lëshim u shfaq strategjia e etiketimit të imazheve sipas përmbajtjes — content-based tagging, e cila tani është e aktivizuar si parazgjedhje dhe është e vetmja e rekomanduar.

Le të shqyrtojmë më në detaje novitetet kryesore në werf v1.1, ndërsa gjithashtu do të flasim për planet për të ardhmen.

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

Formati i ri i emërtimit të fazave dhe algoritmi i përzgjedhjes së fazave nga cache

Rregulli i ri i gjenerimit të emrit të fazës. Tani çdo ndërtim faze gjeneron një emër unik të fazës, i cili përbëhet nga 2 pjesë: nënshkrimi (si ishte në v1.0) plus një identifikues të kohës unik.

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

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

… ose në formë të përgjithshme:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Këtu:

SIGNATURE — është nënshkrimi i fazës, i cili paraqet identifikuesin e përmbajtjes së fazës dhe varet nga historia e ndryshimeve në Git, që solli këtë përmbajtje;
TIMESTAMP_MILLISEC — është një identifikues garantues unik i imazhit, i cili gjenerohet në momentin e ndërtimit të një imazhi të ri.

Algoritmi i përzgjedhjes së fazave nga cache bazohet në kontrollin e lidhshmërisë së Git-commit-ëve:

Werf llogarit nënshkrimin e një faze të caktuar.
Në stages-storage mund të ekzistojnë disa faza për këtë nënshkrim. Werf zgjedh të gjitha fazat që përputhen me nënshkrimin.
Nëse faza aktuale është e lidhur me Git (git-archive, një fazë e përdoruesit me Git-patch: instalo, paraSetup, setup; ose git-latest-patch), atëherë werf zgjedh vetëm ato faza që janë të lidhura me commit-in që është paraardhësi i commit-it aktual (për të cilin është thirrur ndërtimi).
Nga fazat e mbetura të përshtatshme, zgjedhet një — ajo më e vjetër në datën e krijimit.

Faza për degë të ndryshme Git mund të ketë të njëjtin nënshkrim. Por werf do të parandalojë përdorimin e caches të lidhura me degë të ndryshme midis këtyre degëve, edhe nëse nënshkrimet përputhen.

→ Dokumentacioni.

Algoritmi i ri për krijimin dhe ruajtjen e fazave në magazinën e fazave

Nëse gjatë përzgjedhjes së fazave nga cache, werf nuk gjen një fazë të përshtatshme, atëherë aktivizohet procesi i ndërtimit të një faze të re.

Vërejmë se disa procese (në një ose disa hoste) mund të fillojnë ndërtimin e të njëjtës fazë në mënyrë të përafërt në të njëjtën kohë. Werf përdor algoritmin e bllokimit optimist stages-storage në momentin e ruajtjes së imazhit të sapo ndërtuar në stages-storage. Kështu, kur ndërtimi i një faze të re është përfunduar, werf bllokon stages-storage dhe ruan aty vetëm imazhin e sapo ndërtuar në rast se atje nuk ekziston tashmë një imazh i përshtatshëm (sipër nënshkrimit dhe parametrave të tjerë — shihni algoritmin e ri të përzgjedhjes së fazave nga cache).

Imazhi i sapo ndërtuar do të ketë me siguri një identifikues unik sipas TIMESTAMP_MILLISEC (shihni formatin e ri të emërimit të fazave). Në rast se në stages-storage do të gjendet një imazh i përshtatshëm, werf do të hedhë poshtë imazhin e sapo ndërtuar dhe do të përdorë imazhin nga cache.

Me fjalë të tjera: procesi i parë që përfundon ndërtimin e imazhit (më i shpejti), do të ketë të drejtat e ruajtjes në stages-storage (dhe vetëm ky imazh do të përdoret për të gjitha ndërtimet). Procesi i ngadaltë i ndërtimit nuk do ta bllokojë kurrë procesin më të shpejtë nga ruajtja e rezultateve të ndërtimit të fazës aktuale dhe kalimi në ndërtimin e fazës tjetër.

→ Dokumentacioni.

Përformanca e ndërtuesit të Dockerfile është përmirësuar

Në këtë moment, konstrukti i fazave për imazhin e ndërtuar nga Dockerfile përbëhet nga një fazë — dockerfile. Në llogaritjen e nënshkrimit llogaritet suma e kontrollet e skedarëve context, që do të përdoren gjatë ndërtimit. Para këtij përmirësimi, werf kalonte rekurzivisht nëpër të gjithë skedarët dhe merrte shumën e kontrollit duke përmbledhur kontekstin dhe modin e çdo skedari. Duke filluar nga versionet v1.1, werf mund të përdorë shumën e kontrollet e llogaritur, të ruajtur në depo Git.

Në thelb të algoritmit është git ls-tree. Algoritmi merr parasysh të dhënat në .dockerignore dhe kalon rekurzivisht nëpër pemën e skedarëve vetëm kur është e nevojshme. Kështu, ne u çlirua nga leximi i sistemit të skedarëve, dhe varësia e algoritmit nga madhësia context nuk është e rëndësishme.

Po ashtu, algoritmi kontrollon skedarët e pa ndjekur dhe, kur është e nevojshme, i përfshin ata në shumën e kontrollit.

Përmirësuar performanca gjatë importimit të skedarëve

Në versionet werf v1.1 përdoret një server rsync gjatë importit të skedarëve nga artefaktet dhe imazhet. Më parë, importimi kryhej në dy hapa duke përdorur montimin e drejtorisë nga sistemi host.

Performanca e importeve në macOS nuk është më e kufizuar nga volumi Docker, dhe importet kryhen për të njëjtën kohë si në Linux dhe Windows.

Etiketa e bazuar në përmbajtje

Werf v1.1 mbështet atë që quhet etiketa e bazuar në përmbajtjen e imazhit — content-based tagging. Etiketat e imazheve përfundimtare Docker varen nga përmbajtja e këtyre imazheve.

Gjatë ekzekutimit të komandës werf publish --tags-by-stages-signature или werf ci-env --tagging-strategy=stages-signature do të etiketohen imazhet e publikuara me atë që quhet nënshkrimi i fazave të imazhit. Çdo imazh etiketizohet me nënshkrimin e vet të fazave të këtij imazhi, i cili llogaritet sipas të njëjtave rregulla si nënshkrimi normal i secilës fazë veçmas, por është një identifikues agregues i imazhit.

Nënshkrimi i fazave të imazhit varet nga:

përmbajtja e këtij imazhi;
historia e modifikimeve në Git, që çuan në këtë përmbajtje.

Në depo Git gjithmonë ka komitete të kota, që nuk ndryshojnë përmbajtjen e skedarëve të imazhit. Për shembull, komitete që kanë vetëm komente ose komitete bashkimit, ose komitete që ndryshojnë ato skedarë në Git, që nuk do të importohen në imazh.

Duke përdorimi i tagging-ut të bazuar në përmbajtje zgjidh problemet e rindezjes së panevojshme të pod’ëve të aplikacionit në Kubernetes për shkak të ndryshimeve në emrin e imazhit, edhe nëse përmbajtja e imazhit nuk ka ndryshuar. Për më tepër, kjo është një nga arsyet që pengojnë ruajtjen e shumë mikrosherbimeve të një aplikacioni në një Git-repozitor të vetëm.

Gjithashtu, tagging-u i bazuar në përmbajtje është një metodë më e besueshme për tagging sesa tagging-u sipas degëve të Git, sepse përmbajtja e imazheve përfundimtare nuk varet nga rendi i ekzekutimit të pipeline’ave në sistemin CI për ndërtimin e disa komiteteve të të njëjtës degë.

Ëhtë e rëndësishme: duke filluar nga ky moment stages-signature — është strategjia e vetme e rekomanduar për tagging. Ajo do të përdoret si parazgjedhje në komandën werf ci-env (nëse nuk especificohet një skemë tjetër tagimi).

→ Dokumentacioni. Kësaj veçorie do t'i dedikohet gjithashtu një publikim të veçantë. PËRPUNUAR (3 Prill): Artikulli me detaje u publikua.

Nivelet e regjistrimit

Këtu, përdoruesi ka mundësinë të kontrollojë daljen, të caktuar nivelin e regjistrimit dhe të punojë me informacionin e debug-imit. Janë shtuar opsionet --log-quiet, --log-verbose, --log-debug.

Për parazgjedhje, në dalje përmban minimum informacioni:

Duke përdorur daljen e detajuar (--log-verbose) mund të ndjekësh se si punon werf:

Dalja e detajuar (--log-debug), përveç informacionit të debug-imit nga werf, gjithashtu përmban log-et e bibliotekave të përdorura. Për shembull, mund të shihni se si ndodh ndërveprimi me Docker Registry, si dhe të regjistroni vendet ku humb shumë kohë:

Planet e ardhshme

Kujdes! Funksionalitetet e përshkruara më poshtë me shenimin v1.1 do të bëhen të aksesueshme që në këtë version, shumë nga to — në një të ardhme të afërt. Përditësimet do të vijnë përmes autoazhgjerimeve në përdorimin e multiwerf. Këto funksionalitete nuk prekin pjesën e stabilizuar të funksioneve v1.1, shfaqja e tyre nuk do të kërkojë ndërhyrje manuale nga përdoruesi në konfigurimet ekzistuese.

Përkrahje e plotë për realizime të ndryshme të Docker Registry (E RE)

Versioni: v1.1
Afatet: mars
Çështja

Qëllimi është që përdoruesi të përdorë realizimin e tij të preferuar pa kufizime kur përdor werf.

Në këtë moment, ne kemi identifikuar grupin e mëposhtëm të zgjidhjeve për të cilat planifikojmë të ofrojmë mbështetje të plotë:

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

Me yllë kanë shënuar zgjidhjet që aktualisht mbështeten plotësisht nga werf. Për të tjerat ka mbështetje, por me kufizime.

Mund të veçojmë dy probleme kryesore:

Disa zgjidhje nuk mbështesin fshirjen eetiketave me anë të Docker Registry API, gjë që nuk u lejon përdoruesve të përdorin pastrimin automatik të implementuar në werf. Ky fakt është valid për AWS ECR, Docker Hub dhe GitHub Packages.
Një pjesë e zgjidhjeve nuk mbështesin, ashtuquajturat, nested repositories (Docker Hub, GitHub Packages dhe Quay) ose mbështesin, por përdoruesi duhet t'i krijojë ato manualisht duke përdorur UI ose API (AWS ECR).

Ne synojmë të zgjidhim këto e probleme të tjera duke përdorur API-të native të zgjidhjeve. Ky projekt përfshin gjithashtu mbulimin me teste të ciklit të plotë të funksionimit të werf për secilën prej tyre.

Ndërtime të shpërndara të imazheve (↑)

Versioni: v1.2 v1.1 (prioriteti për implementimin e kësaj mundësie është rritur)
Afatet: mars-prill mars
Çështja

Aktualisht, werf v1.0 dhe v1.1 mund të përdoren vetëm në një host të dedikuar për operacionet e ndërtimit, botimit të imazheve dhe vendosjes së aplikacionit në Kubernetes.

Për të hapur mundësitë e punës shpërndare të werf, kur ndërtimi dhe vendosja e aplikacioneve në Kubernetes fillojnë në disa host-e të rastësishme dhe këta host-e nuk ruajnë gjendjen e tyre midis ndërtimeve (runner të përkohshëm), werf kërkon zbatimin e mundësisë për të përdorur Docker Registry si depo të stadeve.

Më parë, kur projekti werf quhej dapp, ekzistonte një mundësi e tillë. Sidoqoftë, ne përballëm disa probleme që duhet të merret parasysh gjatë implementimit të kësaj funksionaliteti në werf.

Shënim. Kjo mundësi nuk parashikon punë të ndërtuesit brenda pod-eve të Kubernetes, sepse për këtë duhet të hiqet varësia nga serveri lokal Docker (në pod-in e Kubernetes nuk ka akses në serverin lokal Docker, sepse vetë procesi është i lansuar në një kontenier, dhe werf nuk mbështet dhe nuk do të mbështesë punën me serverin Docker në rrjet). Mbështetje për punën në Kubernetes do të realizohet ndaras.

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

Versioni: v1.1
Afatet: mars
Çështja

Përfshin dokumentacionin e werf (seksionet referencë dhe udhëzues), si dhe një veprim të zyrtarizuar të GitHub për të punuar me werf.

Për më tepër, kjo do të lejojë që werf të punojë në runner të efemer.

Mekanika e ndërveprimit të përdoruesit me sistemin CI do të bazohet në vendosjen e etiketimeve mbi kërkesat për bashkim për të nismuar veprime të caktuara për ndërtimin/dërgimin e aplikacionit.

Zhvillimi lokal dhe disfatimi i aplikacioneve me werf (↓)

Versioni: v1.1
Afatet: janar-shkurt prill
Çështja

Qëllimi kryesor është të arrihet një konfigurim i unifikuar për disfatimin e aplikacioneve si lokal, ashtu edhe në prodhim, pa veprime të komplikuara, "nga kutia".

Nga werf kërkohet gjithashtu një mod operativ ku do të jetë e rehatshme të redaktohet kodi i aplikacionit dhe të marrim menjëherë reagim nga aplikacioni funksional për debug.

Algoritmi i ri i pastrimit (E RE)

Versioni: v1.1
Afatet: prill
Çështja

Në versionin aktual të werf v1.1 në procedurën cleanup nuk është parashikuar pastrimi i imazheve për skemën e etiketimit bazuar në përmbajtje (content-based tagging) — këto imazhe do të grumbullohen.

Gjithashtu, në versionin aktual të werf (v1.0 dhe v1.1) përdoren politika të ndryshme pastrimi për imazhet e publikuara sipas skemave të etiketimit: degë Git, etiketë Git ose angazhim Git.

Është menduar një algoritëm i ri unifikues për të gjitha skemat e etiketimit për pastrimin e imazheve duke u bazuar në historinë e angazhimeve në Git:

Të ruhet jo më shumë se N1 imazhe të lidhura me N2 angazhimet e fundit për secilën nga git HEAD (degat dhe etiketat).
Të ruhet jo më shumë se N1 imazhe-stage, të lidhura me N2 angazhimet e fundit për secilën nga git HEAD (degat dhe etiketat).
Të ruhet gjithë imazhet që përdoren në burimet e klasterit Kubernetes (shkanohet të gjithë kube-kontekste të skedës së konfigurimit dhe hapësirat emërore; mund të kufizohet kjo sjellje me opsione të veçanta).
Të ruhet gjithë imazhet që përdoren në manifestet e konfigurimit të burimeve, të ruajtura në lëshimet Helm.
Një imazh mund të fshihet nëse nuk është i lidhur me asnjë HEAD nga git (p.sh., sepse ai lidhës përkatës është fshirë) dhe nuk përdoret në asnjë nga manifestet në klasterin Kubernetes dhe në lëshimet Helm.

Ndërtimi paralel i imazheve (↓)

Versioni: v1.1
Afatet: janar-shkurt prill*

Versioni aktual i werf ndërtan imazhet dhe artefaktet e përshkruara në werf.yamlkështu, gradualisht. Është e nevojshme të paralelizohet procesi i ndërtimit të indivitëve të pavarur të imazheve dhe artefakteve, si dhe të sigurohet një output i përshtatshëm dhe informativ.

* Shënim: afati është shtyrë për shkak të rritjes së prioritetit për zbatimin e ndarjes së shpërndarë, e cila do të shtojë më shumë mundësi për shkallëzimin horizontal dhe përdorimin e werf me GitHub Actions. Ndërsa ndarja paralele është hapi tjetër i optimizimit, duke ofruar shkallëzim vertikal gjatë ndarjes së një projekti.

Kalimi në Helm 3 (↓)

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

Përfshin kalimin në bazën e re të kodit Helm 3 dhe një mënyrë të provuar dhe të lehtë për migrimin e instalimeve ekzistuese.

* Shënim: kalimi në Helm 3 nuk do të sjellë mundësi të rëndësishme në werf, sepse të gjitha funksionalitetet kryesore të Helm 3 (3-way-merge dhe mungesa e tiller) janë tashmë të zbatuara në werf. Për më tepër, werf ka mundësi të tjera përveç atyre të përmendura. Sidoqoftë, ky kalim mbetet në planet tona dhe do të realizohet.

Jsonnet për përshkrimin e konfiguracionit Kubernetes (↓)

Versioni: v1.2
Afatet: janar-shkurt prill-maj

Werf do të mbështesë përshkrimin e konfiguracionit për Kubernetes në formatin Jsonnet. Në të njëjtën kohë, werf do të mbetet në përputhje me Helm dhe do të ketë mundësinë e zgjedhjes së formatit të përshkrimit.

Shkaku është se shabllonet e gjuhës Go, sipas vlerësimit të shumë njerëzve, kanë një prag të lartë hyrjeje, dhe kuptueshmëria e kodit të këtyre shablloneve gjithashtu vuante.

Po ashtu, po shqyrtohet mundësia e implementimit të sistemeve të tjera përshkruese të konfiguracionit Kubernetes (për shembull, Kustomize).

Puna brenda Kubernetes (↓)

Versioni: v1.2
Afatet: prill-maj maj-qershor

Qëllimi: të sigurohet ndarja e imazheve dhe dorëzimi i aplikacionit duke përdorur runner në Kubernetes. Domethënë, ndarja e imazheve të reja, publikimi i tyre, pastrimi dhe deploy mund të ndodhin direkt nga pod Kubernetes.

Për të realizuar këtë mundësi, fillimisht kërkohet mundësia e ndarjes së shpërndarë të imazheve (shih pikën më lart).

Po ashtu kërkohet mbështetje për modin e punës së ndarësit pa serverin Docker (dmth, ndarje e ngjashme me Kaniko ose ndarje në userspace).

Werf do të mbështesë ndarjen në Kubernetes jo vetëm me Dockerfile, por gjithashtu me ndarësin e tij Stapel me ripërpunime inkrementale dhe Ansible.

Hapi drejt zhvillimit të hapur

Ne e duam komunitetin tonë (GitHub, Telegram) dhe duam që gjithnjë e më shumë njerëz të ndihmojnë në përmirësimin e werf, të kuptojnë drejtimin në të cilin po lëvizim dhe të kontribuojnë në zhvillim.

Kohët e fundit u vendos që të kalojmë në tabulat e projekteve të GitHub për të hapur pak nga procesi i punës së ekipit tonë. Tani mund të shihni planet e afërta, si dhe punët aktuale në drejtimet e mëposhtme:

K është bërë një punë e madhe me issues:

Janë fshirë ato që nuk janë më të rëndësishme.
Ato ekzistuese janë zvogëluar në një format të unifikuar, me numër të mjaftueshëm detajesh dhe hollësish.
Janë shtuar issues të reja me ide dhe propozime.

Si të aktivizoni versionin v1.1

Versioni është i disponueshëm tani në kanalin 1.1 ea (në kanalet stabil dhe shkëmbim të fortë lëshimet do të shfaqen me kalimin e kohës, megjithatë ea veta është e mjaftueshme e stabilizuar për përdorim, sepse ka kaluar përmes kanaleve alpha dhe beta). Aktivizohet nëpërmjet multiwerf në këtë mënyrë:

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

Përfundim

Arkitektura e re e ruajtjes së fazave dhe optimizimi i funksionimit të ndërtuesit për ndërtuesit Stapel dhe Dockerfile ofron mundësi për të realizuar ndërtime të shpërndara dhe paralel në werf. këto mundësi do të kenë shumë shpejt në të njëjtin lëshim v1.1 dhe do të bëhen automatikisht të disponueshme përmes mekanizmit të azhurnimeve automatik. multiwerf).

Në këtë lëshim u shtua strategjia e etiketimit të përmbajtjes së imazheve — content-based tagging, — e cila u bë strategjia e paracaktuar. Gjithashtu u rishikua logu i komandave kryesore: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Hapi i ardhshëm i rëndësishëm do të jetë shtimi i ndërtimeve të shpërndara. Ndërtimet e shpërndara, nga versioni v1.0, janë bërë një prioritet më i lartë se ndërtimet paralel, sepse shtojnë më shumë vlerë për werf: shkallëzimi vertikal i ndërtuesve dhe mbështetje për ndërtuesit efemerë në sistemet e ndryshme CI/CD, si dhe mundësia për të bërë mbështetje zyrtare për GitHub Actions. Prandaj, afatet për realizimin e ndërtimeve paralel janë shtyrë. Megjithatë, ne po punojmë për t'i realizuar të dyja mundësitë sa më shpejt të jetë e mundur.

Mbani sytë hapur! Dhe mos harroni të shihni tek ne në GitHub, për të krijuar issue, për të gjetur një të ekzistueshëm dhe për të dhënë një plus, për të krijuar një PR ose thjesht për të ndjekur zhvillimin e projektit.