Mono saugyklos tema buvo aptarta ne kartą ir, kaip taisyklė, sukelia labai aktyvius ginčus. Kurdamas kaip atvirojo kodo įrankis, sukurtas tobulinti programos kodo kūrimo iš „Git“ į „Docker“ vaizdų procesą (o paskui juos pristatyti į „Kubernetes“), mes daug negalvojame, kuris pasirinkimas yra geriausias. Mums svarbiausia suteikti viską, ko reikia skirtingų nuomonių šalininkams (jei tai, žinoma, neprieštarauja sveikam protui).
Geras to pavyzdys yra neseniai suteikta werf mono-repo parama. Bet pirmiausia išsiaiškinkime, kaip šis palaikymas apskritai yra susijęs su werf naudojimu ir ką su juo turi „Docker“ registras ...
Problemos
Įsivaizduokime tokią situaciją. Įmonėje dirba daug vystymo komandų, dirbančių su nepriklausomais projektais. Dauguma programų veikia Kubernetes, todėl yra konteineriuose. Norėdami saugoti konteinerius, vaizdus, reikia registro (registro). Bendrovė naudoja „Docker Hub“ kaip tokį registrą su viena paskyra COMPANY. Panašiai kaip daugumoje šaltinio kodo saugojimo sistemų, „Docker Hub“ neleidžia įdėtos saugyklos hierarchijos, toks kaip COMPANY/PROJECT/IMAGE. Tokiu atveju... kaip galite saugoti nemonolitines programas registre su šiuo apribojimu, nesukūrę atskiros paskyros kiekvienam projektui?
Galbūt aprašyta situacija kažkam pažįstama iš pirmų lūpų, bet panagrinėkime aplikacijų saugyklos organizavimo klausimą apskritai, t.y. be nuorodos į aukščiau pateiktą pavyzdį ir „Docker Hub“.
Sprendimai
Jei paraiška monolitinis, ateina viename paveikslėlyje, tada klausimų nekyla ir vaizdus tiesiog išsaugome projekto konteinerio registre.
Kai programa pateikiama kaip keli komponentai, mikropaslaugos, tada reikalingas tam tikras požiūris. Įprastos žiniatinklio programos, kurią sudaro du vaizdai, pavyzdys: frontend и backend - galimi variantai:
- Saugokite vaizdus atskirose įdėtose saugyklose:
- Išsaugokite viską vienoje saugykloje ir apsvarstykite vaizdo pavadinimą žymoje, pavyzdžiui, taip:
NB: Tiesą sakant, yra dar viena galimybė išsaugoti įvairiose saugyklose, PROJECT-frontend и PROJECT-backend, tačiau mes to nesvarstysime dėl sudėtingo palaikymo, organizavimo ir teisių paskirstymo tarp vartotojų.
werf palaikymas
Iš pradžių werf apsiribojo įdėtomis saugyklomis – laimei, dauguma registrų palaiko šią funkciją. Pradedant nuo versijos , pridėtas darbas su registrais, kuriuose lizdas nepalaikomas, ir Docker Hub yra vienas iš jų. Nuo to momento vartotojas gali pasirinkti, kaip išsaugoti programos vaizdus.
Įgyvendinimas galimas pagal pasirinktį --images-repo-mode=multirepo|monorepo (numatytas multirepo, t.y. saugojimas įdėtose saugyklose). Jis apibrėžia šablonus, pagal kuriuos vaizdai saugomi registre. Pakanka pasirinkti norimą režimą naudojant pagrindines komandas, o visa kita liks nepakitusi.
Kadangi daugumą werf parinkčių galima nustatyti aplinkos įvairovėCI / CD sistemose saugojimo režimą paprastai lengva nustatyti visame pasaulyje visam projektui. Pavyzdžiui, GitLab atveju tiesiog pridėkite aplinkos kintamąjį projekto nustatymuose: Nustatymai -> CI / CD -> Kintamieji: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Jei kalbame apie vaizdų publikavimą ir programų diegimą (apie šiuos procesus galite perskaityti išsamiai atitinkamuose dokumentacijos straipsniuose: и ), tada režimas nustato tik šabloną, pagal kurį galite dirbti su vaizdu.
Velnias slypi detalėse
Skirtumas ir pagrindinis sunkumas pridedant naują saugojimo metodą yra registro valymo procesas (Dėl werf palaikomų valymo funkcijų žr ).
Valydama werf atsižvelgia į vaizdus, naudojamus Kubernetes klasteriuose, taip pat į vartotojo sukonfigūruotą politiką. Politika grindžiama žymų padalijimu į strategijas. Šiuo metu palaikomos strategijos:
- 3 strategijos, susietos su Git primityvais, tokiais kaip žyma, šaka ir įsipareigojimas;
- 1 savavališkų tinkintų žymų strategija.
Informaciją apie žymėjimo strategiją išsaugome publikuodami vaizdą galutinio vaizdo etiketėse. Pati prasmė yra vadinamoji meta žyma – Būtina taikyti kai kurias taisykles. Pavyzdžiui, ištrinant šaką ar žymą iš Git saugyklos, logiška ištrinti susijusius nenaudotas vaizdai iš registro, kuriems taikoma dalis mūsų politikos.
Išsaugojus vienoje saugykloje (monorepo), vaizdo žymoje, be metažymos, taip pat gali būti išsaugotas vaizdo pavadinimas: PROJECT:frontend-META-TAG. Norėdami juos atskirti, neįvedėme jokio konkretaus skyriklio, o publikuodami tiesiog pridėjome reikiamą reikšmę galutinio vaizdo etiketėje.
NB: Jei jums įdomu pažvelgti į viską, kas aprašyta werf šaltinio kode, tada išeities taškas gali būti .
Šiame straipsnyje mes nekreipsime daugiau dėmesio į problemas ir savo požiūrio pagrindimą: apie žymėjimo strategijas, duomenų saugojimą etiketėse ir visą publikavimo procesą - visa tai išsamiai aprašyta neseniai paskelbtoje Dmitrijaus Stolyarovo ataskaitoje: “".
Apibendrinti
Neįdėtų registrų palaikymo trūkumas nebuvo blokuojantis veiksnys nei mums, nei mums žinomiems „werf“ naudotojams – juk visada galite sukurti atskirą vaizdų registrą (arba „Google Cloud“ perjungti į sąlyginį konteinerių registrą)... Tačiau, tokio apribojimo panaikinimas atrodė logiškas, kad įrankis būtų patogesnis platesnei DevOps bendruomenei. Ją įgyvendindami susidūrėme su pagrindiniu sunkumu pertvarkant konteinerio registro valymo mechanizmą. Dabar, kai viskas paruošta, smagu suprasti, kad kažkam pasidarė lengviau, o mes (kaip pagrindiniai projekto kūrėjai) neturėsime jokių pastebimų sunkumų toliau palaikydami šią funkciją.
Likite su mumis ir labai greitai papasakosime apie kitas naujoves !
PS
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «".
Šaltinis: www.habr.com