Tema e monorepositorit është diskutuar disa herë tashmë dhe, si rregull, shkakton debate të forta. 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 dërgimin e mëvonshëm në Kubernetes), ne nuk mendojmë shumë për atë se cilat janë zgjedhjet më të mira. 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, sigurisht).
MbĂ«shtetje e re pĂ«r mono-repo nĂ« werf â njĂ« shembull i mirĂ« i kĂ«saj. Por sĂ« pari, le tĂ« kuptojmĂ« si Ă«shtĂ« kjo mbĂ«shtetje e lidhur me pĂ«rdorimin e werf dhe çfarĂ« ka tĂ« bĂ«jĂ« kĂ«tu me Docker RegistryâŠ
Problematika
Imagjinoni njĂ« situatĂ« tĂ« tillĂ«. NĂ« njĂ« kompani ka shumĂ« ekipe zhvilluesish qĂ« punojnĂ« nĂ« projekte tĂ« pavarura. Shumica e aplikacioneve funksionojnĂ« nĂ« Kubernetes, dhe pĂ«r rrjedhojĂ« â janĂ« tĂ« kontejnerizuar. PĂ«r ruajtjen e kontejnerĂ«ve, imazheve, nevojitet njĂ« regjistĂ«r (registry). Si njĂ« regjistĂ«r tĂ« tillĂ«, kompania pĂ«rdor Docker Hub me njĂ« llogari tĂ« vetme KOMPANIA. NĂ« pĂ«rputhje me shumicĂ«n e sistemeve tĂ« ruajtjes sĂ« kodit burimor, Docker Hub nuk lejon krijimin e njĂ« hierarkie tĂ« brendshme tĂ« regjistrave, siç Ă«shtĂ« KOMPANIA/PROJEKTI/IMAZHI. NĂ« kĂ«tĂ« rast⊠si mund tĂ« ruajmĂ« nĂ« regjistrin aplikacione jo monolitike pa krijuar njĂ« llogari tĂ« veçantĂ« pĂ«r çdo projekt?
Ndoshta situata e përshkruar nuk është e panjohur për disa, por le të shqyrtojmë çështjen e organizimit të ruajtjes së aplikacioneve në përgjithësi, dmth pa lidhje me shembullin e sipër përmendur dhe Docker Hub.
MĂ«nyrat e zgjidhjes
Nëse aplikacioni është monolitik, i ardhur në një imazh, nuk ka pyetje dhe ne thjesht ruajmë imazhet në regjistrin e kontejnerëve të projektit.
Kur aplikacioni paraqitet nĂ« formĂ«n e disa komponentĂ«ve, mikroshĂ«rbimeve, atĂ«herĂ« duhet tĂ« zgjidhet njĂ« qasje e caktuar. Me shembullin e njĂ« aplikacioni tipik web, i pĂ«rbĂ«rĂ« nga dy imazhe: frontend dhe backend â mundĂ«sitĂ« janĂ« tĂ« tilla:
- Të ruajmë imazhet në regjistra të veçantë të brendshëm:
- Të ruajmë gjithçka në një regjistër, dhe emri i imazhit të merret parasysh në etiketë, p.sh., në këtë mënyrë:
NB: Në të vërtetë, ka edhe një opsion tjetër me ruajtjen në regjistra të ndryshme, PROJEKTI-frontend dhe PROJEKTI-backend, por ne nuk do ta shqyrtojmë atë për shkak të kompleksitetit të mbështetjes, organizimit dhe shpërndarjes së të drejtave për përdoruesit.
Mbështetje në werf
NĂ« fillim, werf u kufizua me depozita tĂ« ngulitura â ngushĂ«llimi Ă«shtĂ« se shumica e regjistrave mbĂ«shtesin njĂ« mundĂ«si tĂ« tillĂ«. Duke filluar nga versioni , Ă«shtĂ« shtuar puna me regjistrat ku nuk mbĂ«shtetet ngulitja, dhe Docker Hub â nĂ« mesin e tyre. QĂ« nga atĂ«herĂ«, pĂ«rdoruesi ka pasur zgjedhjen se si tĂ« ruajĂ« pamjet e aplikacionit.
Implementimi është i disponueshëm në kuadër të opsionit --images-repo-mode=multirepo|monorepo (me të drejtë multirepo, dmth. ruajtja në depozita të ngulitura). Ajo përcakton modelet sipas të cilave pamjet ruhen në regjistër. Mjafton të zgjidhni modin e duhur gjatë përdorimit të komandave kryesore, dhe gjithçka tjetër do të mbesë e pandryshuar.
Pasi shumica e mundësive të werf mund të caktohen me variabla ambienti, në sistemet CI/CD, modaliteti i ruajtjes, për zakon, lehtë mund të caktohet globalisht për të gjithë projektin. Për shembull, në rastin e GitLab , mjafton të shtoni një variabël ambienti në cilësimet e projektit: Cilësimet -> CI / CD -> Variablat: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Nëse flasim për publikimin e pamjeve dhe deploy-in e aplikacioneve (për këto procese mund të lexoni në detaje në artikujt përkatës të dokumentacionit: dhe ), atëherë modaliteti përcakton ekskluzivisht modelin sipas të cilit mund të punoni me pamjen.
Demon në detaje
Dallimi dhe vĂ«shtirĂ«sia kryesore nĂ« shtimin e njĂ« mĂ«nyre tĂ« re ruajtjeje â Ă«shtĂ« nĂ« procesin e pastrimit tĂ« regjistrit (mundĂ«sitĂ« e pastrimit, tĂ« mbĂ«shtetura nĂ« werf, shihni nĂ« ).
Kur pastron, werf merr parasysh pamjet e përdorura në klasterët Kubernetes, si dhe politikat e konfiguruara nga përdoruesi. Në thelb të politikave është ndarja e etiketave në strategji. Strategjitë, të mbështetura në këtë moment:
- 3 strategji që lidhen me primitivët Git, si etiket, degë dhe të bëjë commit;
- 1 strategji për etiketat e rastësishme të përdoruesit.
Informacionin mbi strategjinĂ« e etiketĂ«s e ruajmĂ« gjatĂ« publikimit tĂ« pamjes nĂ« etiketat e pamjes pĂ«rfundimtare. Vlera vetĂ« â e ashtuquajtura meta-etiketĂ« â Ă«shtĂ« e nevojshme pĂ«r zbatimin e disa politikave. PĂ«r shembull, kur hiqet njĂ« degĂ« ose etiketĂ« nga depoja Git, Ă«shtĂ« logjike tĂ« hiqen gjithashtu pamjet qĂ« nuk pĂ«rdoren nga regjistri, qĂ« mbulohet nga disa nga politikat tona.
Kur ruhet në një regjistër të vetëm (monorepo), në etiketën e pamjes, përveç meta-etiketës gjithashtu mund të ruhet emri i pamjes: PROJEKTI:frontend-META-ETIKETA. Për t'i ndarë, nuk kemi përdorur ndonjë ndarës specifik, por thjesht kemi shtuar vlerën e nevojshme në etiketën e images përfundimtare gjatë publikimit.
NB: Nëse dëshiron të shohësh gjithçka të përshkruar në kodin burimor të werf, atëherë pika e nisjes mund të jetë .
NĂ« kĂ«tĂ« artikull nuk do t'i japim mĂ« shumĂ« vĂ«mendje problematikĂ«s dhe arsyetimit tĂ« qasjes sonĂ«: pĂ«r strategjitĂ« e etiketimit, ruajtjen e tĂ« dhĂ«nave nĂ« etiketa dhe procesin e publikimit nĂ« pĂ«rgjithĂ«si â pĂ«r gjithçka Ă«shtĂ« biseduar nĂ« detaje nĂ« raportin e fundit nga Dmitry Stolyarov: "».
PĂ«rmbledhje
Mungesa e mbĂ«shtetjes pĂ«r regjistrat pa hierarki nuk ishte njĂ« faktor pengues pĂ«r ne ose pĂ«rdoruesit e njohur tĂ« werf â sepse gjithmonĂ« mund tĂ« ngrish njĂ« regjistĂ«r tĂ« veçantĂ« tĂ« imazheve (ose tĂ« kalosh nĂ« regjistrin e kushteve nĂ« Google Cloud)... MegjithatĂ«, heqja e njĂ« kufizimi tĂ« tillĂ« dukej logjike qĂ« mjeti tĂ« ishte mĂ« i pĂ«rshtatshĂ«m pĂ«r njĂ« komunitet mĂ« tĂ« gjerĂ« tĂ« DevOps. GjatĂ« realizimit tĂ« saj, ne u pĂ«rballĂ«m me vĂ«shtirĂ«sinĂ« kryesore nĂ« rishikimin e mekanizmit tĂ« pastrimit tĂ« regjistrit tĂ« konteinerĂ«ve. Tani qĂ« gjithçka Ă«shtĂ« gati, Ă«shtĂ« mirĂ« tĂ« dish 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Ă« kĂ«saj veçorie.
Qëndroni me ne dhe shumë shpejt do t'ju njoftojmë për risitë e tjera në !
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «».
Burimi: habr.com
