{"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\/pl\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Wsparcie dla monorepo i multirepo w werf i jakie ma to znaczenie dla Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wsparcie
\n
\nTemat monorepo by\u0142 ju\u017c wielokrotnie omawiany i zazwyczaj wywo\u0142uje do\u015b\u0107 \u017cywe dyskusje. Tworz\u0105c werf<\/a><\/noindex> jako narz\u0119dzie Open Source, maj\u0105ce na celu ulepszenie proces\u00f3w budowy kodu aplikacji z Git do obraz\u00f3w Docker (i ich p\u00f3\u017aniejszej dostawy do Kubernetes), rzadko zastanawiamy si\u0119, kt\u00f3ry wyb\u00f3r jest lepszy. Najwa\u017cniejsze dla nas jest zapewnienie wszystkiego, co niezb\u0119dne zwolennikom r\u00f3\u017cnych opinii (o ile to nie stoi w sprzeczno\u015bci z rozs\u0105dkiem, oczywi\u015bcie).<\/p>\n

Niedawno wprowadzona obs\u0142uga mono-repo w werf jest dobrym tego przyk\u0142adem. Ale najpierw rozwa\u017cmy, jak ta obs\u0142uga w og\u00f3le wi\u0105\u017ce si\u0119 z u\u017cywaniem werf i co ma wsp\u00f3lnego z Docker Registry\u2026<\/a><\/noindex><\/p>\n

Problematyka<\/h2>\n

\nWyobra\u017amy sobie tak\u0105 sytuacj\u0119. W firmie jest wiele zespo\u0142\u00f3w programistycznych zajmuj\u0105cych si\u0119 niezale\u017cnymi projektami. Wi\u0119kszo\u015b\u0107 aplikacji dzia\u0142a w Kubernetes, a zatem s\u0105 konteneryzowane. Do przechowywania kontener\u00f3w i obraz\u00f3w potrzebny jest rejestr (registry). Jako taki rejestr w firmie u\u017cywany jest Docker Hub z jedynym kontem COMPANY<\/code>. Na podobie\u0144stwo wi\u0119kszo\u015bci system\u00f3w przechowywania kodu \u017ar\u00f3d\u0142owego, Docker Hub nie pozwala na tworzenie zagnie\u017cd\u017conej hierarchii repozytori\u00f3w<\/b>, takiej jak COMPANY\/PROJECT\/IMAGE<\/code>. W takim przypadku\u2026 jak wi\u0119c przechowywa\u0107 w rejestrze aplilacje niemonolityczne, nie tworz\u0105c osobnego konta dla ka\u017cdego projektu? <\/p>\n

\"Wsparcie
\n
\nMo\u017cliwe, \u017ce opisana sytuacja jest komu\u015b znana, ale rozwa\u017cmy temat organizacji przechowywania aplikacji w og\u00f3le, tzn. bez odniesienia do powy\u017cszego przyk\u0142adu i Docker Hub.<\/p>\n

Sposoby rozwi\u0105zania<\/h3>\n

\nJe\u015bli aplikacja jest monolityczna<\/b>, dostarczana w jednym obrazie, to nie ma z tym problem\u00f3w i po prostu zapisujemy obrazy w rejestrze kontener\u00f3w projektu.<\/p>\n

Gdy aplikacja jest przedstawiona w postaci kilku komponent\u00f3w, mikroserwis\u00f3w<\/b>, nale\u017cy wybra\u0107 okre\u015blone podej\u015bcie. Na przyk\u0142adzie typowej aplikacji webowej sk\u0142adaj\u0105cej si\u0119 z dw\u00f3ch obraz\u00f3w: frontend<\/code> i backend<\/code> \u2014 mo\u017cliwe opcje to:<\/p>\n

    \n
  1. Przechowywa\u0107 obrazy w osobnych zagnie\u017cd\u017conych repozytoriach:\n

    \"Wsparcie<\/li>\n

  2. Przechowywa\u0107 wszystko w jednym repozytorium, a nazw\u0119 obrazu uwzgl\u0119dni\u0107 w tagu, na przyk\u0142ad w nast\u0119puj\u0105cy spos\u00f3b:\n

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

    \nNB<\/b>: W og\u00f3le rzecz bior\u0105c, istnieje jeszcze mo\u017cliwo\u015b\u0107 przechowywania w r\u00f3\u017cnych repozytoriach, PROJECT-frontend<\/code> i PROJECT-backend<\/code>, ale nie b\u0119dziemy jej rozwa\u017ca\u0107 ze wzgl\u0119du na trudno\u015bci w utrzymaniu, organizacji i rozdzielaniu uprawnie\u0144 mi\u0119dzy u\u017cytkownikami.<\/i><\/p>\n

    Wsparcie w werf<\/h2>\n

    \nPocz\u0105tkowo werf ogranicza\u0142 si\u0119 do zagnie\u017cd\u017conych repozytori\u00f3w \u2014 na szcz\u0119\u015bcie wi\u0119kszo\u015b\u0107 rejestr\u00f3w wspiera t\u0119 mo\u017cliwo\u015b\u0107. Od wersji v1.0.4-alpha.3<\/a><\/noindex>, dodano obs\u0142ug\u0119 rejestr\u00f3w, w kt\u00f3rych nie wspiera si\u0119 zagnie\u017cd\u017cenia<\/b>, a Docker Hub jest jednym z nich. Od tego momentu u\u017cytkownik ma wyb\u00f3r, jak przechowywa\u0107 obrazy aplikacji.<\/p>\n

    Implementacja jest dost\u0119pna w ramach opcji --images-repo-mode=multirepo|monorepo<\/code> (domy\u015blnie multirepo<\/code>, tj. przechowywanie w zagnie\u017cd\u017conych repozytoriach). Okre\u015bla ona wzorce, wed\u0142ug kt\u00f3rych obrazy s\u0105 przechowywane w rejestrze. Wystarczy wybra\u0107 odpowiedni tryb przy u\u017cyciu podstawowych polece\u0144, a reszta pozostanie niezmieniona.<\/p>\n

    Poniewa\u017c wi\u0119kszo\u015b\u0107 opcji werf mo\u017cna ustawia\u0107 zmiennymi \u015brodowiskowymi<\/b>, w systemach CI\/CD tryb przechowywania, zazwyczaj, mo\u017cna \u0142atwo ustawi\u0107 globalnie dla ca\u0142ego projektu. Na przyk\u0142ad, w przypadku GitLaba<\/b> wystarczy doda\u0107 zmienn\u0105 \u015brodowiskow\u0105 w ustawieniach projektu: Ustawienia -> CI \/ CD -> Zmienne: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Je\u015bli m\u00f3wimy o publikacji obraz\u00f3w i wdra\u017caniu aplikacji (o tych procesach mo\u017cna dok\u0142adniej przeczyta\u0107 w odpowiednich artyku\u0142ach dokumentacji: Proces publikacji<\/a><\/noindex> i Proces wdra\u017cania<\/a><\/noindex>), to tryb jednoznacznie okre\u015bla wzorzec, wed\u0142ug kt\u00f3rego mo\u017cna pracowa\u0107 z obrazem.<\/p>\n

    Diabe\u0142 tkwi w szczeg\u00f3\u0142ach<\/h3>\n

    \nR\u00f3\u017cnica i g\u0142\u00f3wna trudno\u015b\u0107 przy dodawaniu nowego sposobu przechowywania \u2014 to proces czyszczenia registry (mo\u017cliwo\u015bci czyszczenia dost\u0119pne w werf, patrz w Proces czyszczenia<\/a><\/noindex>)<\/i>.<\/p>\n

    Przy czyszczeniu werf bierze pod uwag\u0119 obrazy u\u017cywane w klastrach Kubernetes, a tak\u017ce polityki ustalane przez u\u017cytkownika. Podstaw\u0105 polityk jest rozdzielenie tag\u00f3w na strategie. Strategie obecnie wspierane to:<\/p>\n

      \n
    1. 3 strategie zwi\u0105zane z prymitywami Git, takimi jak tag, ga\u0142\u0105\u017a i commit;<\/li>\n
    2. 1 strategia dla dowolnych, u\u017cytkowniczych tag\u00f3w.<\/li>\n<\/ol>\n

      \nInformacje o strategii tagu przechowujemy przy publikacji obrazu w etykietach ko\u0144cowego obrazu. Sama warto\u015b\u0107 \u2014 tak zwany metatag<\/b> \u2014 jest niezb\u0119dna do stosowania cz\u0119\u015bci polityk. Na przyk\u0142ad, przy usuwaniu ga\u0142\u0119zi lub tagu z repozytorium Git logiczne jest usun\u0105\u0107 tak\u017ce powi\u0105zane niewykorzystywane<\/i> obrazy z rejestru, co jest obj\u0119te cz\u0119\u015bci\u0105 naszych polityk.<\/p>\n

      Przy zachowaniu w jednym repozytorium (monorepo<\/code>), w tagu obrazu, poza metatagiem, mo\u017ce by\u0107 r\u00f3wnie\u017c przechowywana nazwa obrazu: PROJEKT:frontend<\/b>-META-TAG<\/code>. Aby je oddzieli\u0107, nie wprowadzali\u015bmy \u017cadnego specyficznego separatora, tylko dodali\u015bmy niezb\u0119dn\u0105 warto\u015b\u0107 do etykiety ko\u0144cowego obrazu podczas publikacji.<\/p>\n

      NB<\/b>: Je\u015bli chcesz zobaczy\u0107 wszystko, co opisano w kodzie \u017ar\u00f3d\u0142owym werf, punkt wyj\u015bcia mo\u017ce stanowi\u0107 PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      W tym artykule nie b\u0119dziemy po\u015bwi\u0119ca\u0107 wi\u0119cej uwagi problematyce oraz uzasadnieniu naszego podej\u015bcia: na temat strategii tagowania, przechowywania danych w etykietach i procesu publikacji jako ca\u0142o\u015bci \u2014 wszystko to zosta\u0142o szczeg\u00f3\u0142owo opisane w niedawnym wyst\u0105pieniu Dmitrija Stoljarowa: \u201ewerf \u2014 nasze narz\u0119dzie do CI\/CD w Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Podsumowuj\u0105c,<\/h2>\n

      \nBrak wsparcia dla rejestr\u00f3w bez zagnie\u017cd\u017cenia nie stanowi\u0142 dla nas ani dla znanych nam u\u017cytkownik\u00f3w werf czynnika blokuj\u0105cego \u2014 zawsze mo\u017cna by\u0142o utworzy\u0107 oddzielny rejestr obraz\u00f3w (lub przej\u015b\u0107 na tzw. Container Registry w Google Cloud)... Jednak zniesienie takiego ograniczenia wydawa\u0142o si\u0119 logiczne, aby narz\u0119dzie by\u0142o bardziej przyjazne szerszemu spo\u0142eczno\u015bci DevOps. Wprowadzaj\u0105c to, napotkali\u015bmy g\u0142\u00f3wn\u0105 trudno\u015b\u0107 w przetwarzaniu mechanizmu czyszczenia rejestru kontener\u00f3w. Teraz, gdy wszystko jest gotowe, mi\u0142o jest wiedzie\u0107, \u017ce komu\u015b sta\u0142o si\u0119 \u0142atwiej, a my (jako g\u0142\u00f3wni programi\u015bci projektu) nie przewidujemy znacz\u0105cych trudno\u015bci w dalszym wsparciu tej funkcji.<\/p>\n

      Pozosta\u0144 z nami, a wkr\u00f3tce opowiemy o innych nowo\u015bciach w werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n