{"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\/sk\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Podpora monorepo a multirepo vo werf a ak\u00fd m\u00e1 s\u00favis s Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Podpora
\n
\nT\u00e9ma monorepozit\u00e1ra bola u\u017e viackr\u00e1t diskutovan\u00e1 a zvy\u010dajne vyvol\u00e1va ve\u013emi akt\u00edvne debaty. Pri vytv\u00e1ran\u00ed werf<\/a><\/noindex> ako n\u00e1stroja Open Source, ktor\u00fd m\u00e1 zlep\u0161i\u0165 procesy zostavovania k\u00f3du aplik\u00e1ci\u00ed z Git do Docker obrazov (a ich n\u00e1sledn\u00e9ho dod\u00e1vania do Kubernetes), m\u00e1lo prem\u00fd\u0161\u013eame o tom, ktor\u00e1 vo\u013eba je lep\u0161ia. Pre n\u00e1s je prim\u00e1rne zabezpe\u010di\u0165 v\u0161etko potrebn\u00e9 pre podporovate\u013eov r\u00f4znych n\u00e1zorov (ak to samozrejme nie je v rozpore so zdrav\u00fdm rozumom).<\/p>\n

Ned\u00e1vno zaveden\u00e1 podpora mono-repo vo werf je dobr\u00fdm pr\u00edkladom. Ale najprv si po\u010fme objasni\u0165, ako je t\u00e1to podpora v\u00f4bec spojen\u00e1 s pou\u017e\u00edvan\u00edm werf a ak\u00fd to m\u00e1 s\u00favis s Docker Registry\u2026<\/a><\/noindex><\/p>\n

Probl\u00e9m<\/h2>\n

\nPredstavme si tak\u00fa situ\u00e1ciu. V spolo\u010dnosti existuje mno\u017estvo t\u00edmov v\u00fdvoj\u00e1rov, ktor\u00ed pracuj\u00fa na nez\u00e1visl\u00fdch projektoch. V\u00e4\u010d\u0161ina aplik\u00e1ci\u00ed funguje v Kubernetes, a teda s\u00fa kontajnerizovan\u00e9. Na uchov\u00e1vanie kontajnerov, obrazov, je potrebn\u00fd registr. COMPANY<\/code>. Podobne ako vo v\u00e4\u010d\u0161ine syst\u00e9mov spr\u00e1vy zdrojov\u00e9ho k\u00f3du, Docker Hub neumo\u017e\u0148uje vytv\u00e1ra\u0165 vnoren\u00fa hierarchiu repozit\u00e1rov<\/b>, tak\u00fa ako COMPANY\/PROJECT\/IMAGE<\/code>. V takom pr\u00edpade\u2026 ako teda s t\u00fdmto obmedzen\u00edm uchov\u00e1va\u0165 v registri nemet\u00f3ne aplik\u00e1cie, bez vytv\u00e1rania samostatn\u00e9ho \u00fa\u010dtu pre ka\u017ed\u00fd projekt? <\/p>\n

\"Podpora
\n
\nMo\u017eno je op\u00edsan\u00e1 situ\u00e1cia niekomu zn\u00e1ma, ale po\u010fme zv\u00e1\u017ei\u0165 ot\u00e1zku organizovania uchov\u00e1vania aplik\u00e1ci\u00ed vo v\u0161eobecnosti, t.j. bez spojenia s vy\u0161\u0161ie pop\u00edsan\u00fdm pr\u00edkladom a Docker Hub.<\/p>\n

Mo\u017enosti rie\u0161enia<\/h3>\n

\nAk je aplik\u00e1cia monolitn\u00e1<\/b>, dod\u00e1va sa v jednom obraze, tak\u017ee nevznikaj\u00fa \u017eiadne ot\u00e1zky a jednoducho uchov\u00e1vame obrazy v registri kontajnerov projektu.<\/p>\n

Ke\u010f je aplik\u00e1cia prezentovan\u00e1 vo forme nieko\u013ek\u00fdch komponentov, mikroslu\u017eby<\/b>, je potrebn\u00e9 zvoli\u0165 ur\u010dit\u00fd pr\u00edstup. Na pr\u00edklade typickej webovej aplik\u00e1cie, ktor\u00e1 sa sklad\u00e1 z dvoch obrazov: frontend<\/code> a backend<\/code> \u2014 mo\u017en\u00e9 varianty s\u00fa nasleduj\u00face:<\/p>\n

    \n
  1. Uchov\u00e1va\u0165 obrazy v samostatn\u00fdch vnoren\u00fdch repozit\u00e1roch:\n

    \"Podpora<\/li>\n

  2. Uchov\u00e1va\u0165 v\u0161etko v jednom repozit\u00e1ri a n\u00e1zov obrazu zoh\u013eadni\u0165 v tage, napr\u00edklad takto:\n

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

    \nPozn\u00e1mka<\/b>: Vlastne existuje e\u0161te mo\u017enos\u0165 s ulo\u017een\u00edm v r\u00f4znych repozit\u00e1roch, PROJECT-frontend<\/code> a PROJECT-backend<\/code>, ale ten nebudeme zva\u017eova\u0165 z d\u00f4vodu zlo\u017eitosti podpory, organiz\u00e1cie a rozdelenia pr\u00e1v medzi pou\u017e\u00edvate\u013emi.<\/i><\/p>\n

    Podpora v werf<\/h2>\n

    \nP\u00f4vodne werf obmedzoval na vn\u00fatorn\u00e9 repozit\u00e1re \u2014 na\u0161\u0165astie v\u00e4\u010d\u0161ina registri t\u00fato mo\u017enos\u0165 podporuje. Od verzie v1.0.4-alpha.3<\/a><\/noindex>, bola pridan\u00e1 podpora registri, v ktor\u00fdch nie je podpora vn\u00fatornosti<\/b>, vr\u00e1tane Docker Hub. Od tejto chv\u00edle m\u00e1 pou\u017e\u00edvate\u013e na v\u00fdber, ako uchov\u00e1va\u0165 obrazy aplik\u00e1cie.<\/p>\n

    Realiz\u00e1cia je dostupn\u00e1 v r\u00e1mci mo\u017enosti --images-repo-mode=multirepo|monorepo<\/code> (predvolene multirepo<\/code>, t.j. uchov\u00e1vanie vo vn\u00fatorn\u00fdch repozit\u00e1roch). Ur\u010duje \u0161abl\u00f3ny, pod\u013ea ktor\u00fdch s\u00fa obrazy uchov\u00e1van\u00e9 v registri. Sta\u010d\u00ed zvoli\u0165 po\u017eadovan\u00fd re\u017eim pri pou\u017e\u00edvan\u00ed z\u00e1kladn\u00fdch pr\u00edkazov, a v\u0161etko ostatn\u00e9 zostane nezmenen\u00e9.<\/p>\n

    Ke\u010f\u017ee v\u00e4\u010d\u0161inu mo\u017enost\u00ed werf je mo\u017en\u00e9 nastavi\u0165 premenn\u00fdmi prostredia<\/b>, v CI\/CD syst\u00e9moch je re\u017eim uchov\u00e1vania zvy\u010dajne \u013eahko nastavi\u0165 glob\u00e1lne pre cel\u00fd projekt. Napr\u00edklad, v pr\u00edpade GitLab<\/b> sta\u010d\u00ed prida\u0165 premenn\u00fa prostredia v nastaveniach projektu: Nastavenia -> CI \/ CD -> Premenn\u00e9: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Ak hovor\u00edme o publikovan\u00ed obrazov a nasaden\u00ed aplik\u00e1ci\u00ed (o t\u00fdchto procesoch sa m\u00f4\u017eete podrobne do\u010d\u00edta\u0165 v pr\u00edslu\u0161n\u00fdch \u010dl\u00e1nkoch dokument\u00e1cie: Publika\u010dn\u00fd proces<\/a><\/noindex> a Nasadzovac\u00ed proces<\/a><\/noindex>), re\u017eim rozhodne ur\u010duje \u0161abl\u00f3nu, pod\u013ea ktorej m\u00f4\u017eete pracova\u0165 s obrazom.<\/p>\n

    Diabol je v detailoch<\/h3>\n

    \nRozdiel a hlavn\u00e1 zlo\u017eitost pri prid\u00e1van\u00ed nov\u00e9ho sp\u00f4sobu uchov\u00e1vania \u2014 v procese \u010distenia registry (mo\u017enosti \u010distenia, podporovan\u00e9 vo werf, pozri v \u010cistiaci proces<\/a><\/noindex>)<\/i>.<\/p>\n

    Pri \u010disten\u00ed werf zoh\u013ead\u0148uje obrazy pou\u017e\u00edvan\u00e9 v klastroch Kubernetes a taktie\u017e politiky, ktor\u00e9 si pou\u017e\u00edvate\u013e prisp\u00f4sobuje. Z\u00e1kladom polit\u00edk je rozdelenie tagov na strat\u00e9gie. Tak\u017ee, moment\u00e1lne s\u00fa podporovan\u00e9 tri strat\u00e9gie:<\/p>\n

      \n
    1. 3 strat\u00e9gie, ktor\u00e9 s\u00favisia s Git primit\u00edvami, ako s\u00fa tag, vetva a commit;<\/li>\n
    2. 1 strat\u00e9gia pre \u013eubovo\u013en\u00e9 pou\u017e\u00edvate\u013esk\u00e9 tagy.<\/li>\n<\/ol>\n

      \nInform\u00e1cie o strat\u00e9gii tagu uchov\u00e1vame pri publikovan\u00ed obrazu v \u0161t\u00edtkoch kone\u010dn\u00e9ho obrazu. Samotn\u00e1 hodnota \u2014 takzvan\u00fd metatag<\/b> \u2014 je potrebn\u00e1 na uplatnenie \u010dasti polit\u00edk. Napr\u00edklad, pri odstra\u0148ovan\u00ed vetvy alebo tagu z Git repozit\u00e1ra je logick\u00e9 odstr\u00e1ni\u0165 aj s\u00favisiace nevyu\u017eit\u00e9<\/i> obrazy z registru, \u010do je pokryt\u00e9 \u010das\u0165ou na\u0161ich polit\u00edk.<\/p>\n

      Pri uchov\u00e1van\u00ed v jednom repozit\u00e1ri (monorepo<\/code>), v tagu obrazu m\u00f4\u017ee by\u0165 okrem metatagu ulo\u017een\u00e9 aj meno obrazu: PROJEKT:frontend<\/b>-META-TAG<\/code>. Na ich rozdelenie sme nezaviedli \u017eiadny \u0161pecifick\u00fd oddelova\u010d, ale jednoducho sme pridali potrebn\u00fa hodnotu do \u0161t\u00edtku kone\u010dn\u00e9ho obrazu pri publikovan\u00ed.<\/p>\n

      Pozn\u00e1mka<\/b>: Ak m\u00e1te z\u00e1ujem pozrie\u0165 sa na v\u0161etko pop\u00edsan\u00e9 v zdrojovom k\u00f3de werf, potom v\u00fdchodiskov\u00fdm bodom m\u00f4\u017ee by\u0165 PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      V tomto \u010dl\u00e1nku sa nebudeme venova\u0165 viac problematike a od\u00f4vodneniu n\u00e1\u0161ho pr\u00edstupu: o strat\u00e9gi\u00e1ch tagovania, ukladan\u00ed \u00fadajov v \u0161t\u00edtkoch a procese publikovania celkovo \u2014 o v\u0161etkom tomto podrobne hovoril v ned\u00e1vnej spr\u00e1ve Dmitrij Stoljaro v: \u201ewerf \u2014 n\u00e1\u0161 n\u00e1stroj pre CI\/CD v Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Zhr\u0148uj\u00fac<\/h2>\n

      \nNedostatok podpory pre registry bez vnorenia nebol pre n\u00e1s ani pre zn\u00e1mych pou\u017e\u00edvate\u013eov werf blokuj\u00facim faktorom \u2014 ve\u010f v\u017edy je mo\u017en\u00e9 nastavi\u0165 samostatn\u00fd registry obr\u00e1zkov (alebo prejs\u0165 na podmienkov\u00fd Container Registry v Google Cloud)\u2026 Av\u0161ak zru\u0161enie tak\u00e9hoto obmedzenia sa zdalo logick\u00e9, aby bol n\u00e1stroj pohodln\u00fd pre \u0161ir\u0161iu komunitu DevOps. Pri jeho realiz\u00e1cii sme sa stretli s hlavnou komplik\u00e1ciou v prepracovan\u00ed mechanizmu \u010distenia registry kontajnerov. Teraz, ke\u010f je v\u0161etko pripraven\u00e9, je pr\u00edjemn\u00e9 si uvedomi\u0165, \u017ee niekomu sa to u\u013eah\u010dilo, a u n\u00e1s (ako hlavn\u00fdch v\u00fdvoj\u00e1rov projektu) sa v \u010fal\u0161ej podpore tejto funkcie nepredpokladaj\u00fa \u017eiadne v\u00fdrazn\u00e9 \u0165a\u017ekosti.<\/p>\n

      Zosta\u0148te s nami a \u010doskoro v\u00e1m povieme o \u010fal\u0161\u00edch novink\u00e1ch v werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nPre\u010d\u00edtajte si tie\u017e na na\u0161om blogu:<\/p>\n