🥇Monorepo ja multirepo toetamine werfis ja kuidas see seondub Docker Registry'ga

Monorepo teema on juba korduvalt arutatud ja tavaliselt tekitab see üsna aktiivset diskussiooni. Luues werf avatud lähtekoodiga tööriista, mille eesmärk on parandada rakenduste koodi koostamise protsessi Gitist Docker piltide (ja nende edasise tarnimise Kubernetesesse), mõtleme me vähe, milline valik on parem. Meie jaoks on esmatähtis tagada kõik vajalik erinevate arvamuste toetajatele (kui see ei lähe vastuollu terve mõistusega, muidugi).

Hiljuti ilmunud tugi mono-repole werf'is on hea näide sellest. Kuid esiteks uurime, kuidas see tugi üldse on seotud werf'i kasutamisega ja mis on seos Docker Registryga ...

Problemaatika

Kujutage ette olukorda. Ettevõttes on mitmeid arendustiime, kes tegelevad iseseisvate projektidega. Enamik rakendusi töötab Kuberneteses ja seega – on konteineritud. Konteinerite ja piltide salvestamiseks on vajalik register. Sellise registrina kasutab ettevõte Docker Hub'i ühe abonendiga ETTEVÕTE. Sarnaselt enamikule lähtekoodi salvestamise süsteemidele, Docker Hub ei luba luua hierarhilisi registrite struktuure, nagu näiteks ETTEVÕTE/PROJEKT/IMAGE. Sellisel juhul ... kuidas salvestada registris mitte-monoliitseid rakendusi, luues iga projekti jaoks eraldi konto?

Võimalik, et kirjeldatud olukord on kellegi jaoks tuttav, kuid vaatame küsimust rakenduste salvestamise korralduse üle üldiselt, st ilma seoseta eespool kirjeldatud näite ja Docker Hub'iga.

Lahenduste teed

Kui rakendus on monoliitne, siis probleeme ei teki ja me lihtsalt salvestame pildid projekti konteinerite registrisse.

Kui rakendus on esitatud mitme komponendina, Mikroteenused, siis tuleb valida kindel lähenemine. Näiteks tüüpilise veebirakenduse puhul, mis koosneb kahest pildist: frontend ja backend — võimalused on järgmised:

Salvestada pildid eraldi sissepääsudega registrites:
Salvestada kõik ühte registrisse ja arvestada pildi nimega märgises, näiteks järgmiselt:

NB: Tegelikult on veel variant pidada erinevates registrites, PROJEKT-frontend ja PROJEKT-backend, kuid seda me ei käsitle keerukuse tõttu toetamisel, korraldamisel ja õiguste jagamisel kasutajate vahel.

Tugi werf'is

Esialgu piirdus werf siserepositooriumidega — õnneks toetab enamik registreid seda võimalust. Alates versioonist v1.0.4-alpha.3, on lisatud tugi registritele, kus sisemine tugi ei ole saadaval, sealhulgas Docker Hub. Sellest hetkest alates on kasutajal võimalus valida, kuidas rakenduste pilte salvestada.

Rakendamine on saadaval valiku kaudu --images-repo-mode=multirepo|monorepo (vaikimisi multirepo, st salvestamine siserepositooriumidesse). See määrab mallid, mille alusel pilte registris hoitakse. Lihtsalt valige vajalik režiim peamiste käskude kasutamisel, kõik muu jääb muutumatuks.

Kuna enamik werfi valikuid saab määrata keskkonnamuutujate, on CI/CD süsteemides salvestusrežiimi tavaliselt lihtne määrata projekti tasandil. Näiteks GitLabi puhul piisab, kui lisada keskkonnamuutuja projekti seadetes: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Kui rääkida piltide avaldamisest ja rakenduste juurutamisest (nende protsesside kohta saab põhjalikult lugeda vastavates dokumentatsiooni artiklites: Avaldamise protsess ja Juurutamise protsess), siis režiim määrab rangelt mustri, mille alusel saab pilte hallata.

Detailides peitub tõde

Eraldamise ja peamine keerukus uue salvestusviisi lisamisel on registri puhastusprotsess (puhastusvõimalused, mida werf toetab, vt Puhastusprotsess).

Puhastamisel võtab werf arvesse Kuberneteses klastrites kasutatavaid pilte ning ka kasutaja määratletud poliitikaid. Poliitikate aluseks on siltide jagamine strateegiate vahel. Praegu toetatakse järgmisi strateegiaid:

3 strateegiat, mis on seotud Git-i primitiividega, nagu silt, haru ja commit;
1 strateegia juhuslike kasutaja siltide jaoks.

Teavet sildi strateegia kohta salvestame pilti avaldades lõpppildi etikettides. Isegi väärtus — nn metasilt — on vajalik poliitika osade rakendamiseks. Näiteks, kui eemaldada haru või silt Git-repositooriumist, on loogiline eemaldada ka seotud kasutamata pildid registrist, mis katab osa meie poliitikatest.

Kui salvestatakse ühte registrisse (monorepo), siis pildi sildil, välja arvatud metasild, võib samuti sisaldada pildi nime: PROJEKT:frontend-META-MÄRGMeie ei kasutanud mingit spetsiifilist eraldajat, vaid lisasime lihtsalt vajaliku väärtuse lõpp-pildi etiketisse publikatsiooni ajal.

NB: Kui soovite näha kogu seda, mis on werfi lähtekoodis, siis võib alguspunktiks olla PR 1684.

Selles artiklis ei pühenda me enam tähelepanu probleemidele ja meie lähenemise põhjendustele: strateegiate etikettimine, andmete salvestamine etiketites ja väljaandmisprotsess üldiselt — kõik see on üksikasjalikult kajastatud Dmitri Stolyarovi hiljutises ettekandes: «werf — meie CI/CD tööriist Kuberneteses».

Kokkuvõtteks

Konteineriregistrite toetuse puudumine ilma sisemisteta ei olnud meie või tundmaõpitavate werf kasutajate jaoks takistuseks — alati on võimalik üles seadistada eraldi konteineriregister (või liikuda Googles Cloudis tingimuslikule Container Registry'le)… Siiski nägi sellise piirangu kaotamine loogilisena, et tööriist oleks mugavam laiemale DevOpsi kogukonnale. Selle rakendamisel kokku puutudes seisisime silmitsi peamise keerukusega konteineriregistri puhastusmehhanismi ümberkujundamisel. Nüüd, kui kõik on valmis, on meeldiv teadvustada, et kellelegi on see lihtsamaks muutunud, ja meil (kui projekti peaarendajatel) ei prognoosi edaspidi selle funktsiooni toetamisel tõsiseid raskusi.

Püsi meiega ja varsti räägime teistest uuendustest werf!