yra mūsų atvirojo kodo „GitOps CLI“ programa, skirta kurti ir teikti programas „Kubernetes“. Kaip žadėta, pažymėjo naujų werf funkcijų įtraukimo ir tradicinių metodų peržiūros pradžią. Dabar džiaugiamės galėdami pristatyti 1.1 versiją, kuri yra didelis žingsnis plėtojant ir pagrindas ateičiai kolekcininkas werf. Versija šiuo metu pasiekiama .
Išleidimo pagrindas – nauja scenos saugyklos architektūra ir abiejų kolektorių darbo optimizavimas (Stapel ir Dockerfile). Naujoji saugyklos architektūra atveria galimybę tame pačiame pagrindiniame kompiuteryje įdiegti paskirstytus rinkinius iš kelių pagrindinių kompiuterių ir lygiagrečius mazgus.
Darbo optimizavimas apima nereikalingų skaičiavimų pašalinimą etapo parašų skaičiavimo etape ir failų kontrolinių sumų skaičiavimo mechanizmų pakeitimą, kad jie būtų efektyvesni. Šis optimizavimas sumažina vidutinį projekto kūrimo laiką naudojant werf. Ir tuščiosios eigos versijos, kai talpykloje yra visi etapai etapai-saugojimas, dabar tikrai greiti. Daugeliu atvejų kūrimo paleidimas iš naujo užtruks mažiau nei 1 sekundę! Tai taip pat taikoma komandų darbo proceso etapų tikrinimo procedūroms. werf deploy и werf run.
Taip pat šiame leidime pasirodė vaizdų žymėjimo pagal turinį strategija - turiniu pagrįstas žymėjimas, kuri dabar įjungta pagal numatytuosius nustatymus ir vienintelė rekomenduojama.
Pažvelkime atidžiau į pagrindines werf v1.1 naujoves ir tuo pačiu papasakokime apie ateities planus.
Kas pasikeitė werf v1.1?
Naujas etapų pavadinimų formatas ir algoritmas etapams iš talpyklos parinkti
Nauja sceninio vardo generavimo taisyklė. Dabar kiekviena pakopos versija sukuria unikalų scenos pavadinimą, kurį sudaro 2 dalys: parašas (kaip buvo 1.0 versijoje) ir unikalus laikinas identifikatorius.
Pavyzdžiui, visas sceninio vaizdo pavadinimas gali atrodyti taip:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...arba apskritai:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Здесь:
-
SIGNATUREyra sceninis parašas, atspindintis sceninio turinio identifikatorių ir priklausantis nuo redagavimo „Git“, dėl kurio atsirado šis turinys, istorijos; -
TIMESTAMP_MILLISECyra garantuotas unikalus vaizdo identifikatorius, kuris sugeneruojamas kuriant naują vaizdą.
Etapų pasirinkimo iš talpyklos algoritmas pagrįstas „Git“ įsipareigojimų ryšio patikrinimu:
- Werfas apskaičiuoja tam tikro etapo parašą.
- В etapai-saugojimas Tam tikro parašo gali būti keli etapai. Werf pasirenka visus etapus, kurie atitinka parašą.
- Jei dabartinė stadija susieta su Git (git-archyvas, tinkintas etapas su Git pataisomis:
install,beforeSetup,setup; arba git-latest-patch), tada werf pasirenka tik tuos etapus, kurie yra susieti su įvykdymu, kuris yra dabartinio įsipareigojimo (kuriam vadinamas kūrimas) protėvis. - Iš likusių tinkamų etapų atrenkamas vienas – seniausias pagal sukūrimo datą.
Skirtingų Git filialų etapas gali turėti tą patį parašą. Tačiau werf neleis su skirtingomis šakomis susietos talpyklos naudoti tarp šių šakų, net jei parašai sutampa.
.
Naujas etapų kūrimo ir išsaugojimo etapų saugykloje algoritmas
Jei pasirinkdamas etapus iš talpyklos werf neranda tinkamo etapo, pradedamas naujos pakopos surinkimo procesas.
Atminkite, kad keli procesai (viename ar keliuose pagrindiniuose kompiuteriuose) gali pradėti kurti tą patį etapą maždaug tuo pačiu metu. Werf naudoja optimistinį blokavimo algoritmą etapai-saugojimas ką tik surinkto vaizdo įrašymo momentu etapai-saugojimas. Tokiu būdu, kai bus paruoštas naujas etapas, werf blokai etapai-saugojimas ir išsaugo ten ką tik surinktą vaizdą tik tuo atveju, jei tinkamo vaizdo ten nebėra (pagal parašą ir kitus parametrus – žr. naują etapų pasirinkimo iš talpyklos algoritmą).
Garantuojama, kad naujai surinktas vaizdas turės unikalų identifikatorių TIMESTAMP_MILLISEC (žr. naują etapo pavadinimo formatą). Tuo atveju, kai etapai-saugojimas bus rastas tinkamas vaizdas, werf atmes ką tik sukurtą vaizdą ir naudos atvaizdą iš talpyklos.
Kitaip tariant: pirmasis atvaizdo kūrimo procesas (greičiausias) įgis teisę jį saugoti etapais (ir tada šis vienas vaizdas bus naudojamas visoms kūrimo priemonėms). Lėtas kūrimo procesas niekada netrukdys greitesniam procesui išsaugoti dabartinio etapo kūrimo rezultatus ir pereiti prie kitos versijos.
.
Patobulintas „Dockerfile“ kūrimo priemonės našumas
Šiuo metu iš Dockerfile sukurto vaizdo etapų rinkinį sudaro vienas etapas - dockerfile. Skaičiuojant parašą, apskaičiuojama failų kontrolinė suma context, kuris bus naudojamas surinkimo metu. Prieš šį patobulinimą werf rekursyviai peržiūrėjo visus failus ir, susumavus kiekvieno failo kontekstą ir režimą, gavo kontrolinę sumą. Pradedant nuo 1.1 versijos, werf gali naudoti apskaičiuotas kontrolines sumas, saugomas Git saugykloje.
Algoritmas pagrįstas . Algoritmas atsižvelgia į įrašus .dockerignore ir rekursyviai perkelia failų medį tik tada, kai reikia. Taigi mes atsiejome nuo failų sistemos skaitymo ir algoritmo priklausomybės nuo dydžio context nėra reikšmingas.
Algoritmas taip pat patikrina nesekamus failus ir, jei reikia, atsižvelgia į juos kontrolinėje sumoje.
Patobulintas našumas importuojant failus
werf v1.1 versijose naudojamas rsync serveris, kai . Anksčiau importavimas buvo atliktas dviem etapais, naudojant katalogo prijungimą iš pagrindinės sistemos.
„MacOS“ importavimo našumo neberiboja „Docker“ apimtis, o importavimas baigiamas per tiek pat laiko, kiek „Linux“ ir „Windows“.
Turiniu pagrįstas žymėjimas
Werf v1.1 palaiko vadinamąjį žymėjimą pagal vaizdo turinį – turiniu pagrįstas žymėjimas. Gautų „Docker“ vaizdų žymos priklauso nuo tų vaizdų turinio.
Vykdant komandą werf publish --tags-by-stages-signature arba werf ci-env --tagging-strategy=stages-signature publikuoti vaizdai iš vadinamųjų sceninis parašas vaizdas. Kiekvienas vaizdas yra pažymėtas savo šio vaizdo etapų parašu, kuris apskaičiuojamas pagal tas pačias taisykles, kaip ir įprastas kiekvieno etapo parašas atskirai, tačiau yra bendras vaizdo identifikatorius.
Vaizdo etapų parašas priklauso nuo:
- šio vaizdo turinys;
- Git pakeitimų, dėl kurių atsirado šis turinys, istorijas.
Git saugykloje visada yra netikrų įsipareigojimų, kurie nekeičia vaizdo failų turinio. Pvz., Įsipareigoja tik komentaruose arba sujungia įsipareigojimus arba įsipareigojimus, kurie pakeičia tuos Git failus, kurie nebus importuoti į vaizdą.
Naudojant turiniu pagrįstą žymėjimą, išsprendžiamos „Kubernetes“ programų blokų nereikalingo paleidimo iš naujo dėl vaizdo pavadinimo pakeitimų problemos, net jei vaizdo turinys nepasikeitė. Beje, tai yra viena iš priežasčių, neleidžiančių vienoje Git saugykloje saugoti daug vienos programos mikro paslaugų.
Taip pat turiniu pagrįstas žymėjimas yra patikimesnis žymėjimo būdas nei žymėjimas Git šakose, nes gaunamų vaizdų turinys nepriklauso nuo to, kokia tvarka CI sistemoje vykdomi konvejeriai, skirti surinkti kelis tos pačios šakos commitus.
Svarbu,: pradedant nuo dabartinio momento etapai-parašas - yra vienintelė rekomenduojama žymėjimo strategija. Pagal numatytuosius nustatymus jis bus naudojamas komandoje werf ci-env (nebent aiškiai nurodysite kitą žymėjimo schemą).
. Šiai funkcijai taip pat bus skirtas atskiras leidinys. ATNAUJINTA (balandžio 3 d.): Straipsnis su išsamia informacija .
Registravimo lygiai
Dabar vartotojas turi galimybę valdyti išvestį, nustatyti registravimo lygį ir dirbti su derinimo informacija. Pridėtos parinktys --log-quiet, --log-verbose, --log-debug.
Pagal numatytuosius nustatymus išvestyje yra minimali informacija:
Kai naudojate išsamią išvestį (--log-verbose) galite pamatyti, kaip veikia werf:
Išsami produkcija (--log-debug), be werf derinimo informacijos, taip pat yra naudotų bibliotekų žurnalai. Pavyzdžiui, galite pamatyti, kaip vyksta sąveika su „Docker“ registru, taip pat įrašyti vietas, kuriose praleidžiama daug laiko:
Tolesni planai
Dėmesio! Toliau aprašytos parinktys yra pažymėtos v1.1 bus pasiekiama šioje versijoje, daugelis jų – artimiausiu metu. Atnaujinimai bus siunčiami automatiškai . Šios funkcijos neturi įtakos stabiliai v1.1 funkcijų daliai; jų išvaizdai nereikės rankinio vartotojo įsikišimo į esamas konfigūracijas.
Visiškas įvairių „Docker“ registro diegimų palaikymas (NAUJIENA)
- Versija: v1.1
- Datos: kovo mėn
Tikslas yra, kad vartotojas naudotų tinkintą diegimą be apribojimų naudodamas werf.
Šiuo metu mes nustatėme šiuos sprendimus, kuriems garantuojame visapusišką palaikymą:
- Numatytoji (biblioteka/registras)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub paketai
- „GitLab“ registras*,
- Uostas*,
- Krantinė.
Sprendimai, kuriuos šiuo metu visiškai palaiko werf, pažymėti žvaigždute. Kitiems yra parama, bet su apribojimais.
Galima išskirti dvi pagrindines problemas:
- Kai kurie sprendimai nepalaiko žymų pašalinimo naudojant „Docker“ registro API, todėl vartotojai negali naudoti automatinio „werf“ valymo. Tai pasakytina apie AWS ECR, „Docker Hub“ ir „GitHub“ paketus.
- Kai kurie sprendimai nepalaiko vadinamųjų įdėtųjų saugyklų („Docker Hub“, „GitHub Packages“ ir „Quay“) arba palaiko, tačiau vartotojas turi jas sukurti rankiniu būdu naudodamas vartotojo sąsają arba API (AWS ECR).
Šias ir kitas problemas išspręsime naudodami savąsias sprendimų API. Ši užduotis taip pat apima visą werf veikimo ciklą su kiekvieno iš jų testais.
Paskirstytas vaizdo kūrimas (↑)
- Versija: v1.2 v1.1 (šios funkcijos diegimo prioritetas padidintas)
- Datos: kovo – balandžio mėn
Šiuo metu werf v1.0 ir v1.1 galima naudoti tik viename tam skirtame pagrindiniame kompiuteryje vaizdų kūrimo ir publikavimo bei programos diegimo Kubernetes operacijoms.
Norint atverti paskirstyto werf darbo galimybes, kai Kubernetes taikomųjų programų kūrimas ir diegimas paleidžiami keliuose savavališkuose pagrindiniuose kompiuteriuose ir šie kompiuteriai neišsaugo savo būsenos tarp statymų (laikinų bėgikų), werf reikia įdiegti galimybę naudoti Docker Registry kaip scenos parduotuvė.
Anksčiau, kai werf projektas dar vadinosi dapp, jis turėjo tokią galimybę. Tačiau susidūrėme su daugybe problemų, į kurias reikia atsižvelgti diegiant šią funkciją werf.
Atkreipti dėmesį. Ši funkcija nereikalauja, kad kolektorius veiktų Kubernetes ankštyse, nes Norėdami tai padaryti, turite atsikratyti priklausomybės nuo vietinio „Docker“ serverio („Kubernetes pod“ nėra prieigos prie vietinio „Docker“ serverio, nes pats procesas vyksta konteineryje, o werf nepalaiko ir nepalaikys darbas su Docker serveriu tinkle). Palaikymas Kubernetes paleidimui bus įgyvendintas atskirai.
Oficialus „GitHub Actions“ palaikymas (NAUJA)
- Versija: v1.1
- Datos: kovo mėn
Apima werf dokumentaciją (skyrius nuoroda и vadovas), taip pat oficialus GitHub veiksmas, skirtas darbui su werf.
Be to, tai leis werf dirbti su trumpalaikiais bėgikais.
Vartotojo sąveikos su CI sistema mechanika bus pagrįsta etikečių uždėjimu ant ištraukimo užklausų, kad būtų pradėti tam tikri veiksmai kuriant / išleidžiant programą.
Vietinis programų kūrimas ir diegimas naudojant werf (↓)
- Versija: v1.1
- Datos: sausio-vasario mėn., balandžio mėn
Pagrindinis tikslas yra pasiekti vieną vieningą konfigūraciją, kad būtų galima įdiegti programas tiek vietoje, tiek gamyboje, be sudėtingų veiksmų.
werf taip pat reikalingas darbo režimas, kuriame bus patogu redaguoti programos kodą ir akimirksniu gauti grįžtamąjį ryšį iš veikiančios programos derinimui.
Naujas valymo algoritmas (NAUJAS)
- Versija: v1.1
- Datos: balandžio mėn
Dabartinės versijos werf v1.1 procedūroje cleanup Turiniu pagrįstos žymėjimo schemos vaizdų valymas nenumatytas – šie vaizdai kaupsis.
Be to, dabartinė werf versija (v1.0 ir v1.1) naudoja skirtingą valymo politiką vaizdams, paskelbtiems pagal žymėjimo schemas: Git filialas, Git žyma arba Git commit.
Buvo išrastas naujas vaizdų valymo algoritmas, pagrįstas „Git“ įsipareigojimų istorija, suvienodintas visoms žymėjimo schemoms:
- Išsaugokite ne daugiau nei N1 vaizdų, susietų su naujausiais N2 įsipareigojimais kiekvienam git HEAD (šakioms ir žymoms).
- Išsaugokite ne daugiau kaip N1 etapo vaizdų, susietų su N2 naujausiais įsipareigojimais kiekvienam git HEAD (šakoms ir žymoms).
- Išsaugokite visus vaizdus, kurie naudojami bet kuriuose Kubernetes klasterio ištekliuose (nuskaitomi visi konfigūracijos failo kube kontekstai ir vardų erdvės; galite apriboti šį elgesį naudodami specialias parinktis).
- Išsaugokite visus vaizdus, kurie naudojami išteklių konfigūracijos aprašuose, išsaugotuose Helm leidimuose.
- Vaizdas gali būti ištrintas, jei jis nesusietas su jokia HEAD iš git (pavyzdžiui, nes pati atitinkama HEAD buvo ištrinta) ir nenaudojamas jokiuose aprašuose Kubernetes klasteryje ir Helm leidimuose.
Lygiagretus vaizdo kūrimas (↓)
- Versija: v1.1
- Datos: sausio-vasario mėn., balandžio mėn.*
Dabartinė werf versija renka vaizdus ir artefaktus, aprašytus werf.yaml, iš eilės. Būtina sulyginti nepriklausomų vaizdų ir artefaktų etapų surinkimo procesą, taip pat pateikti patogią ir informatyvią išvestį.
* Pastaba: terminas buvo perkeltas dėl didesnio prioriteto diegti paskirstytą surinkimą, kuris suteiks daugiau horizontalaus mastelio keitimo galimybių, taip pat dėl werf naudojimo su GitHub Actions. Lygiagretus surinkimas yra kitas optimizavimo žingsnis, užtikrinantis vertikalų mastelį surenkant vieną projektą.
Perėjimas prie 3 vairo (↓)
- Versija: v1.2
- Datos: vasario-kovo gegužės mėn.*
Apima perkėlimą į naują kodų bazę ir patikrintas, patogus būdas perkelti esamus įrenginius.
* Pastaba: perjungus į Helm 3, werf nebus pridėta reikšmingų funkcijų, nes visos pagrindinės Helm 3 funkcijos (3 krypčių sujungimas ir be vairo) jau įdiegtos werf. Be to, werf turi be nurodytųjų. Tačiau šis perėjimas yra mūsų planuose ir bus įgyvendintas.
Jsonnet, skirtas Kubernetes konfigūracijai aprašyti (↓)
- Versija: v1.2
- Datos: sausis-vasaris balandis-gegužė
Werf palaikys Kubernetes konfigūracijos aprašymus Jsonnet formatu. Tuo pačiu metu werf išliks suderinamas su Helm ir bus galima pasirinkti aprašymo formatą.
Priežastis ta, kad „Go“ šablonai, daugelio žmonių nuomone, turi aukštą patekimo barjerą, taip pat nukenčia ir šių šablonų kodo suprantamumas.
Taip pat svarstoma galimybė įdiegti kitas Kubernetes konfigūracijos aprašymo sistemas (pavyzdžiui, Kustomize).
Darbas Kubernetes (↓)
- Versija: v1.2
- Datos: balandžio-gegužės-gegužės-birželio mėn
Tikslas: užtikrinti, kad vaizdai būtų sukurti ir programa būtų pristatyta naudojant Kubernetes bėgikus. Tie. Naujus vaizdus galima kurti, publikuoti, išvalyti ir įdiegti tiesiai iš „Kubernetes“ rinkinių.
Norėdami įgyvendinti šią galimybę, pirmiausia turite turėti galimybę sukurti paskirstytus vaizdus (žr. aukščiau esantį punktą).
Tam taip pat reikalingas kūrėjo darbo režimo palaikymas be „Docker“ serverio (t. y. „Kaniko“ tipo kūrimo arba kūrimo vartotojo erdvėje).
„Werf“ palaikys „Kubernetes“ kūrimą ne tik naudodamas „Dockerfile“, bet ir su „Stapel“ kūrėju, atlikdamas laipsnišką perstatymą ir „Ansible“.
Žingsnis atviros plėtros link
Mes mylime savo bendruomenę (, ) ir norime, kad vis daugiau žmonių padėtų tobulinti werf, suprastų kryptį, kuria judame, ir dalyvautų kuriant.
Visai neseniai buvo nuspręsta pereiti prie siekdami atskleisti mūsų komandos darbo procesą. Dabar galite matyti artimiausius planus ir dabartinį darbą šiose srityse:
- ;
- ;
- ;
- .
Daug padirbėta su problemomis:
- Pašalino nereikšmingus.
- Esamos suvestos į vieną formatą, turint pakankamai detalių ir detalių.
- Pridėta naujų problemų su idėjomis ir pasiūlymais.
Kaip įjungti versiją v1.1
Versija šiuo metu pasiekiama (kanaluose stabilus и uola Tačiau išleidimai pasirodys stabilizavus ea pats jau yra pakankamai stabilus naudojimui, nes ėjo per kanalus alfa и beta). Suaktyvinta tokiu būdu:
source $(multiwerf use 1.1 ea)
werf COMMAND ...išvada
Nauja etapo saugyklos architektūra ir kūrėjų optimizavimas Stapel ir Dockerfile kūrėjams atveria galimybę įdiegti paskirstytas ir lygiagrečias kūrimas werf. Šios funkcijos netrukus pasirodys tame pačiame v1.1 leidime ir bus automatiškai pasiekiamos naudojant automatinio atnaujinimo mechanizmą (naudotojams ).
Šiame leidime buvo pridėta žymėjimo strategija, pagrįsta vaizdo turiniu – turiniu pagrįstas žymėjimas, kuri tapo numatytoji strategija. Pagrindinis komandų žurnalas taip pat buvo perdarytas: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Kitas svarbus žingsnis yra paskirstytų mazgų pridėjimas. Paskirstytos versijos tapo didesniu prioritetu nei lygiagrečios versijos nuo 1.0 versijos, nes jos suteikia daugiau vertės werf: vertikalus kūrėjų mastelio keitimas ir trumpalaikių kūrėjų palaikymas įvairiose CI / CD sistemose, taip pat galimybė oficialiai palaikyti GitHub veiksmus. . Todėl lygiagrečių surinkimų įgyvendinimo terminai buvo perkelti. Tačiau stengiamės kuo greičiau įgyvendinti abi galimybes.
Sekite naujienas! Ir nepamirškite apsilankyti pas mus Norėdami sukurti problemą, susiraskite esamą ir pridėkite pliusą, sukurkite PR arba tiesiog stebėkite projekto vystymąsi.
PS
Taip pat skaitykite mūsų tinklaraštyje:
- «»
- «»;
- Pastabų apie werf naujoves serija:
- «»;
- «»;
- «»;
- «".
Šaltinis: www.habr.com