{"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\/ro\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Suport pentru monorepo \u0219i multirepo \u00een werf \u0219i ce leg\u0103tur\u0103 are cu Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Suport
\n
\nTema monorepo-ului a fost discutat\u0103 de mai multe ori \u0219i, de regul\u0103, st\u00e2rne\u0219te dispute foarte active. C\u00e2nd cre\u0103m werf<\/a><\/noindex> un instrument Open Source destinat \u00eembun\u0103t\u0103\u021birii proceselor de construire a codului aplica\u021biilor din Git \u00een imagini Docker (\u0219i livrarea lor ulterioar\u0103 \u00een Kubernetes), rareori ne g\u00e2ndim la alegerea optim\u0103. Pentru noi, este esen\u021bial s\u0103 asigur\u0103m tot ce este necesar sus\u021bin\u0103torilor diferitelor opinii (dac\u0103 nu contravine bunului sim\u021b, desigur).<\/p>\n

Sprijinul recent ap\u0103rut pentru mono-repo \u00een werf este un bun exemplu \u00een acest sens. Dar, mai \u00eent\u00e2i, s\u0103 analiz\u0103m cum este legat acest sprijin de utilizarea werf \u0219i ce leg\u0103tur\u0103 are cu Docker Registry...<\/a><\/noindex><\/p>\n

Problematica<\/h2>\n

\nS\u0103 ne imagin\u0103m o situa\u021bie. \u00cen companie exist\u0103 numeroase echipe de dezvoltatori care lucreaz\u0103 la proiecte independente. Majoritatea aplica\u021biilor func\u021bioneaz\u0103 \u00een Kubernetes, a\u0219adar - sunt containerizate. Pentru stocarea containerelor, imaginilor, este necesar un registru. Ca registru, compania folose\u0219te Docker Hub cu un singur cont COMPANY<\/code>. La fel ca \u00een majoritatea sistemelor de stocare a codului surs\u0103, Docker Hub nu permite crearea unei ierarhii de registre \u00eennodat\u0103<\/b>, cum ar fi COMPANY\/PROJECT\/IMAGE<\/code>. \u00cen acest caz\u2026 cum putem stoca aplica\u021biile nemonolitice \u00een registru, f\u0103r\u0103 a crea un cont separat pentru fiecare proiect? <\/p>\n

\"Suport
\n
\nPoate c\u0103 situa\u021bia descris\u0103 este cunoscut\u0103 unor persoane, dar s\u0103 analiz\u0103m \u00eentrebarea organiz\u0103rii stoc\u0103rii aplica\u021biilor \u00een general, adic\u0103 f\u0103r\u0103 a face referire la exemplul de mai sus \u0219i Docker Hub.<\/p>\n

Modalit\u0103\u021bi de solu\u021bie<\/h3>\n

\nDac\u0103 aplica\u021bia este monolitic\u0103<\/b>, livrat\u0103 \u00eentr-o singur\u0103 imagine, atunci nu sunt \u00eentreb\u0103ri \u0219i pur \u0219i simplu salv\u0103m imaginile \u00een registrul containerelor proiectului.<\/p>\n

C\u00e2nd aplica\u021bia este reprezentat\u0103 prin mai multe componente, microservicii<\/b>, este necesar s\u0103 alegem o abordare specific\u0103. De exemplu, pentru o aplica\u021bie web tipic\u0103, format\u0103 din dou\u0103 imagini: frontend<\/code> \u0219i backend<\/code> \u2014 variantele posibile sunt:<\/p>\n

    \n
  1. A p\u0103stra imaginile \u00een registre \u00eennodat\u0103 separate:\n

    \"Suport<\/li>\n

  2. A p\u0103stra totul \u00eentr-un singur registru, iar numele imaginii s\u0103 fie luat \u00een considerare \u00een tag, de exemplu, astfel:\n

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

    \nNB<\/b>: De fapt, mai exist\u0103 o variant\u0103 cu p\u0103strarea \u00een diferite registre, PROJECT-frontend<\/code> \u0219i PROJECT-backend<\/code>, dar aceasta nu va fi tratat\u0103 din cauza complexit\u0103\u021bii \u00eentre\u021binerii, organiz\u0103rii \u0219i distribuirii drepturilor \u00eentre utilizatori.<\/i><\/p>\n

    Sprijinul \u00een werf<\/h2>\n

    \nIni\u021bial, werf s-a limitat la depozitele \u00eencorporate \u2014 fiindc\u0103 majoritatea registrelor suport\u0103 aceast\u0103 op\u021biune. \u00cencep\u00e2nd cu versiunea v1.0.4-alpha.3<\/a><\/noindex>, a fost ad\u0103ugat\u0103 lucrul cu registe care nu suport\u0103 ierarhii<\/b>, printre care se num\u0103r\u0103 \u0219i Docker Hub. De la acest moment, utilizatorul a avut posibilitatea de a alege cum s\u0103 stocheze imaginile aplica\u021biei.<\/p>\n

    Implementarea este disponibil\u0103 \u00een cadrul op\u021biunii --images-repo-mode=multirepo|monorepo<\/code> \uff08implicit multirepo<\/code>, adic\u0103 stocare \u00een depozite \u00eencorporate). Aceasta define\u0219te \u0219abloanele conform c\u0103rora imaginile sunt stocate \u00een registru. Este suficient s\u0103 alegi modul dorit atunci c\u00e2nd folose\u0219ti comenzile de baz\u0103, iar tot restul va r\u0103m\u00e2ne neschimbat.<\/p>\n

    Deoarece majoritatea op\u021biunilor werf pot fi setate prin variabile de mediu<\/b>, \u00een sistemele CI\/CD, modul de stocare poate fi setat \u00een general global pentru \u00eentregul proiect. De exemplu, \u00een cazul GitLab<\/b> , este suficient s\u0103 adaugi o variabil\u0103 de mediu \u00een set\u0103rile proiectului: Settings -> CI \/ CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    C\u00e2nd vine vorba de publicarea imaginilor \u0219i de desf\u0103\u0219urarea aplica\u021biilor (despre aceste procese po\u021bi citi \u00een detaliu \u00een articolele corespunz\u0103toare din documenta\u021bie: Publicare proces<\/a><\/noindex> \u0219i Desf\u0103\u0219urare proces<\/a><\/noindex>), modul determin\u0103 exclusiv \u0219ablonul conform c\u0103ruia se poate lucra cu imaginea.<\/p>\n

    Diavolul se afl\u0103 \u00een detalii<\/h3>\n

    \nDiferen\u021ba \u0219i dificultatea principal\u0103 \u00een ad\u0103ugarea unui nou mod de stocare este \u00een procesul de cur\u0103\u021bare a registry-ului (posibilit\u0103\u021bile de cur\u0103\u021bare suportate \u00een werf, vezi \u00een Proces de cur\u0103\u021bare<\/a><\/noindex>)<\/i>.<\/p>\n

    La cur\u0103\u021bare, werf ia \u00een considerare imaginile utilizate \u00een clusterele Kubernetes, precum \u0219i politicile configurate de utilizator. La baza politicilor se afl\u0103 \u00eemp\u0103r\u021birea etichetelor \u00een strategii. Strategiile sus\u021binute \u00een prezent sunt:<\/p>\n

      \n
    1. 3 strategii legate de primitivele Git, cum ar fi eticheta, ramura \u0219i commit-ul;<\/li>\n
    2. 1 strategie pentru etichete personalizate arbitrare.<\/li>\n<\/ol>\n

      \nInforma\u021biile despre strategia etichetei sunt p\u0103strate la publicarea imaginii \u00een etichetele imaginii finale. Valoarea \u00een sine \u2014 a\u0219a-numita metatag<\/b> \u2014 este necesar\u0103 pentru aplicarea unor politici. De exemplu, \u00een cazul \u0219tergerii unei ramuri sau a unei etichete din registrul Git, este logic s\u0103 \u0219tergi \u0219i imaginele asociate neutilizate<\/i> din registru, ceea ce este acoperit de o parte din politicile noastre.<\/p>\n

      C\u00e2nd se salveaz\u0103 \u00eentr-un singur registru (monorepo<\/code>), \u00een eticheta imaginii, pe l\u00e2ng\u0103 metatag, poate fi stocat \u0219i numele imaginii: PROIECT:frontend<\/b>-META-TAG<\/code>. Pentru a le separa, nu am introdus un separator specific, ci am ad\u0103ugat pur \u0219i simplu valoarea necesar\u0103 \u00een eticheta imaginii finale la publicare.<\/p>\n

      NB<\/b>: Dac\u0103 sunte\u021bi interesat s\u0103 vizualiza\u021bi tot ce este descris \u00een codul surs\u0103 werf, un punct de plecare poate fi PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      \u00cen acest articol nu ne vom concentra mai mult asupra problematicii \u0219i justific\u0103rii abord\u0103rii noastre: despre strategiile de etichetare, stocarea datelor \u00een etichete \u0219i procesul de publicare \u00een ansamblu \u2014 despre toate acestea s-a discutat detaliat \u00een raportul recent al lui Dmitri Stoliarov: \u201ewerf \u2014 instrumentul nostru pentru CI\/CD \u00een Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      \u00cen concluzie<\/h2>\n

      \nLipsa suportului pentru registre f\u0103r\u0103 pozi\u021bionare nu a fost un factor blocant pentru noi sau pentru utilizatorii cunoscu\u021bi ai werf \u2014 deoarece \u00eentotdeauna este posibil s\u0103 ridica\u021bi un registru distinct de imagini (sau s\u0103 trece\u021bi la un registru de containere \u00een Google Cloud)\u2026 Cu toate acestea, eliminarea unei astfel de restric\u021bii p\u0103rea logic\u0103 pentru a face instrumentul mai accesibil unei comunit\u0103\u021bi DevOps mai largi. Implement\u00e2nd-o, ne-am confruntat cu principala dificultate \u00een reproiectarea mecanismului de cur\u0103\u021bare a registrului de containere. Acum, c\u00e2nd totul este preg\u0103tit, este pl\u0103cut s\u0103 realiz\u0103m c\u0103 cuiva i-a fost mai u\u0219or, iar noi (ca dezvoltatori principali ai proiectului) nu ne a\u0219tept\u0103m la dificult\u0103\u021bi semnificative \u00een suportul ulterior al acestei caracteristici.<\/p>\n

      R\u0103m\u00e2ne\u021bi cu noi \u0219i \u00een cur\u00e2nd v\u0103 vom povesti despre alte nout\u0103\u021bi \u00een werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n