🥇Turiniu pagrįstas žymėjimas werf kolekcionieriuje: kodėl ir kaip tai veikia?

werf yra mūsų atvirojo kodo „GitOps CLI“ programa, skirta kurti ir teikti programas „Kubernetes“. IN leidimas v1.1 vaizdų rinkiklyje buvo įdiegta nauja funkcija: vaizdų žymėjimas pagal turinį arba turiniu pagrįstas žymėjimas. Iki šiol tipinė werf žymėjimo schema apimdavo Docker vaizdų žymėjimą naudojant Git tag, Git branch arba Git commit. Tačiau visos šios schemos turi trūkumų, kuriuos visiškai išsprendžia nauja žymėjimo strategija. Išsami informacija apie tai ir kodėl ji tokia gera, pateikiama žemiau.

Mikropaslaugų rinkinio išleidimas iš vienos „Git“ saugyklos

Dažnai susidaro situacija, kai programa yra padalinta į daug daugiau ar mažiau nepriklausomų paslaugų. Šių paslaugų išleidimas gali vykti savarankiškai: vienu metu gali būti išleista viena ar daugiau paslaugų, o likusios turi veikti toliau be jokių pakeitimų. Tačiau kodo saugojimo ir projektų valdymo požiūriu tokias taikomųjų programų paslaugas patogiau laikyti vienoje saugykloje.

Yra situacijų, kai paslaugos yra tikrai nepriklausomos ir nesusijusios su viena programa. Tokiu atveju jie bus išdėstyti atskiruose projektuose ir jų išleidimas bus vykdomas per atskirus CI/CD procesus kiekviename iš projektų.

Tačiau iš tikrųjų kūrėjai dažnai padalija vieną aplikaciją į kelias mikropaslaugas, tačiau sukurti kiekvienai atskirą saugyklą ir projektą... yra aiškus perteklius. Būtent ši situacija bus aptariama toliau: kelios tokios mikropaslaugos yra vienoje projekto saugykloje, o išleidimai vyksta vienu procesu CI/CD.

Žymėjimas pagal Git filialą ir Git žymą

Tarkime, kad naudojama dažniausiai naudojama žymėjimo strategija – žyma arba šaka. Git filialuose vaizdai žymimi filialo pavadinimu, o vienam filialui vienu metu skelbiamas tik vienas vaizdas pagal tos šakos pavadinimą. „Git“ žymose vaizdai žymimi pagal žymos pavadinimą.

Kai sukuriama nauja Git žyma, pavyzdžiui, kai išleidžiama nauja versija, bus sukurta nauja Docker žyma visiems projekto vaizdams Docker registre:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Šie nauji vaizdų pavadinimai per Helm šablonus perduodami į Kubernetes konfigūraciją. Pradedant dislokavimą komanda werf deploy laukas atnaujinamas image „Kubernetes“ išteklių aprašuose ir iš naujo paleidžiant atitinkamus išteklius dėl pakeisto vaizdo pavadinimo.

problema: tuo atveju, kai iš tikrųjų vaizdo turinys nepasikeitė nuo ankstesnio išleidimo („Git“ žyma), o tik „Docker“ žyma, taip atsitinka papildomai iš naujo paleidžiant šią programą ir atitinkamai galimos prastovos. Nors nebuvo jokios realios priežasties atlikti šį paleidimą iš naujo.

Dėl to, naudojant dabartinę žymėjimo schemą, būtina atskirti kelias atskiras „Git“ saugyklas ir kyla problemų organizuojant šių kelių saugyklų diegimą. Apskritai tokia schema pasirodo perkrauta ir sudėtinga. Geriau sujungti daugybę paslaugų į vieną saugyklą ir sukurti Docker žymas, kad nebūtų nereikalingų paleidimų iš naujo.

Žymėjimas naudojant Git commit

werf taip pat turi žymėjimo strategiją, susijusią su Git įsipareigojimais.

„Git-commit“ yra „Git“ saugyklos turinio identifikatorius ir priklauso nuo „Git“ saugyklos failų redagavimo istorijos, todėl atrodo logiška jį naudoti žymint vaizdus „Docker“ registre.

Tačiau žymėjimas naudojant Git commit turi tuos pačius trūkumus, kaip ir žymėjimas naudojant Git filialus arba Git žymas:

Galima sukurti tuščią įsipareigojimą, kuris nekeičia jokių failų, tačiau vaizdo Docker žyma bus pakeista.
Galima sukurti sujungimo įsipareigojimą, kuris nekeičia failų, tačiau vaizdo „Docker“ žyma bus pakeista.
Gali būti atliktas įsipareigojimas pakeisti tuos „Git“ failus, kurie nėra importuoti į vaizdą, ir vaizdo „Docker“ žyma bus pakeista dar kartą.

Git filialo pavadinimo žymėjimas neatspindi vaizdo versijos

Yra dar viena problema, susijusi su „Git“ filialų žymėjimo strategija.

Žymėjimas pagal šakos pavadinimą veikia tol, kol tos šakos įsipareigojimai renkami nuosekliai chronologine tvarka.

Jei pagal dabartinę schemą vartotojas pradeda atstatyti seną įsipareigojimą, susietą su tam tikra šaka, tada werf perrašys vaizdą naudodamas atitinkamą Docker žymą su naujai sukurta senojo įpareigojimo vaizdo versija. Diegiant šią žymą nuo šiol kyla pavojus, kad paleidžiant blokus iš naujo bus ištraukta kita vaizdo versija, todėl mūsų programa praras ryšį su CI sistema ir bus desinchronizuota.

Be to, nuosekliai stumiant į vieną šaką su trumpu laiko tarpu tarp jų, senasis įsipareigojimas gali būti sudarytas vėliau nei naujesnis: senoji vaizdo versija perrašys naują, naudodama Git filialo žymą. Tokias problemas galima išspręsti naudojant CI/CD sistemą (pavyzdžiui, GitLab CI paleidžiamas pastarosios konvejeras, skirtas įsipareigojimų serijai). Tačiau ne visos sistemos tai palaiko ir turi būti patikimesnis būdas užkirsti kelią tokiai esminei problemai.

Kas yra turiniu pagrįstas žymėjimas?

Taigi, kas yra turiniu pagrįstas žymėjimas – vaizdų žymėjimas pagal turinį.

Norint sukurti Docker žymas, naudojami ne Git primityvai (Git filialas, Git žyma...), o kontrolinė suma, susieta su:

vaizdo turinį. Vaizdo ID žyma atspindi jos turinį. Kuriant naują versiją, šis identifikatorius nepasikeis, jei vaizde esantys failai nepasikeitė;
šio vaizdo sukūrimo Git istorija. Vaizdai, susieti su skirtingomis Git šakomis ir skirtinga kūrimo istorija per werf, turės skirtingas ID žymas.

Tokia identifikatoriaus žyma yra vadinamoji vaizdo sceninis parašas.

Kiekvienas vaizdas susideda iš etapų rinkinio: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch ir tt Kiekvienas etapas turi identifikatorių, atspindintį jo turinį − sceninis parašas (sceninis parašas).

Galutinis vaizdas, susidedantis iš šių etapų, yra pažymėtas vadinamuoju šių etapų rinkinio parašu - etapų parašas, – apibendrina visus vaizdo etapus.

Kiekvienam vaizdui iš konfigūracijos werf.yaml bendru atveju bus savo parašas ir atitinkamai Docker žyma.

Scenos parašas išsprendžia visas šias problemas:

Atsparus tuščiiems Git įsipareigojimams.
Atsparus „Git“ įsipareigojimams, kurie keičia su vaizdu nesusijusius failus.
Nekyla problemų, susijusių su dabartinės vaizdo versijos pertvarkymu, kai iš naujo paleidžiama senų atšakos Git įpareigojimų versija.

Dabar tai yra rekomenduojama žymėjimo strategija ir numatytoji werf visose CI sistemose.

Kaip įjungti ir naudoti werf

Dabar komanda turi atitinkamą parinktį werf publish: --tag-by-stages-signature=true|false

CI sistemoje žymėjimo strategija nurodoma komanda werf ci-env. Anksčiau jam buvo nustatytas parametras werf ci-env --tagging-strategy=tag-or-branch. Dabar, jei nurodysite werf ci-env --tagging-strategy=stages-signature arba nenurodykite šios parinkties, werf pagal numatytuosius nustatymus naudos žymėjimo strategiją stages-signature. Komanda werf ci-env automatiškai nustatys reikiamas komandos vėliavėles werf build-and-publish (Arba werf publish), todėl šioms komandoms nereikia nurodyti jokių papildomų parinkčių.

Pavyzdžiui, komanda:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...gali sukurti šiuos vaizdus:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Čia 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d yra vaizdo etapų parašas backendIr f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - įvaizdžio etapų parašas frontend.

Naudojant specialias funkcijas werf_container_image и werf_container_env Helm šablonuose nieko keisti nereikia: šios funkcijos automatiškai sugeneruos teisingus vaizdų pavadinimus.

Konfigūracijos pavyzdys CI sistemoje:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Daugiau informacijos apie konfigūraciją rasite dokumentacijoje:

Iš viso

Naujas variantas werf publish --tag-by-stages-signature=true|false.
Nauja pasirinkimo vertė werf ci-env --tagging-strategy=stages-signature|tag-or-branch (jei nenurodyta, numatytasis bus stages-signature).
Jei anksčiau naudojote „Git“ įsipareigojimų žymėjimo parinktis (WERF_TAG_GIT_COMMIT arba variantas werf publish --tag-git-commit COMMIT), tada būtinai perjunkite į žymėjimo strategiją etapai-parašas.
Geriau iš karto pakeisti naujus projektus į naują žymėjimo schemą.
Perkeliant į werf 1.1, patartina senus projektus pakeisti į naują žymėjimo schemą, bet seną žyma arba šaka vis dar palaikoma.

Turiniu pagrįstas žymėjimas išsprendžia visas straipsnyje aptartas problemas:

Docker žymos pavadinimo atsparumas tuščiam Git įsipareigojimui.
Docker žymos pavadinimo atsparumas Git įsipareigojimams pakeisti failus, nesusijusius su vaizdu.
Nekyla problemų, susijusių su dabartinės vaizdo versijos pertvarkymu, kai iš naujo paleidžiama senų „Git“ įsipareigojimų „Git“ atšakų versija.

Panaudok tai! Ir nepamirškite apsilankyti pas mus GitHubsukurti problemą arba rasti esamą, pridėti pliusą, sukurti PR arba tiesiog stebėti projekto vystymąsi.

PS

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Turiniu pagrįstas žymėjimas werf kolekcionieriuje: kodėl ir kaip tai veikia?