{"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":"Monorepo ja multirepo tugi werf'is ja kuidas siia sobib Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Monorepo
\n
\nMonorepo teemat on juba korduvalt arutatud ja see tekitab tavaliselt aktiivseid vaidlusi. Luues werf<\/a><\/noindex> avatud l\u00e4htekoodiga t\u00f6\u00f6riist, mille eesm\u00e4rk on parandada rakenduste koodide koostamisprotsesse Gitist Docker-piltideks (ja nende edastamist Kubernetesesse), m\u00f5tleme me v\u00e4he sellele, milline valik on parem. Meie peamine eesm\u00e4rk on tagada k\u00f5ik vajalik, et toetada erinevaid arvamusi (kui see ei ole vastuolus m\u00f5istusega, loomulikult).<\/p>\n

Hiljuti sisse viidud mono-repo tugi werf'is on hea n\u00e4ide sellest. Kuid enne kui edasi minna, vaatame, kuidas see tugi on seotud werf'i kasutamisega ja kuidas siia sobib Docker Registry...<\/a><\/noindex><\/p>\n

Probleemistik<\/h2>\n

\nKujutage ette olukorda. Ettev\u00f5ttes on palju arendajate meeskondi, kes tegelevad s\u00f5ltumatute projektidega. Enamik rakendusi toimib Kuberneteses ja seega \u2014 on konteineriseeritud. Konteinerite ja piltide salvestamiseks on vajalik registri (registry) olemasolu. Sellise registrina kasutatakse ettev\u00f5ttes Docker Hub'i koos \u00fche konto COMPANY<\/code>. Sarnaselt enamikule l\u00e4htekoode salvestamise s\u00fcsteemidele, Docker Hub ei luba luua sisemist hierarhiat registrite vahel<\/b>, nagu ETTEV\u00d5TE\/PROJEKT\/PILT<\/code>. Sel juhul... kuidas selle piirangu puhul hallata mitmetasandilisi rakendusi, luues iga projekti jaoks eraldi konto? <\/p>\n

\"Monorepo
\n
\nV\u00f5ib-olla on nimetatud olukord kellelegi tuttav, kuid vaatame rakenduste hoidmise korraldust laiemalt, st ilma eelnevalt mainitud n\u00e4iteta ja Docker Hub'ita.<\/p>\n

Lahenduste teed<\/h3>\n

\nKui rakendus on monoliitne<\/b>, ei tekki k\u00fcsimusi ja salvestame lihtsalt projekti konteinerite registrisse.<\/p>\n

Kui rakendus esindab end mitme komponendina, mikroteenustena<\/b>, tuleb valida teatud l\u00e4henemine. N\u00e4ite aluseks v\u00f5ttes t\u00fc\u00fcpiliselt veebirakendust, mis koosneb kahest pildist: eesmine<\/code> ja tagaosa<\/code> \u2014 v\u00f5imalikud valikud on j\u00e4rgmised:<\/p>\n

    \n
  1. Hoidke pilte eraldi sisemistes registrites:\n

    \"Monorepo<\/li>\n

  2. Hoidke k\u00f5ik \u00fches registris ja v\u00f5tke arvesse pildi nime silti, n\u00e4iteks nii:\n

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

    \nNB<\/b>: Tegelikult on veel variant, mis on salvestamine erinevatesse registritesse, PROJEKT-eesmine<\/code> ja PROJEKT-tagaosa<\/code>, kuid me ei k\u00e4sitle seda keerulise toe, organisatsiooni ja kasutajate vaheliste \u00f5iguste jagamise t\u00f5ttu.<\/i><\/p>\n

    Tugi werf'is<\/h2>\n

    \nAlguses piirdus werf sisemiste hoidlate, \u00f5nneks toetavad enamik registreid sellist v\u00f5imalust. Alates versioonist v1.0.4-alpha.3<\/a><\/noindex>, lisandus toimetamine registritega, kus sisemist ei toetata<\/b>, ja Docker Hub kuulub nende hulka. Sellest hetkest alates on kasutajal valik, kuidas s\u00e4ilitada rakenduse pilte.<\/p>\n

    Rakendamine on saadaval valiku raames --images-repo-mode=multirepo|monorepo<\/code> (vaikimisi multirepo<\/code>, st hoidmine sisemistes hoidlates). See m\u00e4\u00e4ratleb mustrid, mille alusel pildid registreeritud on. Peab vaid valima vajaliku re\u017eiimi p\u00f5hikomandeid kasutades, k\u00f5ik muu j\u00e4\u00e4b muutumatuks.<\/p>\n

    Kuna enamik werf'i valikuid saab m\u00e4\u00e4rata keskkonnamuutujate kaudu<\/b>, CI\/CD s\u00fcsteemides on salvestamisre\u017eiimi tavaliselt lihtne m\u00e4\u00e4rata kogu projekti jaoks globaalselt. N\u00e4iteks GitLabi puhul<\/b> piisab keskkonnamuutuja lisamisest projekti seadetes: Seaded -> CI \/ CD -> Muutujad: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    R\u00e4\u00e4kides piltide avaldamisest ja rakenduste juurutamisest (need protsessid on p\u00f5hjalikult k\u00e4sitletud vastavates dokumentatsiooni artiklites: Avaldamise protsess<\/a><\/noindex> ja Juurutamise protsess<\/a><\/noindex>), m\u00e4\u00e4rab re\u017eiim eksklusiivselt malli, mille alusel piltidega t\u00f6\u00f6tada.<\/p>\n

    Detailides peitub diibel<\/h3>\n

    \nUue salvestusviisi lisamise peamine erinevus ja keerukus seisneb registri puhastamise protsessis (puhastamisv\u00f5imalused, mida werf toetab, vt Puhastamisprotsess<\/a><\/noindex>)<\/i>.<\/p>\n

    Werf arvestab puhastamisel Kubernetes'i klastrites kasutatavaid pilte ning kasutaja m\u00e4\u00e4ratud poliitikaid. Poliitikate aluseks on siltide jagamine strateegiateks. Hetkel toetatud strateegiad:<\/p>\n

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

      \nTeave sildi strateegia kohta salvestatakse pildi avaldamisel l\u00f5pppildi etikettidesse. Isegi v\u00e4\u00e4rtus \u2014 nii nimetatud metasilt<\/b> \u2014 on vajalik poliitika osade rakendamiseks. N\u00e4iteks, kui haru v\u00f5i silt eemaldatakse Git'i repos, on m\u00f5istlik eemaldada ka seotud kasutamata<\/i> pildid registrist, mida katab osa meie poliitikatest.<\/p>\n

      \u00dches repolis salvestades (monorepo<\/code>), konteineri silti all v\u00f5ib peale meta-sildi hoida ka konteineri nime: PROJEKT:eesmine<\/b>-META-SILT<\/code>. Nende eraldamiseks ei ole me kasutanud mingit spetsiifilist eraldajat, vaid oleme lihtsalt lisanud vajaliku v\u00e4\u00e4rtuse l\u00f5ppkonteineri silti avaldamisel.<\/p>\n

      NB<\/b>: Kui soovite vaatama hakata k\u00f5ike, mis on kirjeldatud werfi l\u00e4htekoodis, siis alguspunktiks v\u00f5ib olla PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      Selles artiklis ei kavatse me rohkem t\u00e4helepanu p\u00f6\u00f6rata meie l\u00e4henemise probleemidele ja p\u00f5hjendusele: silti strateegiate, andmete s\u00e4ilitamise ja avaldamisprotsessi osas \u2014 k\u00f5igest sellest on p\u00f5hjalikult r\u00e4\u00e4gitud Dmitri Stolyarovi hiljutises ettekandes: \u201ewerf \u2014 meie CI\/CD t\u00f6\u00f6riist Kuberneteses<\/a><\/noindex>\u00bb.<\/p>\n

      Kokkuv\u00f5tteks<\/h2>\n

      \nRegistry ilma s\u00fcgavat struktuuri toetamine ei olnud meie ega meie teadaolevate kasutajate jaoks probleem \u2014 alati on v\u00f5imalik t\u00f5sta eraldi konteinerite registrit (v\u00f5i minna Google Cloudi tingimuslikku Container Registry'isse)\u2026 Kuid sellise piiri eemaldamine tundus loogiline, et t\u00f6\u00f6riist oleks mugavam laiemale DevOps kogukonnale. Selle rakendamisel kohtasime peamist raskust konteinerite registri puhastusmehhanismi \u00fcmberkujundamisel. N\u00fc\u00fcd, kui k\u00f5ik on valmis, on hea teada, et kellelgi on lihtsam, ja meile (kui selle projekti peamistele arendajatele) ei ennustata t\u00f5siseid raskusi selle funktsiooni t\u00e4iendavas toetamises.<\/p>\n

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

      P.S.<\/h2>\n

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