Tema mono-repozitorija je bila obravnavana že večkrat in praviloma povzroča zelo aktivno polemiko. Z ustvarjanjem kot odprtokodno orodje, zasnovano za izboljšanje postopka gradnje aplikacijske kode iz Git v slike Docker (in nato njihove dostave v Kubernetes), ne razmišljamo veliko o tem, katera izbira je najboljša. Za nas je primarno zagotoviti vse potrebno za zagovornike drugačnih mnenj (če to seveda ni v nasprotju z zdravo pametjo).
werfova nedavna podpora mono-repo je dober primer tega. Najprej pa ugotovimo, kako je ta podpora na splošno povezana z uporabo werf in kaj ima s tem opraviti register Docker ...
Problematično
Predstavljajmo si takšno situacijo. Podjetje ima veliko razvojnih ekip, ki delajo na samostojnih projektih. Večina aplikacij deluje na Kubernetesu in so zato zaprte. Za shranjevanje vsebnikov, slik potrebujete register (register). Kot tak register podjetje uporablja Docker Hub z enim samim računom COMPANY. Podobno kot večina sistemov za shranjevanje izvorne kode, Docker Hub ne dovoljuje hierarhije ugnezdenih skladišč, kot naprimer COMPANY/PROJECT/IMAGE. V tem primeru ... kako lahko s to omejitvijo shranite nemonolitne aplikacije v register, ne da bi ustvarili ločen račun za vsak projekt?
Morda je opisana situacija komu znana iz prve roke, vendar razmislimo o vprašanju organizacije shranjevanja aplikacij na splošno, tj. brez sklicevanja na zgornji primer in Docker Hub.
Rešitve
Če je aplikacija monolitna, pride v eni sliki, potem ni vprašanj in slike preprosto shranimo v register vsebnikov projekta.
Ko je aplikacija predstavljena kot več komponent, mikrostoritve, potem je potreben določen pristop. Na primeru tipične spletne aplikacije, sestavljene iz dveh slik: frontend и backend - možne možnosti so:
- Shranjujte slike v ločenih ugnezdenih repozitorijih:
- Shranite vse v eno skladišče in upoštevajte ime slike v oznaki, na primer, kot sledi:
NB: Pravzaprav obstaja še ena možnost s shranjevanjem v različnih skladiščih, PROJECT-frontend и PROJECT-backend, vendar ga ne bomo upoštevali zaradi zahtevnosti podpore, organizacije in razdelitve pravic med uporabniki.
podpora werf
Sprva se je werf omejil na ugnezdene repozitorije - na srečo večina registrov podpira to funkcijo. Začenši z različico , dodano delo z registri, v katerih gnezdenje ni podprto, in Docker Hub je eden izmed njih. Od te točke naprej lahko uporabnik izbira, kako shraniti slike aplikacije.
Izvedba na voljo po izbiri --images-repo-mode=multirepo|monorepo (privzeto multirepo, tj. shranjevanje v ugnezdenih repozitorijih). Določa vzorce, po katerih so slike shranjene v registru. Dovolj je, da pri uporabi osnovnih ukazov izberete želeni način, vse ostalo pa ostane nespremenjeno.
Ker je večino možnosti werf mogoče nastaviti spremenljivke okolja, v sistemih CI/CD je način shranjevanja običajno enostavno globalno nastaviti za celoten projekt. na primer v primeru GitLaba samo dodajte spremenljivko okolja v nastavitve projekta: Nastavitve -> CI / CD -> Spremenljivke: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Če govorimo o objavljanju slik in uvajanju aplikacij (o teh postopkih lahko podrobneje preberete v ustreznih dokumentacijskih člankih: и ), potem način samo določa predlogo, po kateri lahko delate s sliko.
Hudič je v podrobnostih
Razlika in glavna težava pri dodajanju novega načina shranjevanja je v procesu čiščenja registra (za funkcije čiščenja, ki jih podpira werf, glejte ).
Pri čiščenju werf upošteva slike, uporabljene v gručah Kubernetes, kot tudi pravilnike, ki jih konfigurira uporabnik. Politike temeljijo na delitvi oznak na strategije. Trenutno podprte strategije:
- 3 strategije, povezane s primitivi Git, kot so tag, veja in commit;
- 1 strategija za poljubne oznake po meri.
Podatke o strategiji oznake ob objavi slike shranimo v oznake končne slike. Sam pomen je t.i meta oznaka - Zahtevano za uporabo nekaterih pravilnikov. Na primer, ko brišete vejo ali oznako iz repozitorija Git, je logično, da izbrišete povezano neuporabljeno slike iz registra, kar je zajeto v delih naših pravilnikov.
Ko je shranjen v enem repozitoriju (monorepo), v oznaki slike je poleg meta oznake lahko shranjeno tudi ime slike: PROJECT:frontend-META-TAG. Da bi jih ločili, nismo uvedli nobenega posebnega ločila, temveč smo oznaki končne slike ob objavi le dodali potrebno vrednost.
NB: Če vas zanima vse, kar je opisano v izvorni kodi werf, je lahko izhodišče .
V tem članku ne bomo več pozornosti posvečali težavam in utemeljitvi našega pristopa: o strategijah označevanja, shranjevanju podatkov v nalepkah in procesu objavljanja kot celoti - vse to je podrobno opisano v nedavnem poročilu Dmitrija Stolyarova: “".
Povzemanje
Pomanjkanje podpore za neugnezdene registre ni bil dejavnik blokiranja za nas ali nam znane uporabnike werf - navsezadnje lahko vedno ustvarite ločen register slik (ali preklopite na pogojni register vsebnikov v Google Cloud) ... Vendar pa odprava takšne omejitve se je zdela logična, da bi bilo orodje bolj priročno za širšo skupnost DevOps. Med njegovo implementacijo smo se soočili z glavno težavo pri predelavi mehanizma čiščenja registra vsebnika. Zdaj, ko je vse pripravljeno, je lepo ugotoviti, da je nekomu postalo lažje, mi (kot glavni razvijalci projekta) pa ne bomo imeli opaznih težav pri nadaljnji podpori te funkcije.
Ostanite z nami in kmalu vam bomo povedali o drugih novostih v !
PS
Preberite tudi na našem blogu:
- «»;
- «".
Vir: www.habr.com