🥇Suporta para sa monorepo at multirepo sa werf at ano ang kinalaman dito ng Docker Registry

Ang paksa ng isang monorepository ay tinalakay nang higit sa isang beses at, bilang panuntunan, ay nagdudulot ng napakaaktibong debate. Lumilikha werf Bilang isang tool na Open Source na idinisenyo upang pahusayin ang proseso ng pagbuo ng code ng aplikasyon mula sa Git patungo sa mga imahe ng Docker (at pagkatapos ay ihatid ang mga ito sa Kubernetes), hindi namin masyadong iniisip kung aling pagpipilian ang pinakamahusay. Para sa amin, pangunahing ibigay ang lahat ng kailangan para sa mga tagasuporta ng iba't ibang opinyon (kung hindi ito sumasalungat sa sentido komun, siyempre).

Ang kamakailang ipinakilalang suporta para sa mono-repo sa werf ay isang magandang halimbawa nito. Ngunit una, alamin natin kung paano karaniwang nauugnay ang suportang ito sa paggamit ng werf at kung ano ang kinalaman ng Docker Registry dito...

Mga isyu

Isipin natin ang sitwasyong ito. Ang kumpanya ay may maraming mga development team na nagtatrabaho sa mga independiyenteng proyekto. Karamihan sa mga application ay gumagana sa Kubernetes at, nang naaayon, ay containerized. Upang mag-imbak ng mga lalagyan at larawan, kinakailangan ang isang pagpapatala. Ang kumpanya ay gumagamit ng Docker Hub na may isang account bilang tulad ng isang pagpapatala. COMPANY. Katulad ng karamihan sa mga source code storage system, Hindi ka pinapayagan ng Docker Hub na gumawa ng nested hierarchy ng mga repository, tulad ng COMPANY/PROJECT/IMAGE. Sa kasong ito... paano tayo makakapag-imbak ng mga non-monolithic na application sa registry na may ganitong limitasyon nang hindi gumagawa ng hiwalay na account para sa bawat proyekto?

Marahil ang inilarawan na sitwasyon ay pamilyar sa isang tao nang una, ngunit tingnan natin ang isyu ng pag-aayos ng imbakan ng application sa pangkalahatan, i.e. nang walang pagtukoy sa halimbawa sa itaas at Docker Hub.

Mga solusyon

Kung ang aplikasyon monolitik, ay nasa isang larawan, pagkatapos ay walang mga tanong na lumabas at ise-save lang namin ang mga larawan sa registry ng container ng proyekto.

Kapag ang isang application ay ipinakita bilang maramihang mga bahagi, mga microservice, pagkatapos ay kailangan mong pumili ng isang tiyak na diskarte. Gamit ang halimbawa ng isang karaniwang web application na binubuo ng dalawang larawan: frontend и backend - ang mga posibleng pagpipilian ay:

Mag-imbak ng mga larawan sa magkahiwalay na nested na mga repository:
I-store ang lahat sa isang repository, at isama ang pangalan ng larawan sa tag, halimbawa, tulad ng sumusunod:

NB: Sa totoo lang, may isa pang opsyon sa pag-save sa iba't ibang repository, PROJECT-frontend и PROJECT-backend, ngunit hindi namin ito isasaalang-alang dahil sa pagiging kumplikado ng suporta, organisasyon at pamamahagi ng mga karapatan sa pagitan ng mga user.

suporta ng werf

Sa una, ang werf ay limitado sa mga nested repository - sa kabutihang palad, karamihan sa mga registry ay sumusuporta sa tampok na ito. Mula sa bersyon v1.0.4-alpha.3, nagdagdag ng trabaho sa mga rehistro kung saan hindi suportado ang nesting, at isa sa kanila ang Docker Hub. Mula sa sandaling ito, ang gumagamit ay may pagpipilian kung paano mag-imbak ng mga larawan ng application.

Available ang pagpapatupad bilang bahagi ng opsyon --images-repo-mode=multirepo|monorepo (default multirepo, ibig sabihin. imbakan sa mga nested repository). Tinutukoy nito ang mga pattern kung saan naka-imbak ang mga imahe sa registry. Ito ay sapat na upang piliin ang nais na mode kapag ginagamit ang mga pangunahing utos, at lahat ng iba pa ay mananatiling hindi nagbabago.

Dahil ang karamihan sa mga pagpipilian sa werf ay maaaring itakda mga variable ng kapaligiran, sa mga CI/CD system, ang storage mode ay karaniwang madaling itakda sa buong mundo para sa buong proyekto. Halimbawa, sa kaso ng GitLab Magdagdag lang ng environment variable sa mga setting ng proyekto: Mga Setting -> CI / CD -> Mga Variable: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Kung pinag-uusapan natin ang tungkol sa pag-publish ng mga larawan at paglulunsad ng mga application (maaari mong basahin ang tungkol sa mga prosesong ito nang detalyado sa mga nauugnay na artikulo ng dokumentasyon: Proseso ng pag-publish и I-deploy ang proseso), pagkatapos ang mode ay tanging tumutukoy sa template kung saan maaari kang magtrabaho kasama ang imahe.

Ang diyablo ay nasa mga detalye

Ang pagkakaiba at pangunahing kahirapan kapag nagdaragdag ng isang bagong paraan ng imbakan ay nasa proseso ng paglilinis ng pagpapatala (Mga tampok sa paglilinis na sinusuportahan sa werf, tingnan Proseso ng paglilinis).

Kapag naglilinis, isinasaalang-alang ng werf ang mga larawang ginamit sa mga cluster ng Kubernetes, pati na rin ang mga patakarang na-configure ng user. Ang mga patakaran ay batay sa paghahati ng mga tag sa mga diskarte. Mga diskarte na kasalukuyang sinusuportahan:

3 diskarte na nauugnay sa mga primitive ng Git tulad ng tag, branch at commit;
1 diskarte para sa mga custom na custom na tag.

Nagse-save kami ng impormasyon tungkol sa diskarte sa tag kapag pina-publish ang larawan sa mga label ng huling larawan. Ang kahulugan mismo ay ang tinatawag na meta tag — kinakailangan para sa paglalapat ng ilang patakaran. Halimbawa, kapag nagtatanggal ng branch o tag mula sa isang Git repository, lohikal na tanggalin ang nauugnay hindi nagamit mga larawan mula sa registry, na sakop ng bahagi ng aming mga patakaran.

Kapag nagse-save sa isang repository (monorepo), sa tag ng larawan, bilang karagdagan sa meta tag, ang pangalan ng larawan ay maaari ding iimbak: PROJECT:frontend-META-TAG. Upang paghiwalayin ang mga ito, hindi kami nagpakilala ng anumang partikular na separator, ngunit idinagdag lamang ang kinakailangang halaga sa label ng huling larawan kapag nag-publish.

NB: Kung interesado kang tingnan ang lahat ng inilarawan sa source code ng werf, kung gayon ang panimulang punto ay maaaring PR 1684.

Sa artikulong ito ay hindi na namin bibigyan ng higit na pansin ang mga problema at katwiran ng aming diskarte: tungkol sa mga diskarte sa pag-tag, pag-iimbak ng data sa mga label at ang proseso ng pag-publish sa pangkalahatan - lahat ng ito ay inilarawan nang detalyado sa kamakailang ulat ni Dmitry Stolyarov: "Ang werf ay ang aming tool para sa CI/CD sa Kubernetes'.

Upang ibuod

Ang kakulangan ng suporta para sa mga registry na walang nesting ay hindi isang blocking factor para sa amin o sa mga user ng werf na kilala namin - pagkatapos ng lahat, maaari kang palaging magtaas ng hiwalay na registry ng mga larawan (o lumipat sa conditional Container Registry sa Google Cloud) ... Gayunpaman , ang pag-alis ng naturang paghihigpit ay tila lohikal upang gawing mas maginhawa ang tool sa mas malawak na komunidad ng DevOps. Habang ipinapatupad ito, nakatagpo kami ng pangunahing kahirapan sa muling paggawa ng mekanismo ng paglilinis ng container registry. Ngayon na handa na ang lahat, nakakatuwang malaman na naging mas madali ito para sa isang tao, at kami (bilang pangunahing mga developer ng proyekto) ay hindi nakikita ang anumang kapansin-pansin na mga paghihirap sa karagdagang pagsuporta sa tampok na ito.

Manatili sa amin at sa lalong madaling panahon sasabihin namin sa iyo ang tungkol sa iba pang mga inobasyon sa werf!