Atbalsts monorepo un multirepo werf un kāds ar to saistīts Docker reģistrs

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?

Atbalsts monorepo un multirepo werf un kāds ar to saistīts Docker reģistrs

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:

  1. Saglabājiet attēlus atseviŔķos ligzdotos krātuvēs:

    Atbalsts monorepo un multirepo werf un kāds ar to saistīts Docker reģistrs

  2. Saglabājiet visu vienā repozitorijā un ņemiet vērā attēla nosaukumu tagā, piemēram, Ŕādi:

    Atbalsts monorepo un multirepo werf un kāds ar to saistīts Docker reģistrs

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:

  1. 3 stratēģijas, ko saista Git primitīvi, piemēram, tag, branch un commit;
  2. 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!

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru