It ûnderwerp fan in monorepository is mear as ien kear besprutsen en feroarsaket yn 'e regel tige aktyf debat. Oanmeitsjen As in Open Source-ark ûntworpen om it proses fan it bouwen fan tapassingskoade fan Git yn Docker-ôfbyldings te ferbetterjen (en se dan te leverjen oan Kubernetes), tinke wy net folle oer hokker kar it bêste is. Foar ús is it primêr om alles nedich te jaan foar oanhingers fan ferskate mieningen (as dit fansels net yn striid is mei sûn ferstân).
De koartlyn ynfierde stipe foar mono-repo yn werf is dêr in goed foarbyld fan. Mar litte wy earst útfine hoe't dizze stipe yn 't algemien ferbân is mei it brûken fan werf en wat Docker Registry dêrmei te krijen hat...
Issues
Litte wy ús dizze situaasje foarstelle. It bedriuw hat in protte ûntwikkelingsteams dy't wurkje oan ûnôfhinklike projekten. De measte applikaasjes operearje yn Kubernetes en wurde dêrtroch kontenerisearre. Om konteners en ôfbyldings op te slaan, is in register nedich. It bedriuw brûkt Docker Hub mei ien inkeld akkount as sa'n register. COMPANY. Fergelykber mei de measte boarnekoade-opslachsystemen, Docker Hub lit jo net in geneste hiërargy fan repositories oanmeitsje, lykas COMPANY/PROJECT/IMAGE. Yn dit gefal ... hoe kinne wy net-monolityske applikaasjes opslaan yn it register mei dizze beheining sûnder in apart akkount foar elk projekt te meitsjen?
Miskien is de beskreaune situaasje bekend foar ien fan 'e earste hân, mar lit ús sjen nei de kwestje fan it organisearjen fan applikaasje-opslach yn' t algemien, d.w.s. sûnder ferwizing nei it boppesteande foarbyld en Docker Hub.
Solutions
As de applikaasje monolithically, komt yn ien ôfbylding, dan komme der gjin fragen op en wy bewarje de ôfbyldings gewoan yn it kontenerregister fan it projekt.
As in applikaasje wurdt presintearre as meardere komponinten, mikrotsjinsten, dan moatte jo in bepaalde oanpak kieze. Mei it foarbyld fan in typyske webapplikaasje besteande út twa ôfbyldings: frontend и backend - de mooglike opsjes binne:
- Bewarje ôfbyldings yn aparte geneste repositories:
- Bewarje alles yn ien repository, en befetsje de ôfbyldingsnamme yn 'e tag, bygelyks as folget:
NB: Eins is d'r in oare opsje mei opslaan yn ferskate repositories, PROJECT-frontend и PROJECT-backend, mar wy sille it net beskôgje fanwege de kompleksiteit fan stipe, organisaasje en ferdieling fan rjochten tusken brûkers.
werf stipe
Yn it earstoan wie werf beheind ta geneste repositories - gelokkich stypje de measte registers dizze funksje. Sûnt ferzje , tafoege wurk mei registers wêryn nesting wurdt net stipe, en Docker Hub is ien fan harren. Fan dit momint ôf hie de brûker in kar foar hoe't jo applikaasje-ôfbyldings opslaan.
Ymplemintaasje beskikber as ûnderdiel fan 'e opsje --images-repo-mode=multirepo|monorepo (standert multirepo, d.w.s. opslach yn geneste repositories). It definiearret de patroanen wêrmei't ôfbyldings wurde opslein yn it register. It is genôch om de winske modus te selektearjen by it brûken fan basiskommando's, en al it oare sil net feroare wurde.
Sûnt de measte werf opsjes kinne wurde ynsteld omjouwingsfariabelen, yn CI / CD systemen, de opslach modus is meastal maklik te setten globaal foar it hiele projekt. Bygelyks, yn it gefal fan GitLab Foegje gewoan in omjouwingsfariabele ta yn 'e projektynstellingen: Ynstellings -> CI / CD -> Fariabelen: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
As wy prate oer it publisearjen fan ôfbyldings en it útroljen fan applikaasjes (jo kinne oer dizze prosessen yn detail lêze yn 'e relevante dokumintaasjeartikels: и ), dan bepaalt de modus allinich it sjabloan wêrmei jo mei de ôfbylding kinne wurkje.
De duvel is yn 'e details
It ferskil en de wichtichste muoite by it tafoegjen fan in nije opslachmetoade is yn it proses fan it skjinmeitsjen fan it register (skjinfunksjes stipe yn werf, sjoch ).
By it skjinmeitsjen hâldt werf rekken mei de ôfbyldings dy't brûkt wurde yn Kubernetes-klusters, en ek troch de brûker konfigureare belied. Belied is basearre op it dielen fan tags yn strategyen. Op it stuit stipe strategyen:
- 3 strategyen relatearre oan Git-primitiven lykas tag, branch en commit;
- 1 strategy foar oanpaste oanpaste tags.
Wy bewarje ynformaasje oer de tagstrategy by it publisearjen fan de ôfbylding yn 'e labels fan' e definitive ôfbylding. De betsjutting sels is de saneamde meta tag - nedich foar it tapassen fan guon belied. Bygelyks, by it wiskjen fan in branch of tag út in Git-repository, is it logysk om assosjearre te wiskjen net brûkt ôfbyldings út it register, dat wurdt dekt troch in part fan ús belied.
By it opslaan yn ien repository (monorepo), yn 'e ôfbyldingstag, neist de metatag, kin de namme fan 'e ôfbylding ek opslein wurde: PROJECT:frontend-META-TAG. Om se te skieden hawwe wy gjin spesifike separator ynfierd, mar gewoan de nedige wearde tafoege oan it label fan 'e definitive ôfbylding by it publisearjen.
NB: As jo ynteressearre binne om te sjen nei alles beskreaun yn 'e werf boarnekoade, dan kin it útgongspunt wêze .
Yn dit artikel sille wy net mear omtinken jaan oan de problemen en rjochtfeardiging fan ús oanpak: oer taggingstrategyen, gegevensopslach yn labels en it publisearjen proses yn it algemien - dit alles wurdt yn detail beskreaun yn it resinte rapport fan Dmitry Stolyarov: "".
Gearfetsje
It gebrek oan stipe foar registries sûnder nêst wie gjin blokkearjende faktor foar ús of werf brûkers dy't ús bekend binne - jo kinne ommers altyd in aparte registraasje fan ôfbyldings ophelje (of oerskeakelje nei it betingst Container Registry yn Google Cloud) ... , it fuortheljen fan sa'n beheining like logysk om it ark handiger te meitsjen foar de bredere DevOps-mienskip. By it útfieren fan it, hawwe wy de wichtichste muoite tsjinkaam by it werwurkjen fan it skjinmeitsjen fan kontenerregister. No't alles klear is, is it moai om te witten dat it foar ien makliker wurden is, en wy (as haadûntwikkelders fan it projekt) foarsizze gjin merkbere swierrichheden om dizze funksje fierder te stypjen.
Bliuw by ús en hiel gau sille wy fertelle oer oare ynnovaasjes yn !
PS
Lês ek op ús blog:
- «";
- «".
Boarne: www.habr.com
