Atbalsts monorepo un multirepo werf un kÄds ar to saistÄ«ts Docker reÄ£istrs
MonokrÄtuves tÄma ir apspriesta vairÄk nekÄ vienu reizi un, kÄ likums, izraisa ļoti aktÄ«vus strÄ«dus. Radot werf kÄ atvÄrtÄ pirmkoda rÄ«ks, kas paredzÄts, lai uzlabotu lietojumprogrammas koda veidoÅ”anas procesu no Git uz Docker attÄliem (un pÄc tam tos nogÄdÄjot Kubernetes), mÄs daudz nedomÄjam par to, kura izvÄle ir vislabÄkÄ. Mums primÄri ir nodroÅ”inÄt visu nepiecieÅ”amo dažÄdu viedokļu piekritÄjiem (ja tas, protams, nav pretrunÄ ar veselo saprÄtu).
werf nesenais monorepo atbalsts ir labs piemÄrs tam. Bet vispirms izdomÄsim, kÄ Å”is atbalsts parasti ir saistÄ«ts ar werf izmantoÅ”anu un kÄds ar to ir saistÄ«ts Docker reÄ£istrs ...
problÄmas
IedomÄsimies Å”Ädu situÄciju. UzÅÄmumam ir daudzas attÄ«stÄ«bas komandas, kas strÄdÄ pie neatkarÄ«giem projektiem. LielÄkÄ daļa lietojumprogrammu darbojas Kubernetes, un tÄpÄc tÄs ir konteinerizÄtas. Lai uzglabÄtu konteinerus, attÄlus, nepiecieÅ”ams reÄ£istrs (reÄ£istrs). KÄ Å”Ädu reÄ£istru uzÅÄmums izmanto Docker Hub ar vienu kontu COMPANY. LÄ«dzÄ«gi kÄ lielÄkajai daļai pirmkoda glabÄÅ”anas sistÄmu, Docker Hub neatļauj ligzdotu repozitoriju hierarhiju, piemÄram, COMPANY/PROJECT/IMAGE. TÄdÄ gadÄ«jumÄ... kÄ jÅ«s varat saglabÄt nemonolÄ«tas lietojumprogrammas reÄ£istrÄ ar Å”o ierobežojumu, neveidojot atseviŔķu kontu katram projektam?
IespÄjams, aprakstÄ«tÄ situÄcija kÄdam ir pazÄ«stama no pirmavotiem, taÄu apskatÄ«sim jautÄjumu par lietojumprogrammu krÄtuves organizÄÅ”anu kopumÄ, t.i. bez atsauces uz iepriekÅ” minÄto piemÄru un Docker Hub.
RisinÄjumi
Ja pieteikums monolÄ«ta, nÄk vienÄ attÄlÄ, tad jautÄjumu nav un attÄlus vienkÄrÅ”i saglabÄjam projekta konteineru reÄ£istrÄ.
Ja lietojumprogramma tiek parÄdÄ«ta kÄ vairÄkas sastÄvdaļas, mikropakalpojumi, tad ir nepiecieÅ”ama noteikta pieeja. Tipiskas tÄ«mekļa lietojumprogrammas piemÄrÄ, kas sastÄv no diviem attÄliem: frontend Šø backend - iespÄjamie varianti ir:
SaglabÄjiet visu vienÄ repozitorijÄ un Åemiet vÄrÄ attÄla nosaukumu tagÄ, piemÄram, Å”Ädi:
NB: PatiesÄ«bÄ ir vÄl viena iespÄja ar saglabÄÅ”anu dažÄdÄs krÄtuvÄs, PROJECT-frontend Šø PROJECT-backend, taÄu mÄs to neuzskatÄ«sim, jo āāir sarežģīts atbalsts, organizÄcija un tiesÄ«bu sadale starp lietotÄjiem.
werf atbalsts
SÄkotnÄji werf aprobežojÄs ar ligzdotÄm krÄtuvÄm - par laimi, lielÄkÄ daļa reÄ£istru atbalsta Å”o funkciju. SÄkot no versijas v1.0.4-alpha.3, pievienots darbs ar reÄ£istriem, kuros ligzdoÅ”ana netiek atbalstÄ«ta, un Docker Hub ir viens no tiem. No Ŕī brīža lietotÄjs var izvÄlÄties, kÄ saglabÄt lietojumprogrammas attÄlus.
IevieÅ”ana pieejama saskaÅÄ ar opciju --images-repo-mode=multirepo|monorepo (noklusÄjums multirepo, t.i. glabÄÅ”ana ligzdotajos krÄtuvÄs). Tas nosaka modeļus, pÄc kuriem attÄli tiek glabÄti reÄ£istrÄ. Pietiek, lai, izmantojot pamata komandas, izvÄlÄtos vajadzÄ«go režīmu, un viss pÄrÄjais paliks nemainÄ«gs.
TÄ kÄ lielÄko daļu werf opciju var iestatÄ«t vides mainÄ«gieCI/CD sistÄmÄs uzglabÄÅ”anas režīmu parasti ir viegli iestatÄ«t globÄli visam projektam. PiemÄram, GitLab gadÄ«jumÄ vienkÄrÅ”i pievienojiet vides mainÄ«go projekta iestatÄ«jumos: IestatÄ«jumi -> CI / CD -> MainÄ«gie: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ja mÄs runÄjam par attÄlu publicÄÅ”anu un lietojumprogrammu izvÄrÅ”anu (par Å”iem procesiem sÄ«kÄk varat izlasÄ«t attiecÄ«gajos dokumentÄcijas rakstos: PublicÄÅ”anas process Šø IzvietoÅ”anas process), tad režīms nosaka tikai veidni, pÄc kuras varat strÄdÄt ar attÄlu.
Velns slÄpjas detaļÄs
AtŔķirÄ«ba un galvenÄs grÅ«tÄ«bas, pievienojot jaunu uzglabÄÅ”anas metodi, ir reÄ£istra tÄ«rÄ«Å”anas procesÄ (lai iegÅ«tu informÄciju par tÄ«rÄ«Å”anas funkcijÄm, ko atbalsta werf, skatiet TÄ«rÄ«Å”anas process).
Veicot tÄ«rÄ«Å”anu, werf Åem vÄrÄ Kubernetes klasteros izmantotos attÄlus, kÄ arÄ« lietotÄja konfigurÄtÄs politikas. Politikas ir balstÄ«tas uz tagu sadalÄ«jumu stratÄÄ£ijÄs. PaÅ”laik atbalstÄ«tÄs stratÄÄ£ijas:
3 stratÄÄ£ijas, ko saista Git primitÄ«vi, piemÄram, tag, branch un commit;
1 stratÄÄ£ija patvaļīgiem pielÄgotiem tagiem.
InformÄciju par tagu stratÄÄ£iju, publicÄjot attÄlu, saglabÄjam gala attÄla etiÄ·etÄs. Pati nozÄ«me ir t.s metatags - NepiecieÅ”ams, lai piemÄrotu dažas politikas. PiemÄram, dzÄÅ”ot filiÄli vai tagu no Git repozitorija, ir loÄ£iski izdzÄst saistÄ«tos neizmantota attÄlus no reÄ£istra, uz ko attiecas daļa no mÅ«su politikÄm.
SaglabÄjot vienÄ repozitorijÄ (monorepo), attÄla tagÄ papildus metatagam var saglabÄt arÄ« attÄla nosaukumu: PROJECT:frontend-META-TAG. Lai tos atdalÄ«tu, mÄs neieviesÄm nekÄdu Ä«paÅ”u atdalÄ«tÄju, bet publicÄÅ”anas laikÄ vienkÄrÅ”i pievienojÄm nepiecieÅ”amo vÄrtÄ«bu gala attÄla etiÄ·etei.
NB: Ja interesÄ apskatÄ«t visu, kas aprakstÄ«ts werf pirmkodÄ, tad sÄkumpunkts var bÅ«t PR 1684.
Å ajÄ rakstÄ mÄs nepievÄrsÄ«sim lielÄku uzmanÄ«bu mÅ«su pieejas problÄmÄm un pamatojumam: par marÄ·ÄÅ”anas stratÄÄ£ijÄm, datu uzglabÄÅ”anu etiÄ·etÄs un publicÄÅ”anas procesu kopumÄ - tas viss ir detalizÄti aprakstÄ«ts nesenajÄ Dmitrija Stoļarova ziÅojumÄ: āwerf ir mÅ«su CI/CD rÄ«ks pakalpojumÄ Kubernetes'.
Apkopot
Neligzdoto reÄ£istru atbalsta trÅ«kums nebija bloÄ·ÄjoÅ”s faktors ne mums, ne mums zinÄmajiem werf lietotÄjiem - galu galÄ jÅ«s vienmÄr varat izveidot atseviŔķu attÄlu reÄ£istru (vai pÄrslÄgties uz nosacÄ«to konteineru reÄ£istru Google mÄkonÄ«) ... TomÄr, Å”Äda ierobežojuma noÅemÅ”ana Ŕķita loÄ£iski, lai rÄ«ks bÅ«tu ÄrtÄks plaÅ”Äkai DevOps kopienai. IevieÅ”ot to, mÄs saskÄrÄmies ar galvenajÄm grÅ«tÄ«bÄm, pÄrstrÄdÄjot konteineru reÄ£istra tÄ«rÄ«Å”anas mehÄnismu. Tagad, kad viss ir gatavs, ir patÄ«kami apzinÄties, ka kÄdam ir kļuvis vieglÄk, un mums (kÄ galvenajiem projekta izstrÄdÄtÄjiem) nebÅ«s manÄmu grÅ«tÄ«bu Ŕīs funkcijas turpmÄkajÄ atbalstÄ«Å”anÄ.
Palieciet kopÄ ar mums, un pavisam drÄ«z mÄs jums pastÄstÄ«sim par citiem jauninÄjumiem werf!