Suporta alang sa monorepo ug multirepo sa werf ug unsa ang kalabotan sa Docker Registry niini

Ang hilisgutan sa usa ka mono-repository gihisgutan labaw pa sa kausa ug, ingon nga usa ka lagda, hinungdan sa aktibo nga kontrobersiya. Pinaagi sa paghimo werf isip usa ka open source tool nga gidesinyo aron mapalambo ang proseso sa pagtukod og application code gikan sa Git ngadto sa Docker nga mga hulagway (ug dayon ihatod kini ngadto sa Kubernetes), wala kaayo mi maghunahuna kon asa nga pagpili ang labing maayo. Alang kanamo, nag-una ang paghatag sa tanan nga gikinahanglan alang sa mga tigpaluyo sa lainlaing mga opinyon (kung dili kini sukwahi sa sentido komon, siyempre).

Ang bag-o nga mono-repo nga suporta ni werf usa ka maayong pananglitan niini. Apan una, atong mahibal-an kung giunsa kini nga suporta sa kasagaran adunay kalabotan sa paggamit sa werf ug kung unsa ang buhaton sa Docker Registry niini ...

Mga isyu

Hunahunaa ang ingon nga kahimtang. Ang kompanya adunay daghang mga development team nga nagtrabaho sa mga independente nga proyekto. Kadaghanan sa mga aplikasyon nagdagan sa Kubernetes ug busa gisudlan. Sa pagtipig sa mga sudlanan, mga hulagway, kinahanglan nimo ang usa ka rehistro (registry). Ingon nga usa ka rehistro, gigamit sa kompanya ang Docker Hub nga adunay usa ka account COMPANY. Sama sa kadaghanan sa mga sistema sa pagtipig sa source code, Ang Docker Hub wala magtugot sa nested repository hierarchy, sama sa COMPANY/PROJECT/IMAGE. Niana nga kaso… unsaon nimo pagtipig sa mga non-monolithic nga aplikasyon sa rehistro nga adunay kini nga limitasyon nga wala maghimo usa ka lahi nga account alang sa matag proyekto?

Tingali, ang gihulagway nga sitwasyon pamilyar sa usa ka tawo mismo, apan atong tagdon ang isyu sa pag-organisar sa pagtipig sa aplikasyon sa kinatibuk-an, i.e. nga walay paghisgot sa pananglitan sa ibabaw ug Docker Hub.

Mga solusyon

Kung ang aplikasyon monolitik, moabut sa usa ka imahe, unya wala’y mga pangutana ug gitipigan ra namon ang mga imahe sa rehistro sa sulud sa proyekto.

Kung ang usa ka aplikasyon gipresentar ingon daghang mga sangkap, microservices, nan gikinahanglan ang usa ka paagi. Sa pananglitan sa usa ka tipikal nga aplikasyon sa web nga naglangkob sa duha ka mga imahe: frontend и backend - ang posible nga mga kapilian mao ang:

1. Tipigi ang mga hulagway sa bulag nga nested repository:

   

2. Itago ang tanan sa usa ka repository, ug hunahunaa ang ngalan sa imahe sa tag, pananglitan, ingon sa mosunod:

   

NB: Sa tinuud, adunay lain nga kapilian sa pagtipig sa lainlaing mga repositoryo, PROJECT-frontend и PROJECT-backend, apan dili namo kini tagdon tungod sa pagkakomplikado sa suporta, organisasyon ug pag-apod-apod sa mga katungod tali sa mga tiggamit.

suporta sa werf

Sa sinugdan, gilimitahan sa werf ang kaugalingon sa mga nested repository - maayo na lang, kadaghanan sa mga rehistro nagsuporta niini nga bahin. Pagsugod sa bersyon v1.0.4-alpha.3, dugang nga trabaho sa mga rehistro diin wala gisuportahan ang nesting, ug ang Docker Hub usa niini. Gikan nianang puntoha, ang user adunay kapilian kung unsaon pagtipig sa mga imahe sa aplikasyon.

Implementasyon anaa ubos sa opsyon --images-repo-mode=multirepo|monorepo (default multirepo, i.e. pagtipig sa mga nested repository). Gihubit niini ang mga sumbanan diin ang mga imahe gitipigan sa rehistro. Igo na ang pagpili sa gitinguha nga mode kung gigamit ang sukaranan nga mga mando, ug ang tanan magpabilin nga wala mausab.

Tungod kay ang kadaghanan sa mga kapilian sa werf mahimong itakda mga variable sa palibot, sa mga sistema sa CI / CD, ang mode sa pagtipig kasagaran sayon ​​​​nga itakda sa tibuok kalibutan alang sa tibuok nga proyekto. Pananglitan, sa kaso sa GitLab idugang lang ang usa ka variable sa palibot sa mga setting sa proyekto: Mga Setting -> CI / CD -> Mga Variable: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Kung maghisgot kami bahin sa pagmantala sa mga imahe ug paglansad sa mga aplikasyon (mahimo nimo mabasa ang bahin sa kini nga mga proseso sa detalye sa mga may kalabotan nga artikulo sa dokumentasyon: Proseso sa pagmantala и Proseso sa pag-deploy), unya ang mode ra ang nagtino sa template diin mahimo nimong magamit ang imahe.

Ang yawa anaa sa mga detalye

Ang kalainan ug ang nag-unang kalisud sa pagdugang sa usa ka bag-ong paagi sa pagtipig anaa sa proseso sa paglimpyo sa rehistro (alang sa mga bahin sa paglimpyo nga gisuportahan sa werf, tan-awa Proseso sa paglimpiyo).

Kung nanglimpyo, gikonsiderar sa werf ang mga imahe nga gigamit sa mga cluster sa Kubernetes, ingon man ang mga palisiya nga gi-configure sa tiggamit. Ang mga palisiya gibase sa pagbahin sa mga tag ngadto sa mga estratehiya. Gisuportahan karon nga mga estratehiya:

1. 3 nga mga estratehiya nga gi-link sa Git primitives sama sa tag, branch, ug commit;
2. 1 nga estratehiya para sa arbitraryong custom nga mga tag.

Gitipigan namon ang kasayuran bahin sa estratehiya sa tag kung gipatik ang imahe sa mga label sa katapusan nga imahe. Ang kahulogan mismo mao ang gitawag meta tag - Gikinahanglan nga ipadapat ang pipila sa mga palisiya. Pananglitan, kung magtangtang sa usa ka sanga o tag gikan sa usa ka repositoryo sa Git, lohikal ang pagtangtang nga may kalabotan wala magamit mga hulagway gikan sa registry, nga nasakup sa bahin sa among mga palisiya.

Kung gitipigan sa usa ka repository (monorepo), sa tag sa imahe, dugang sa meta tag, ang ngalan sa imahe mahimo usab nga tipigan: PROJECT:frontend-META-TAG. Aron mabulag sila, wala kami nagpaila sa bisan unsang piho nga separator, apan gidugang lamang ang kinahanglan nga kantidad sa label sa katapusan nga imahe kung gimantala.

NB: Kung interesado ka sa pagtan-aw sa tanan nga gihulagway sa werf source code, nan ang punto sa pagsugod mahimo PR 1684.

Niini nga artikulo, dili na nato hatagan ug dugang pagtagad ang mga problema ug katarungan sa atong pamaagi: mahitungod sa mga estratehiya sa pag-tag, pagtipig sa datos sa mga label ug sa proseso sa pagmantala sa kinatibuk-an - kining tanan gihulagway sa detalye sa usa ka bag-o nga taho ni Dmitry Stolyarov: "Ang werf mao ang among himan alang sa CI/CD sa Kubernetes".

Sa pagsumada

Ang kakulang sa suporta alang sa unnested registries dili usa ka blocking factor alang kanamo o sa werf users nga nailhan namo - human sa tanan, mahimo ka kanunay nga magpataas sa usa ka bulag nga rehistro sa imahe (o mobalhin sa usa ka conditional Container Registry sa Google Cloud) ... Apan, ang pagtangtang sa ingon nga pagdili ingon og makatarunganon aron ang himan mahimong mas kombenyente sa mas lapad nga komunidad sa DevOps. Sa pagpatuman niini, nag-atubang kami sa nag-unang kalisud sa pag-rework sa mekanismo sa paglimpyo sa rehistro sa sudlanan. Karon nga ang tanan andam na, kini nindot nga makaamgo nga kini nahimong mas sayon ​​alang sa usa ka tawo, ug kami (ingon nga ang nag-unang developers sa proyekto) walay bisan unsa nga mamatikdan nga mga kalisdanan sa dugang pagsuporta niini nga bahin.

Pabilin kanamo ug sa dili madugay kami mosulti kanimo bahin sa ubang mga inobasyon sa werf!

PS

Basaha usab sa among blog:

• «Mahimo ka na karon magtukod mga imahe sa Docker sa werf gamit ang usa ka regular nga Dockerfile";
• «werf - among himan alang sa CI / CD sa Kubernetes (kinatibuk-ang pagtan-aw ug taho sa video)".

Source: www.habr.com