Tema e monorepozitit është diskutuar disa herë dhe, zakonisht, shkakton debate mjaft aktiv. Duke krijuar si një mjet Open Source, i destinuar për të përmirësuar proceset e ndërtimit të kodit të aplikacioneve nga Git në imazhe Docker (dhe shpërndarjen e tyre të mëvonshme në Kubernetes), ne nuk mendojmë shumë për atë se cili është zgjedhja më e mirë. Për ne, është thelbësore të sigurojmë gjithçka të nevojshme për mbështetësit e mendimeve të ndryshme (nëse kjo nuk është në kundërshtim me shëndetin e arsyes, natyrisht).
MbĂ«shtetje e sapodalĂ« pĂ«r mono-repo nĂ« werf Ă«shtĂ« njĂ« shembull i mirĂ« pĂ«r kĂ«tĂ«. Por, pĂ«rpara se tĂ« fillojmĂ«, le tĂ« zbĂ«rthejmĂ« se si Ă«shtĂ« e lidhur kjo mbĂ«shtetje me pĂ«rdorimin e werf dhe çfarĂ« ka tĂ« bĂ«jĂ« kjo me Docker RegistryâŠ
Problematika
Imagjinoni një situatë të tillë. Në një kompani ka shumë grupe zhvilluesish që janë të angazhuar në projekte të pavarura. Shumica e aplikacioneve funksionojnë në Kubernetes dhe, për rrjedhojë, janë të kontejnerizuara. Për ruajtjen e kontejnerëve dhe imazheve, kërkohet një regjistër (registry). Si një regjistër të tillë, kompania përdor Docker Hub me një llogari të vetme COMPANY. Sipas analogjisë me shumicën e sistemeve të ruajtjes së kodit burimor, Docker Hub nuk lejon krijimin e një hierarkie të brendshme të regjistrave, si COMPANY/PROJECT/IMAGE. Në këtë rast⊠si të ruajmë aplikacionet jo-monolitike në regjistrin pa krijuar një llogari të veçantë për secilin projekt?
Ndoshta situata e përshkruar është e njohur për dikë, por le të shqyrtojmë çështjen e organizimit të ruajtjes së aplikacioneve në përgjithësi, pra pa lidhje me shembullin e përmendur më parë dhe Docker Hub.
Zgjidhjet
Nëse aplikacioni është monolitik, nuk ka pyetje dhe ne thjesht ruajmë imazhet në regjistrin e kontejnerëve të projektit.
Kur aplikacioni paraqitet nĂ« formĂ« tĂ« disa komponenteve, mikrosherbimesh, duhet tĂ« zgjidhet njĂ« qasje e caktuar. PĂ«r shembull, nĂ« njĂ« aplikacion tipik web, i pĂ«rbĂ«rĂ« nga dy imazhe: frontend dhe backend â mundĂ«sitĂ« janĂ« si mĂ« poshtĂ«:
- Të ruajmë imazhet në regjistra të brendshme të veçanta:
- Të ruajmë gjithçka në një regjistër, ndërsa emri i imazhit të merret parasysh në etiketë, për shembull, në këtë mënyrë:
NB: Në të vërtetë, ka një mundësi të tjera, duke ruajtur në regjistra të ndryshëm, PROJECT-frontend dhe PROJECT-backend, por nuk do ta shqyrtojmë atë për shkak të vështirësive në mbështetje, organizim dhe ndarje të drejtave ndërmjet përdoruesve.
Mbështetje në werf
Fillimisht werf u kufizua nĂ« regjistra tĂ« brendshĂ«m â fatmirĂ«sisht, shumica e regjistrave e mbĂ«shtesin njĂ« mundĂ«si tĂ« tillĂ«. Duke filluar nga versione , Ă«shtĂ« shtuar puna me regjistra nĂ« tĂ« cilat nuk mbĂ«shtetet brendĂ«sia, dhe Docker Hub Ă«shtĂ« nĂ« mesin e tyre. QĂ« nga ky moment, pĂ«rdoruesi ka pasur zgjedhjen se si tĂ« ruajĂ« imazhet e aplikacionit.
Zbatimi Ă«shtĂ« i disponueshĂ«m nĂ« kuadĂ«r tĂ« opsionit --images-repo-mode=multirepo|monorepo (ndonĂ«se, me parazgjedhje multirepo, pra ruajtja nĂ« regjistra tĂ« brendshĂ«m). Ky opsion pĂ«rcakton modelet me tĂ« cilat imazhet ruhen nĂ« regjistĂ«r. ĂshtĂ« e mjaftueshme tĂ« zgjidhni modin e duhur gjatĂ« pĂ«rdorimit tĂ« komandave kryesore, dhe e gjithĂ« e tjera do tĂ« mbetet e pandryshuar.
Duke qenë se shumica e opsioneve të werf mund të përcaktohen me variabla të mjedisit, në sistemet CI/CD, mënyra e ruajtjes zakonisht përcaktohet lehtësisht globalisht për të gjithë projektin. Për shembull, në rastin e GitLab mjafton të shtoni një variabël mjedisi në cilësimet e projektit: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Nëse flasim për publikimin e imazheve dhe të aplikacioneve (për këto procese mund të lexoni më shumë në artikujt përkatës në dokumentacion: dhe ), atëherë mënyra përcakton vetëm modelin me të cilin mund të punoni me imazhin.
Djalli është në detaje
Dallimi dhe vĂ«shtirĂ«sia kryesore nĂ« shtimin e njĂ« mĂ«nyre tĂ« re ruajtjeje â nĂ« procesin e pastrimit tĂ« regjistrit (mundĂ«sitĂ« e pastrimit, tĂ« mbĂ«shtetura nĂ« werf, shih nĂ« ).
Gjatë pastrimit, werf merr parasysh imazhet që përdoren në klasterët Kubernetes, si dhe politikat e përcaktuara nga përdoruesi. Në thelb, politikat i nënshtrohen ndarjes së etiketave në strategji. Strategjitë aktualisht të mbështetura janë:
- 3 strategji të lidhura me primitivat Git, si etiketa, dega dhe commit;
- 1 strategji për etiketa të rastësishme të përdoruesve.
Informacionin mbi strategjinĂ« e etiketĂ«s e ruajmĂ« gjatĂ« publikimit tĂ« imazhit nĂ« etiketat e imazhit pĂ«rfundimtar. Vlera vetĂ« â e quajtur metaetiketĂ« â Ă«shtĂ« e nevojshme pĂ«r zbatimin e disa pjesĂ«ve tĂ« politikave. PĂ«r shembull, kur hiqet njĂ« degĂ« ose etiketĂ« nga regjistri Git, Ă«shtĂ« logjike tĂ« hiqen dhe imazhet e lidhura nga regjistri qĂ« nuk pĂ«rdoren, dhe kjo mb coveredhet nga pjesa e politikave tanĂ«.
Kur ruhen nĂ« njĂ« regjistĂ«r (monorepo), nĂ« etiketĂ«n e imazhit, pĂ«rveç metaetiketĂ«s, mund tĂ« ruhet edhe emri i imazhit: PROJEKTI:frontend-META-TAG. PĂ«r tâi ndarĂ« ato, ne nuk vendosĂ«m ndonjĂ« ndarĂ«s specifik, por thjesht e shtuam vlerĂ«n e nevojshme nĂ« etiketĂ«n e imazhit pĂ«rfundimtar gjatĂ« publikimit.
NB: Nëse jeni të interesuar të shihni gjithçka të përshkruar në kodin burimor të werf, pika e nisjes mund të jetë .
NĂ« kĂ«tĂ« artikull nuk do t'i kushtojmĂ« mĂ« shumĂ« vĂ«mendje problematikĂ«s dhe arsyetimit tĂ« qasjes sonĂ«: mbi strategjitĂ« e etiketimit, ruajtjes sĂ« tĂ« dhĂ«nave nĂ« etiketa dhe procesit tĂ« publikimit nĂ« tĂ«rĂ«si â mbi kĂ«tĂ« Ă«shtĂ« folur nĂ« hollĂ«si nĂ« raportin e fundit tĂ« Dmitrij Stolyarov: "».
PĂ«rmbledhur
Mungesa e mbĂ«shtetjes pĂ«r regjistrat pa hierarki nuk ishte njĂ« faktor bllokues pĂ«r ne ose pĂ«rdoruesit e njohur tĂ« werf â sepse gjithmonĂ« Ă«shtĂ« e mundur tĂ« ngritni njĂ« regjistĂ«r tĂ« veçantĂ« imazhesh (ose tĂ« kaloni nĂ« regjistrin e kushteve tĂ« Container Registry nĂ« Google Cloud)⊠MegjithatĂ«, heqja e njĂ« kufizimi tĂ« tillĂ« dukej e arsyeshme nĂ« mĂ«nyrĂ« qĂ« mjeti tĂ« ishte mĂ« i pĂ«rshtatshĂ«m pĂ«r njĂ« komunitet mĂ« tĂ« gjerĂ« tĂ« DevOps. Duke e realizuar atĂ«, u pĂ«rballĂ«m me vĂ«shtirĂ«sinĂ« kryesore nĂ« pĂ«rpunimin e mekanizmit tĂ« pastrimit tĂ« regjistrit tĂ« kontejnerĂ«ve. Tani, kur gjithçka Ă«shtĂ« gati, Ă«shtĂ« kĂ«naqĂ«si tĂ« kuptojmĂ« se dikujt i Ă«shtĂ« bĂ«rĂ« mĂ« e lehtĂ«, dhe ne (si zhvilluesit kryesorĂ« tĂ« projektit) nuk parashikojmĂ« vĂ«shtirĂ«si tĂ« dukshme nĂ« mbĂ«shtetje tĂ« mĂ«tejshme tĂ« kĂ«saj funksionaliteti.
Qëndroni me ne dhe shumë shpejt do t'ju tregojmë për risitë e tjera në !
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «».
Burimi: habr.com
