{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Toetamine monorepo ja multirepo werf-is ning kuidas see on seotud Docker Registryga","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Toetamine
\n
\nMonorepo teema on juba korduvalt arutatud ja tavaliselt tekitab see \u00fcsna aktiivset diskussiooni. Luues werf<\/a><\/noindex> avatud l\u00e4htekoodiga t\u00f6\u00f6riista, mille eesm\u00e4rk on parandada rakenduste koodi koostamise protsessi Gitist Docker piltide (ja nende edasise tarnimise Kubernetesesse), m\u00f5tleme me v\u00e4he, milline valik on parem. Meie jaoks on esmat\u00e4htis tagada k\u00f5ik vajalik erinevate arvamuste toetajatele (kui see ei l\u00e4he vastuollu terve m\u00f5istusega, muidugi).<\/p>\n

Hiljuti ilmunud tugi mono-repole werf'is on hea n\u00e4ide sellest. Kuid esiteks uurime, kuidas see tugi \u00fcldse on seotud werf'i kasutamisega ja mis on seos Docker Registryga ...<\/a><\/noindex><\/p>\n

Problemaatika<\/h2>\n

\nKujutage ette olukorda. Ettev\u00f5ttes on mitmeid arendustiime, kes tegelevad iseseisvate projektidega. Enamik rakendusi t\u00f6\u00f6tab Kuberneteses ja seega \u2013 on konteineritud. Konteinerite ja piltide salvestamiseks on vajalik register. Sellise registrina kasutab ettev\u00f5te Docker Hub'i \u00fche abonendiga ETTEV\u00d5TE<\/code>. Sarnaselt enamikule l\u00e4htekoodi salvestamise s\u00fcsteemidele, Docker Hub ei luba luua hierarhilisi registrite struktuure<\/b>, nagu n\u00e4iteks ETTEV\u00d5TE\/PROJEKT\/IMAGE<\/code>. Sellisel juhul ... kuidas salvestada registris mitte-monoliitseid rakendusi, luues iga projekti jaoks eraldi konto? <\/p>\n

\"Toetamine
\n
\nV\u00f5imalik, et kirjeldatud olukord on kellegi jaoks tuttav, kuid vaatame k\u00fcsimust rakenduste salvestamise korralduse \u00fcle \u00fcldiselt, st ilma seoseta eespool kirjeldatud n\u00e4ite ja Docker Hub'iga.<\/p>\n

Lahenduste teed<\/h3>\n

\nKui rakendus on monoliitne<\/b>, siis probleeme ei teki ja me lihtsalt salvestame pildid projekti konteinerite registrisse.<\/p>\n

Kui rakendus on esitatud mitme komponendina, Mikroteenused<\/b>, siis tuleb valida kindel l\u00e4henemine. N\u00e4iteks t\u00fc\u00fcpilise veebirakenduse puhul, mis koosneb kahest pildist: frontend<\/code> ja backend<\/code> \u2014 v\u00f5imalused on j\u00e4rgmised:<\/p>\n

    \n
  1. Salvestada pildid eraldi sissep\u00e4\u00e4sudega registrites:\n

    \"Toetamine<\/li>\n

  2. Salvestada k\u00f5ik \u00fchte registrisse ja arvestada pildi nimega m\u00e4rgises, n\u00e4iteks j\u00e4rgmiselt:\n

    \"Toetamine<\/li>\n<\/ol>\n

    \nNB<\/b>: Tegelikult on veel variant pidada erinevates registrites, PROJEKT-frontend<\/code> ja PROJEKT-backend<\/code>, kuid seda me ei k\u00e4sitle keerukuse t\u00f5ttu toetamisel, korraldamisel ja \u00f5iguste jagamisel kasutajate vahel.<\/i><\/p>\n

    Tugi werf'is<\/h2>\n

    \nEsialgu piirdus werf siserepositooriumidega \u2014 \u00f5nneks toetab enamik registreid seda v\u00f5imalust. Alates versioonist v1.0.4-alpha.3<\/a><\/noindex>, on lisatud tugi registritele, kus sisemine tugi ei ole saadaval<\/b>, sealhulgas Docker Hub. Sellest hetkest alates on kasutajal v\u00f5imalus valida, kuidas rakenduste pilte salvestada.<\/p>\n

    Rakendamine on saadaval valiku kaudu --images-repo-mode=multirepo|monorepo<\/code> (vaikimisi multirepo<\/code>, st salvestamine siserepositooriumidesse). See m\u00e4\u00e4rab mallid, mille alusel pilte registris hoitakse. Lihtsalt valige vajalik re\u017eiim peamiste k\u00e4skude kasutamisel, k\u00f5ik muu j\u00e4\u00e4b muutumatuks.<\/p>\n

    Kuna enamik werfi valikuid saab m\u00e4\u00e4rata keskkonnamuutujate<\/b>, on CI\/CD s\u00fcsteemides salvestusre\u017eiimi tavaliselt lihtne m\u00e4\u00e4rata projekti tasandil. N\u00e4iteks GitLabi puhul<\/b> piisab, kui lisada keskkonnamuutuja projekti seadetes: Settings -> CI \/ CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Kui r\u00e4\u00e4kida piltide avaldamisest ja rakenduste juurutamisest (nende protsesside kohta saab p\u00f5hjalikult lugeda vastavates dokumentatsiooni artiklites: Avaldamise protsess<\/a><\/noindex> ja Juurutamise protsess<\/a><\/noindex>), siis re\u017eiim m\u00e4\u00e4rab rangelt mustri, mille alusel saab pilte hallata.<\/p>\n

    Detailides peitub t\u00f5de<\/h3>\n

    \nEraldamise ja peamine keerukus uue salvestusviisi lisamisel on registri puhastusprotsess (puhastusv\u00f5imalused, mida werf toetab, vt Puhastusprotsess<\/a><\/noindex>)<\/i>.<\/p>\n

    Puhastamisel v\u00f5tab werf arvesse Kuberneteses klastrites kasutatavaid pilte ning ka kasutaja m\u00e4\u00e4ratletud poliitikaid. Poliitikate aluseks on siltide jagamine strateegiate vahel. Praegu toetatakse j\u00e4rgmisi strateegiaid:<\/p>\n

      \n
    1. 3 strateegiat, mis on seotud Git-i primitiividega, nagu silt, haru ja commit;<\/li>\n
    2. 1 strateegia juhuslike kasutaja siltide jaoks.<\/li>\n<\/ol>\n

      \nTeavet sildi strateegia kohta salvestame pilti avaldades l\u00f5pppildi etikettides. Isegi v\u00e4\u00e4rtus \u2014 nn metasilt<\/b> \u2014 on vajalik poliitika osade rakendamiseks. N\u00e4iteks, kui eemaldada haru v\u00f5i silt Git-repositooriumist, on loogiline eemaldada ka seotud kasutamata<\/i> pildid registrist, mis katab osa meie poliitikatest.<\/p>\n

      Kui salvestatakse \u00fchte registrisse (monorepo<\/code>), siis pildi sildil, v\u00e4lja arvatud metasild, v\u00f5ib samuti sisaldada pildi nime: PROJEKT:frontend<\/b>-META-M\u00c4RG<\/code>Meie ei kasutanud mingit spetsiifilist eraldajat, vaid lisasime lihtsalt vajaliku v\u00e4\u00e4rtuse l\u00f5pp-pildi etiketisse publikatsiooni ajal.<\/p>\n

      NB<\/b>: Kui soovite n\u00e4ha kogu seda, mis on werfi l\u00e4htekoodis, siis v\u00f5ib alguspunktiks olla PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      Selles artiklis ei p\u00fchenda me enam t\u00e4helepanu probleemidele ja meie l\u00e4henemise p\u00f5hjendustele: strateegiate etikettimine, andmete salvestamine etiketites ja v\u00e4ljaandmisprotsess \u00fcldiselt \u2014 k\u00f5ik see on \u00fcksikasjalikult kajastatud Dmitri Stolyarovi hiljutises ettekandes: \u00abwerf \u2014 meie CI\/CD t\u00f6\u00f6riist Kuberneteses<\/a><\/noindex>\u00bb.<\/p>\n

      Kokkuv\u00f5tteks<\/h2>\n

      \nKonteineriregistrite toetuse puudumine ilma sisemisteta ei olnud meie v\u00f5i tundma\u00f5pitavate werf kasutajate jaoks takistuseks \u2014 alati on v\u00f5imalik \u00fcles seadistada eraldi konteineriregister (v\u00f5i liikuda Googles Cloudis tingimuslikule Container Registry'le)\u2026 Siiski n\u00e4gi sellise piirangu kaotamine loogilisena, et t\u00f6\u00f6riist oleks mugavam laiemale DevOpsi kogukonnale. Selle rakendamisel kokku puutudes seisisime silmitsi peamise keerukusega konteineriregistri puhastusmehhanismi \u00fcmberkujundamisel. N\u00fc\u00fcd, kui k\u00f5ik on valmis, on meeldiv teadvustada, et kellelegi on see lihtsamaks muutunud, ja meil (kui projekti peaarendajatel) ei prognoosi edaspidi selle funktsiooni toetamisel t\u00f5siseid raskusi.<\/p>\n

      P\u00fcsi meiega ja varsti r\u00e4\u00e4gime teistest uuendustest werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nLugege ka meie blogist:<\/p>\n