🥇Mbështetje për Monorepo dhe multirepo në werf dhe çfarë lidhje ka Docker Registry me të

Tema e një monorepo është diskutuar shumë herë dhe, si rregull, shkakton debate mjaft aktive. werf Si një mjet me burim të hapur i projektuar për të përmirësuar procesin e ndërtimit të kodit të aplikacionit nga Git në imazhe Docker (dhe më pas dërgimin e tyre në Kubernetes), ne nuk shpenzojmë shumë kohë duke spekuluar se cila zgjedhje është më e mira. Shqetësimi ynë kryesor është të ofrojmë gjithçka të nevojshme për mbështetësit e mendimeve të ndryshme (për sa kohë që kjo nuk bie ndesh me logjikën e shëndoshë, sigurisht).

Mbështetja e shtuar së fundmi për mono-repo në werf është një shembull i mirë i kësaj. Por së pari, le të kuptojmë se si lidhet kjo mbështetje me përdorimin e werf dhe çfarë lidhje ka Docker Registry me të…

Çështjet

Le ta imagjinojmë këtë situatë. Një kompani ka disa ekipe zhvillimi që punojnë në projekte të pavarura. Shumica e aplikacioneve funksionojnë në Kubernetes dhe për këtë arsye janë të kontejnerizuara. Nevojitet një regjistër për të ruajtur kontejnerët dhe imazhet. Kompania përdor Docker Hub si regjistër të saj, me një llogari të vetme. COMPANYNgjashëm me shumicën e sistemeve të ruajtjes së kodit burimor, Docker Hub nuk lejon hierarkitë e depove të ndërthurura., siç është COMPANY/PROJECT/IMAGENë atë rast... si mund t'i ruajmë aplikacionet jo-monolitike në regjistër me këtë kufizim, pa krijuar një llogari të veçantë për secilin projekt?

Kjo situatë mund të jetë e njohur për disa, por le të shohim çështjen e organizimit të ruajtjes së aplikacioneve në përgjithësi, pa iu referuar shembullit të mësipërm dhe Docker Hub.

Zgjidhje

Nëse aplikimi në mënyrë monolitike, ofrohet në një imazh të vetëm, atëherë nuk lindin pyetje dhe ne thjesht i ruajmë imazhet në regjistrin e kontejnerëve të projektit.

Kur një aplikacion paraqitet si komponentë të shumtë, mikroshërbime, atëherë duhet të zgjidhet një qasje specifike. Duke përdorur shembullin e një aplikacioni tipik web që përbëhet nga dy imazhe: frontend и backend — opsionet e mundshme janë:

Ruani imazhet në depo të ndara të ndërthurura:
Ruaj gjithçka në një depo të vetme dhe përfshi emrin e imazhit në etiketë, për shembull, si kjo:

NBNë fakt, ekziston një tjetër mundësi me ruajtjen në depo të ndryshme, PROJECT-frontend и PROJECT-backend, por nuk do ta shqyrtojmë për shkak të kompleksitetit të mbështetjes, organizimit dhe shpërndarjes së të drejtave midis përdoruesve.

Mbështetje në werf

Fillimisht, werf e kufizoi veten në depo të ndërthurura—për fat të mirë, shumica e regjistrave e mbështesin këtë veçori. Duke filluar me versionin v1.0.4-alfa.3, shtoi punën me regjistrat në të cilat folezimi nuk mbështetet, dhe Docker Hub është një prej tyre. Që tani e tutje, përdoruesit kanë mundësi të zgjedhin se si t'i ruajnë imazhet e aplikacioneve.

Implementimi është i disponueshëm si opsion --images-repo-mode=multirepo|monorepo (sipas parazgjedhjes multirepo(p.sh., ruajtja në depo të ndërthurura). Ai përcakton shabllonet me anë të të cilave ruhen imazhet në regjistër. Thjesht zgjidhni modalitetin e dëshiruar kur përdorni komandat bazë dhe gjithçka tjetër do të mbetet e pandryshuar.

Meqenëse shumica e opsioneve të werf mund të vendosen variablat e mjedisitNë sistemet CI/CD, modaliteti i ruajtjes zakonisht është i lehtë për t'u vendosur globalisht për të gjithë projektin. Për shembull, në rastin e GitLab Mjafton të shtoni një ndryshore mjedisi në cilësimet e projektit: Cilësimet -> CI / CD -> Variablat: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Duke folur për publikimin e imazheve dhe lançimin e aplikacioneve (mund të lexoni në detaje rreth këtyre proceseve në artikujt përkatës të dokumentacionit: Procesi i publikimit и Procesi i vendosjes), atëherë modaliteti përcakton ekskluzivisht shabllonin me të cilin mund të punoni me imazhin.

Djalli është në detaje

Dallimi dhe vështirësia kryesore kur shtohet një metodë e re ruajtjeje është në procesin e pastrimit të regjistrit. (për aftësitë e pastrimit të mbështetura nga werf, shihni Procesi i pastrimit).

Gjatë pastrimit, werf merr në konsideratë imazhet e përdorura në klasteret Kubernetes, si dhe politikat e konfiguruara nga përdoruesi. Politikat bazohen në ndarjen e etiketave në strategji. Strategjitë e mbështetura aktualisht:

3 strategji që lidhen me primitivët e Git si tag, branch dhe commit;
1 strategji për etiketat e personalizuara.

Ne e ruajmë informacionin e strategjisë së etiketës kur publikojmë një imazh në etiketat e imazhit përfundimtar. Vlera në vetvete është e ashtuquajtura meta tag — është e nevojshme për zbatimin e disa politikave. Për shembull, kur fshihet një degë ose etiketë nga një depo Git, ka kuptim të fshihen edhe ato që lidhen me të. i papërdorur imazhe nga regjistri, i cili mbulohet nga një pjesë e politikave tona.

Kur ruani në një depo (monorepo), përveç meta-etiketës, etiketa e imazhit mund të ruajë edhe emrin e imazhit: PROJECT:frontend-META-TAGPër t'i ndarë ato, nuk prezantuam ndonjë ndarës specifik, por thjesht i shtuam vlerën e nevojshme etiketës përfundimtare të imazhit pas publikimit.

NBNëse jeni të interesuar të shikoni gjithçka që përshkruhet në kodin burimor të werf, atëherë një pikënisje mund të jetë PR 1684.

Në këtë artikull, nuk do t'i kushtojmë më shumë vëmendje problemeve dhe justifikimit të qasjes sonë: në lidhje me strategjitë e etiketimit, ruajtjen e të dhënave në etiketa dhe procesin e publikimit në përgjithësi - e gjithë kjo përshkruhet në detaje në një raport të kohëve të fundit nga Dmitry Stolyarov: "werf është mjeti ynë për CI/CD në Kubernetes'.

Për të përmbledhur

Mungesa e mbështetjes për regjistrat jo të ndërthurur nuk ishte një pengesë për ne ose për asnjë nga përdoruesit e werf që njohim - është gjithmonë e mundur të konfigurosh një regjistër të veçantë imazhesh (ose të kalosh në diçka si Regjistri i Kontejnerëve në Google Cloud). Megjithatë, heqja e këtij kufizimi dukej logjike për ta bërë mjetin më të përdorshëm nga komuniteti më i gjerë DevOps. Ndërsa e zbatonim atë, hasëm sfidën kryesore në ridizajnimin e mekanizmit të pastrimit të regjistrit të kontejnerëve. Tani që gjithçka është gati, është mirë të dish se gjërat janë bërë më të lehta për dikë, dhe ne (si zhvilluesit kryesorë të projektit) nuk parashikojmë ndonjë vështirësi të konsiderueshme në mbështetjen e mëtejshme të kësaj veçorie.

Qëndroni të lidhur dhe do t'ju tregojmë për risi të tjera në të ardhmen e afërt. werf!