Ënnerstëtzung fir Monorepo a Multirepo op werf a wat huet den Docker Registry domat ze dinn

D'Thema vun engem Mono-Repository ass méi wéi eemol diskutéiert ginn an, als Regel, verursaacht ganz aktiv Kontrovers. Duerch Schafung werf als Open Source Tool entwéckelt fir de Prozess vum Bau vun Applikatiounscode vu Git op Docker Biller ze verbesseren (an se dann op Kubernetes ze liwweren), denken mir net vill iwwer wéi eng Wiel am Beschten ass. Fir eis ass et primär alles wat néideg ass fir Unhänger vu verschiddene Meenungen ze bidden (wann dat natierlech net dem gesonde Mënscheverstand widdersprécht).

werf rezent Mono-Repo Ënnerstëtzung ass e gutt Beispill vun dëser. Awer als éischt, loosst eis erausfannen wéi dës Ënnerstëtzung allgemeng mat der Benotzung vu Werf verbonnen ass a wat den Docker Registry domat ze dinn huet ...

Problemer

Loosst eis esou eng Situatioun virstellen. D'Firma huet vill Entwécklungsteams déi un onofhängege Projete schaffen. Déi meescht Uwendungen lafen op Kubernetes a sinn dofir containeriséiert. Fir Container, Biller ze späicheren, braucht Dir e Registry (Registry). Als esou e Registry benotzt d'Firma Docker Hub mat engem eenzege Kont COMPANY. Ähnlech wéi déi meescht Quellcode Späichersystemer, Docker Hub erlaabt net nested Repository Hierarchie, sou wéi COMPANY/PROJECT/IMAGE. An deem Fall ... wéi kënnt Dir net-monolithesch Uwendungen am Registry mat dëser Begrenzung späicheren ouni e separate Kont fir all Projet ze kreéieren?

Vläicht ass déi beschriwwe Situatioun fir een aus der éischter Hand vertraut, awer loosst eis d'Thema vun der Organisatioun vun der Applikatiounspäicherung am Allgemengen betruechten, d.h. ouni Referenz op dat uewe Beispill an Docker Hub.

Léisungen

Wann d'Applikatioun monolithesch, kënnt an engem Bild, da gëtt et keng Froen a mir späicheren d'Biller einfach an de Containerregister vum Projet.

Wann eng Applikatioun als Multiple Komponente presentéiert gëtt, microservices, dann ass eng gewëssen Approche néideg. Am Beispill vun enger typescher Webapplikatioun déi aus zwee Biller besteet: frontend и backend - déi méiglech Optiounen sinn:

1. Späichert Biller an getrennten nested Repositories:

   

2. Späichert alles an engem Repository, a betruecht den Numm vum Bild am Tag, zum Beispill, wéi follegt:

   

NB: Eigentlech gëtt et eng aner Optioun mat Spueren a verschiddene Repositories, PROJECT-frontend и PROJECT-backend, awer mir wäerten et net betruechten wéinst der Komplexitéit vun der Ënnerstëtzung, der Organisatioun an der Verdeelung vu Rechter tëscht de Benotzer.

werf Ënnerstëtzung

Am Ufank huet werf sech op nestet Repositories limitéiert - glécklecherweis ënnerstëtzen déi meescht Registry dës Feature. Vun der Versioun un v1.0.4-alpha.3, dobäi Aarbecht mat registries an deem Nesting gëtt net ënnerstëtzt, an Docker Hub ass ee vun hinnen. Vun deem Punkt un huet de Benotzer e Choix wéi d'Applikatiounsbiller gespäichert ginn.

Ëmsetzung verfügbar ënner Optioun --images-repo-mode=multirepo|monorepo (Standard multirepo, d.h. Stockage an nested Repositories). Et definéiert d'Mustere mat deenen d'Biller am Registry gespäichert ginn. Et ass genuch fir de gewënschte Modus ze wielen wann Dir d'Basisbefehle benotzt, an alles anescht bleift onverännert.

Well déi meescht werf Optiounen kënnen agestallt ginn Ëmweltverännerlechen, an CI / CD Systemer ass de Späichermodus normalerweis einfach global fir de ganze Projet ze setzen. Zum Beispill, am Fall vu GitLab füügt just eng Ëmfeldvariabel an de Projet Astellunge derbäi: Astellungen -> CI / CD -> Variablen: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Wa mir iwwer d'Verëffentlechung vu Biller an d'Ausrollen vun Uwendungen schwätzen (Dir kënnt iwwer dës Prozesser am Detail an den zoustännegen Dokumentatiounsartikelen liesen: Verëffentlechungsprozess и Deploy Prozess), da bestëmmt de Modus eleng d'Schabloun mat där Dir mam Bild schaffe kënnt.

Den Däiwel ass an den Detailer

Den Ënnerscheed an d'Haaptschwieregkeet wann Dir eng nei Späichermethod bäidréit ass am Prozess vun der Reinigung vum Registry (fir Purge Features ënnerstëtzt vu werf, kuckt Botzprozess).

Beim Botzen berücksichtegt werf d'Biller déi a Kubernetes Cluster benotzt ginn, souwéi Politiken déi vum Benotzer konfiguréiert sinn. Politik baséiert op der Divisioun vun Tags an Strategien. Aktuell ënnerstëtzt Strategien:

1. 3 Strategien verbonne mat Git Primitiv wéi Tag, Branche, a Commit;
2. 1 Strategie fir arbiträr personaliséiert Tags.

Mir späicheren Informatioun iwwer d'Tagstrategie beim Verëffentlechen vum Bild an den Etiketten vum finalen Bild. D'Bedeitung selwer ass de sougenannte meta tag - Obligatoresch fir e puer vun de Politiken ze gëllen. Zum Beispill, wann Dir eng Branche oder Tag aus engem Git Repository läschen, ass et logesch fir Zesummenhang ze läschen onbenotzt Biller aus dem Registry, deen duerch en Deel vun eiser Politik ofgedeckt ass.

Wann an engem Repository gespäichert ass (monorepo), am Bildtag, nieft dem Metatag, kann den Numm vum Bild och gespäichert ginn: PROJECT:frontend-META-TAG. Fir se ze trennen, hu mir kee spezifesche Separator agefouert, mee einfach den néidege Wäert op de Label vum finalen Bild bäigefüügt beim Verëffentlechung.

NB: Wann Dir interesséiert sidd fir alles ze kucken wat am werf Quellcode beschriwwe gëtt, da kann de Startpunkt sinn PR 1684.

An dësem Artikel wäerte mir net méi Opmierksamkeet op d'Problemer an d'Begrënnung vun eiser Approche bezuelen: iwwer Taggingstrategien, Daten an Etiketten an de Verëffentlechungsprozess als Ganzt - all dat ass am Detail an engem rezente Bericht vum Dmitry Stolyarov beschriwwen: "werf ass eisen Tool fir CI/CD zu Kubernetes".

Ze resuméieren

De Manktem un Ënnerstëtzung fir onbeschiedegt Registry war net e Blockéierungsfaktor fir eis oder d'werf Benotzer déi eis bekannt sinn - schliisslech kënnt Dir ëmmer e separat Bildregistréieren erhéijen (oder op eng bedingt Container Registry an Google Cloud wiesselen) ... Wéi och ëmmer, sou eng Restriktioun ewechzehuelen schéngt logesch ze sinn fir datt d'Tool méi bequem ass déi breet DevOps Gemeinschaft. Duerch et ëmzesetzen, hu mir d'Haaptschwieregkeet konfrontéiert fir de Containerregistrierungsreinigungsmechanismus ëmzeschaffen. Elo datt alles fäerdeg ass, ass et schéin ze realiséieren datt et méi einfach ginn ass fir een, a mir (als Haaptentwéckler vum Projet) wäerte keng merkbar Schwieregkeeten hunn fir dës Feature weider z'ënnerstëtzen.

Bleift bei eis a ganz geschwënn wäerte mir Iech iwwer aner Innovatiounen soen an werf!

PS

Liest och op eisem Blog:

• «Dir kënnt elo Docker Biller op werf bauen mat engem normale Dockerfile";
• «werf - eisen Tool fir CI / CD zu Kubernetes (Iwwerbléck a Videobericht)".

Source: will.com