{"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\/sq\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"P\u00ebrkrahja e monorepo dhe multirepo n\u00eb werf dhe \u00e7far\u00eb lidhje ka me Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"P\u00ebrkrahja
\n
\nTema e monorepozitit \u00ebsht\u00eb diskutuar disa her\u00eb dhe, zakonisht, shkakton debate mjaft aktiv. Duke krijuar werf<\/a><\/noindex> si nj\u00eb mjet Open Source, i destinuar p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar proceset e nd\u00ebrtimit t\u00eb kodit t\u00eb aplikacioneve nga Git n\u00eb imazhe Docker (dhe shp\u00ebrndarjen e tyre t\u00eb m\u00ebvonshme n\u00eb Kubernetes), ne nuk mendojm\u00eb shum\u00eb p\u00ebr at\u00eb se cili \u00ebsht\u00eb zgjedhja m\u00eb e mir\u00eb. P\u00ebr ne, \u00ebsht\u00eb thelb\u00ebsore t\u00eb sigurojm\u00eb gjith\u00e7ka t\u00eb nevojshme p\u00ebr mb\u00ebshtet\u00ebsit e mendimeve t\u00eb ndryshme (n\u00ebse kjo nuk \u00ebsht\u00eb n\u00eb kund\u00ebrshtim me sh\u00ebndetin e arsyes, natyrisht).<\/p>\n

Mb\u00ebshtetje e sapodal\u00eb p\u00ebr mono-repo n\u00eb werf \u00ebsht\u00eb nj\u00eb shembull i mir\u00eb p\u00ebr k\u00ebt\u00eb. Por, p\u00ebrpara se t\u00eb fillojm\u00eb, le t\u00eb zb\u00ebrthejm\u00eb se si \u00ebsht\u00eb e lidhur kjo mb\u00ebshtetje me p\u00ebrdorimin e werf dhe \u00e7far\u00eb ka t\u00eb b\u00ebj\u00eb kjo me Docker Registry\u2026<\/a><\/noindex><\/p>\n

Problematika<\/h2>\n

\nImagjinoni nj\u00eb situat\u00eb t\u00eb till\u00eb. N\u00eb nj\u00eb kompani ka shum\u00eb grupe zhvilluesish q\u00eb jan\u00eb t\u00eb angazhuar n\u00eb projekte t\u00eb pavarura. Shumica e aplikacioneve funksionojn\u00eb n\u00eb Kubernetes dhe, p\u00ebr rrjedhoj\u00eb, jan\u00eb t\u00eb kontejnerizuara. P\u00ebr ruajtjen e kontejner\u00ebve dhe imazheve, k\u00ebrkohet nj\u00eb regjist\u00ebr (registry). Si nj\u00eb regjist\u00ebr t\u00eb till\u00eb, kompania p\u00ebrdor Docker Hub me nj\u00eb llogari t\u00eb vetme COMPANY<\/code>. Sipas analogjis\u00eb me shumic\u00ebn e sistemeve t\u00eb ruajtjes s\u00eb kodit burimor, Docker Hub nuk lejon krijimin e nj\u00eb hierarkie t\u00eb brendshme t\u00eb regjistrave<\/b>, si COMPANY\/PROJECT\/IMAGE<\/code>. N\u00eb k\u00ebt\u00eb rast\u2026 si t\u00eb ruajm\u00eb aplikacionet jo-monolitike n\u00eb regjistrin pa krijuar nj\u00eb llogari t\u00eb ve\u00e7ant\u00eb p\u00ebr secilin projekt? <\/p>\n

\"P\u00ebrkrahja
\n
\nNdoshta situata e p\u00ebrshkruar \u00ebsht\u00eb e njohur p\u00ebr dik\u00eb, por le t\u00eb shqyrtojm\u00eb \u00e7\u00ebshtjen e organizimit t\u00eb ruajtjes s\u00eb aplikacioneve n\u00eb p\u00ebrgjith\u00ebsi, pra pa lidhje me shembullin e p\u00ebrmendur m\u00eb par\u00eb dhe Docker Hub.<\/p>\n

Zgjidhjet<\/h3>\n

\nN\u00ebse aplikacioni \u00ebsht\u00eb monolitik<\/b>, nuk ka pyetje dhe ne thjesht ruajm\u00eb imazhet n\u00eb regjistrin e kontejner\u00ebve t\u00eb projektit.<\/p>\n

Kur aplikacioni paraqitet n\u00eb form\u00eb t\u00eb disa komponenteve, mikrosherbimesh<\/b>, duhet t\u00eb zgjidhet nj\u00eb qasje e caktuar. P\u00ebr shembull, n\u00eb nj\u00eb aplikacion tipik web, i p\u00ebrb\u00ebr\u00eb nga dy imazhe: frontend<\/code> dhe backend<\/code> \u2014 mund\u00ebsit\u00eb jan\u00eb si m\u00eb posht\u00eb:<\/p>\n

    \n
  1. T\u00eb ruajm\u00eb imazhet n\u00eb regjistra t\u00eb brendshme t\u00eb ve\u00e7anta:\n

    \"P\u00ebrkrahja<\/li>\n

  2. T\u00eb ruajm\u00eb gjith\u00e7ka n\u00eb nj\u00eb regjist\u00ebr, nd\u00ebrsa emri i imazhit t\u00eb merret parasysh n\u00eb etiket\u00eb, p\u00ebr shembull, n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb:\n

    \"P\u00ebrkrahja<\/li>\n<\/ol>\n

    \nNB<\/b>: N\u00eb t\u00eb v\u00ebrtet\u00eb, ka nj\u00eb mund\u00ebsi t\u00eb tjera, duke ruajtur n\u00eb regjistra t\u00eb ndrysh\u00ebm, PROJECT-frontend<\/code> dhe PROJECT-backend<\/code>, por nuk do ta shqyrtojm\u00eb at\u00eb p\u00ebr shkak t\u00eb v\u00ebshtir\u00ebsive n\u00eb mb\u00ebshtetje, organizim dhe ndarje t\u00eb drejtave nd\u00ebrmjet p\u00ebrdoruesve.<\/i><\/p>\n

    Mb\u00ebshtetje n\u00eb werf<\/h2>\n

    \nFillimisht werf u kufizua n\u00eb regjistra t\u00eb brendsh\u00ebm \u2014 fatmir\u00ebsisht, shumica e regjistrave e mb\u00ebshtesin nj\u00eb mund\u00ebsi t\u00eb till\u00eb. Duke filluar nga versione v1.0.4-alpha.3<\/a><\/noindex>, \u00ebsht\u00eb shtuar puna me regjistra n\u00eb t\u00eb cilat nuk mb\u00ebshtetet brend\u00ebsia<\/b>, dhe Docker Hub \u00ebsht\u00eb n\u00eb mesin e tyre. Q\u00eb nga ky moment, p\u00ebrdoruesi ka pasur zgjedhjen se si t\u00eb ruaj\u00eb imazhet e aplikacionit.<\/p>\n

    Zbatimi \u00ebsht\u00eb i disponuesh\u00ebm n\u00eb kuad\u00ebr t\u00eb opsionit --images-repo-mode=multirepo|monorepo<\/code> (ndon\u00ebse, me parazgjedhje multirepo<\/code>, pra ruajtja n\u00eb regjistra t\u00eb brendsh\u00ebm). Ky opsion p\u00ebrcakton modelet me t\u00eb cilat imazhet ruhen n\u00eb regjist\u00ebr. \u00cbsht\u00eb e mjaftueshme t\u00eb zgjidhni modin e duhur gjat\u00eb p\u00ebrdorimit t\u00eb komandave kryesore, dhe e gjith\u00eb e tjera do t\u00eb mbetet e pandryshuar.<\/p>\n

    Duke qen\u00eb se shumica e opsioneve t\u00eb werf mund t\u00eb p\u00ebrcaktohen me variabla t\u00eb mjedisit<\/b>, n\u00eb sistemet CI\/CD, m\u00ebnyra e ruajtjes zakonisht p\u00ebrcaktohet leht\u00ebsisht globalisht p\u00ebr t\u00eb gjith\u00eb projektin. P\u00ebr shembull, n\u00eb rastin e GitLab<\/b> mjafton t\u00eb shtoni nj\u00eb variab\u00ebl mjedisi n\u00eb cil\u00ebsimet e projektit: Settings -> CI \/ CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    N\u00ebse flasim p\u00ebr publikimin e imazheve dhe t\u00eb aplikacioneve (p\u00ebr k\u00ebto procese mund t\u00eb lexoni m\u00eb shum\u00eb n\u00eb artikujt p\u00ebrkat\u00ebs n\u00eb dokumentacion: Procesi i publikimit<\/a><\/noindex> dhe Procesi i vendosjes<\/a><\/noindex>), at\u00ebher\u00eb m\u00ebnyra p\u00ebrcakton vet\u00ebm modelin me t\u00eb cilin mund t\u00eb punoni me imazhin.<\/p>\n

    Djalli \u00ebsht\u00eb n\u00eb detaje<\/h3>\n

    \nDallimi dhe v\u00ebshtir\u00ebsia kryesore n\u00eb shtimin e nj\u00eb m\u00ebnyre t\u00eb re ruajtjeje \u2014 n\u00eb procesin e pastrimit t\u00eb regjistrit (mund\u00ebsit\u00eb e pastrimit, t\u00eb mb\u00ebshtetura n\u00eb werf, shih n\u00eb Procesi i pastrimit<\/a><\/noindex>)<\/i>.<\/p>\n

    Gjat\u00eb pastrimit, werf merr parasysh imazhet q\u00eb p\u00ebrdoren n\u00eb klaster\u00ebt Kubernetes, si dhe politikat e p\u00ebrcaktuara nga p\u00ebrdoruesi. N\u00eb thelb, politikat i n\u00ebnshtrohen ndarjes s\u00eb etiketave n\u00eb strategji. Strategjit\u00eb aktualisht t\u00eb mb\u00ebshtetura jan\u00eb:<\/p>\n

      \n
    1. 3 strategji t\u00eb lidhura me primitivat Git, si etiketa, dega dhe commit;<\/li>\n
    2. 1 strategji p\u00ebr etiketa t\u00eb rast\u00ebsishme t\u00eb p\u00ebrdoruesve.<\/li>\n<\/ol>\n

      \nInformacionin mbi strategjin\u00eb e etiket\u00ebs e ruajm\u00eb gjat\u00eb publikimit t\u00eb imazhit n\u00eb etiketat e imazhit p\u00ebrfundimtar. Vlera vet\u00eb \u2014 e quajtur metaetiket\u00eb<\/b> \u2014 \u00ebsht\u00eb e nevojshme p\u00ebr zbatimin e disa pjes\u00ebve t\u00eb politikave. P\u00ebr shembull, kur hiqet nj\u00eb deg\u00eb ose etiket\u00eb nga regjistri Git, \u00ebsht\u00eb logjike t\u00eb hiqen dhe imazhet<\/i> e lidhura nga regjistri q\u00eb nuk p\u00ebrdoren, dhe kjo mb coveredhet nga pjesa e politikave tan\u00eb.<\/p>\n

      Kur ruhen n\u00eb nj\u00eb regjist\u00ebr (monorepo<\/code>), n\u00eb etiket\u00ebn e imazhit, p\u00ebrve\u00e7 metaetiket\u00ebs, mund t\u00eb ruhet edhe emri i imazhit: PROJEKTI:frontend<\/b>-META-TAG<\/code>. P\u00ebr t\u2019i ndar\u00eb ato, ne nuk vendos\u00ebm ndonj\u00eb ndar\u00ebs specifik, por thjesht e shtuam vler\u00ebn e nevojshme n\u00eb etiket\u00ebn e imazhit p\u00ebrfundimtar gjat\u00eb publikimit.<\/p>\n

      NB<\/b>: N\u00ebse jeni t\u00eb interesuar t\u00eb shihni gjith\u00e7ka t\u00eb p\u00ebrshkruar n\u00eb kodin burimor t\u00eb werf, pika e nisjes mund t\u00eb jet\u00eb PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      N\u00eb k\u00ebt\u00eb artikull nuk do t'i kushtojm\u00eb m\u00eb shum\u00eb v\u00ebmendje problematik\u00ebs dhe arsyetimit t\u00eb qasjes son\u00eb: mbi strategjit\u00eb e etiketimit, ruajtjes s\u00eb t\u00eb dh\u00ebnave n\u00eb etiketa dhe procesit t\u00eb publikimit n\u00eb t\u00ebr\u00ebsi \u2014 mbi k\u00ebt\u00eb \u00ebsht\u00eb folur n\u00eb holl\u00ebsi n\u00eb raportin e fundit t\u00eb Dmitrij Stolyarov: \"werf \u2014 mjeti yn\u00eb p\u00ebr CI\/CD n\u00eb Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      P\u00ebrmbledhur<\/h2>\n

      \nMungesa e mb\u00ebshtetjes p\u00ebr regjistrat pa hierarki nuk ishte nj\u00eb faktor bllokues p\u00ebr ne ose p\u00ebrdoruesit e njohur t\u00eb werf \u2014 sepse gjithmon\u00eb \u00ebsht\u00eb e mundur t\u00eb ngritni nj\u00eb regjist\u00ebr t\u00eb ve\u00e7ant\u00eb imazhesh (ose t\u00eb kaloni n\u00eb regjistrin e kushteve t\u00eb Container Registry n\u00eb Google Cloud)\u2026 Megjithat\u00eb, heqja e nj\u00eb kufizimi t\u00eb till\u00eb dukej e arsyeshme n\u00eb m\u00ebnyr\u00eb q\u00eb mjeti t\u00eb ishte m\u00eb i p\u00ebrshtatsh\u00ebm p\u00ebr nj\u00eb komunitet m\u00eb t\u00eb gjer\u00eb t\u00eb DevOps. Duke e realizuar at\u00eb, u p\u00ebrball\u00ebm me v\u00ebshtir\u00ebsin\u00eb kryesore n\u00eb p\u00ebrpunimin e mekanizmit t\u00eb pastrimit t\u00eb regjistrit t\u00eb kontejner\u00ebve. Tani, kur gjith\u00e7ka \u00ebsht\u00eb gati, \u00ebsht\u00eb k\u00ebnaq\u00ebsi t\u00eb kuptojm\u00eb se dikujt i \u00ebsht\u00eb b\u00ebr\u00eb m\u00eb e leht\u00eb, dhe ne (si zhvilluesit kryesor\u00eb t\u00eb projektit) nuk parashikojm\u00eb v\u00ebshtir\u00ebsi t\u00eb dukshme n\u00eb mb\u00ebshtetje t\u00eb m\u00ebtejshme t\u00eb k\u00ebsaj funksionaliteti.<\/p>\n

      Q\u00ebndroni me ne dhe shum\u00eb shpejt do t'ju tregojm\u00eb p\u00ebr risit\u00eb e tjera n\u00eb werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nLexoni gjithashtu n\u00eb blogun ton\u00eb:<\/p>\n