Tema e një monorepozitori është diskutuar më shumë se një herë dhe, si rregull, shkakton debat shumë aktiv. Duke krijuar Si një mjet me burim të hapur i krijuar për të përmirësuar procesin e krijimit të kodit të aplikacionit nga Git në imazhet e Docker (dhe më pas dërgimin e tyre në Kubernetes), ne nuk mendojmë shumë se cila zgjedhje është më e mira. Për ne është parësore të ofrojmë gjithçka të nevojshme për mbështetësit e mendimeve të ndryshme (nëse kjo nuk bie ndesh me sensin e shëndoshë, natyrisht).
Mbështetja e prezantuar së fundmi për mono-repo në werf është një shembull i mirë për këtë. Por së pari, le të kuptojmë se si kjo mbështetje lidhet përgjithësisht me përdorimin e werf dhe çfarë lidhje ka Docker Registry me të...
Çështjet
Le ta imagjinojmë këtë situatë. Kompania ka shumë ekipe zhvillimi që punojnë në projekte të pavarura. Shumica e aplikacioneve funksionojnë në Kubernetes dhe, në përputhje me rrethanat, janë kontejnerizuar. Për të ruajtur kontejnerët dhe imazhet, kërkohet një regjistër. Kompania përdor Docker Hub me një llogari të vetme si një regjistër të tillë. COMPANY. Ngjashëm me shumicën e sistemeve të ruajtjes së kodit burimor, Docker Hub nuk ju lejon të krijoni një hierarki të mbivendosur të depove, si p.sh COMPANY/PROJECT/IMAGE. Në këtë 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 çdo projekt?
Ndoshta situata e përshkruar është e njohur për dikë nga dora e parë, por le të shohim çështjen e organizimit të ruajtjes së aplikacioneve në përgjithësi, d.m.th. pa iu referuar shembullit të mësipërm dhe Docker Hub.
Zgjidhjet
Nëse aplikimi në mënyrë monolitike, vjen në një imazh, atëherë nuk lindin asnjë 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ë zgjidhni një qasje të caktuar. Duke përdorur shembullin e një aplikacioni tipik në internet të përbërë nga dy imazhe: frontend и backend - Opsionet e mundshme janë:
- Ruani imazhet në depo të veçanta të mbivendosur:
- Ruani gjithçka në një depo dhe përfshini emrin e imazhit në etiketë, për shembull, si më poshtë:
NB: Në fakt, ekziston një mundësi tjetër me ruajtjen në depo të ndryshme, PROJECT-frontend и PROJECT-backend, por ne nuk do ta konsiderojmë atë për shkak të kompleksitetit të mbështetjes, organizimit dhe shpërndarjes së të drejtave midis përdoruesve.
mbështjetja e werf
Fillimisht, werf ishte i kufizuar në depo të mbivendosur - për fat të mirë, shumica e regjistrave e mbështesin këtë veçori. Që nga versioni , shtoi punën me regjistrat në të cilat foleja nuk mbështetet, dhe Docker Hub është një prej tyre. Që nga ky moment, përdoruesi kishte një zgjedhje se si të ruante imazhet e aplikacionit.
Zbatimi i disponueshëm si pjesë e opsionit --images-repo-mode=multirepo|monorepo (e parazgjedhur multirepo, d.m.th. ruajtja në depo të mbivendosur). Ai përcakton modelet me të cilat imazhet ruhen në regjistër. Mjafton të zgjidhni mënyrën 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 mjedisit, në sistemet CI/CD, mënyra e ruajtjes zakonisht është e lehtë për t'u vendosur globalisht për të gjithë projektin. Për shembull, në rastin e GitLab Thjesht shtoni një variabël mjedisi në cilësimet e projektit: Cilësimet -> CI / CD -> Variablat: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Nëse flasim për publikimin e imazheve dhe paraqitjen e aplikacioneve (mund të lexoni në lidhje me këto procese në detaje në artikujt përkatës të dokumentacionit: и ), atëherë mënyra përcakton vetëm shabllonin me të cilin mund të punoni me imazhin.
Djalli është në detaje
Dallimi dhe vështirësia kryesore kur shtoni një metodë të re të ruajtjes është në procesin e pastrimit të regjistrit (veçoritë e pastrimit të mbështetura në werf, shih ).
Kur pastron, werf merr parasysh imazhet e përdorura në grupimet Kubernetes, si dhe politikat e konfiguruara nga përdoruesit. Politikat bazohen në ndarjen e etiketave në strategji. Strategjitë e mbështetura aktualisht:
- 3 strategji që lidhen me primitivet Git si tag, degëzimi dhe commit;
- 1 strategji për etiketat e personalizuara.
Ne ruajmë informacionin në lidhje me strategjinë e etiketave kur publikojmë imazhin në etiketat e imazhit përfundimtar. Vetë kuptimi është i ashtuquajturi meta etiketë — e nevojshme për zbatimin e disa politikave. Për shembull, kur fshini një degë ose etiketë nga një depo Git, është logjike të fshini të lidhur të papërdorura imazhe nga regjistri, i cili mbulohet nga një pjesë e politikave tona.
Kur ruani në një depo (monorepo), në etiketën e imazhit, përveç meta etiketës, mund të ruhet edhe emri i figurës: PROJECT:frontend-META-TAG. Për t'i ndarë ato, ne nuk futëm ndonjë ndarës specifik, por thjesht i shtuam vlerën e nevojshme etiketës së imazhit përfundimtar gjatë publikimit.
NB: Nëse jeni të interesuar të shikoni gjithçka që përshkruhet në kodin burimor werf, atëherë pika fillestare mund të jetë .
Në këtë artikull ne nuk do t'i kushtojmë më shumë vëmendje problemeve dhe arsyetimit 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ë raportin e fundit nga Dmitry Stolyarov: "'.
Për të përmbledhur
Mungesa e mbështetjes për regjistrat pa fole nuk ishte një faktor bllokues për ne ose përdoruesit e Werf të njohur për ne - në fund të fundit, gjithmonë mund të krijoni një regjistër të veçantë të imazheve (ose të kaloni në Regjistrin e kushtëzuar të kontejnerëve në Google Cloud) ... Megjithatë , heqja e një kufizimi të tillë dukej logjike për ta bërë mjetin më të përshtatshëm për komunitetin më të gjerë DevOps. Gjatë zbatimit të tij, ne hasëm vështirësinë kryesore në ripërpunimin e mekanizmit të pastrimit të regjistrit të kontejnerëve. Tani që gjithçka është gati, është mirë të dini se është bërë më e lehtë për dikë dhe ne (si zhvilluesit kryesorë të projektit) nuk parashikojmë ndonjë vështirësi të dukshme në mbështetjen e mëtejshme të kësaj veçorie.
Qëndroni me ne dhe shumë shpejt do t'ju tregojmë për risitë e tjera në !
PS
Lexoni edhe në blogun tonë:
- «"?
- «'.
Burimi: www.habr.com