{"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 oraz powi\u0105zanie z Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Nowo wprowadzona obs\u0142uga mono-repo w werf jest dobrym tego przyk\u0142adem. Ale najpierw zastan\u00f3wmy si\u0119, jak to wsparcie jest zwi\u0105zane z u\u017cywaniem werf oraz jakie ma to powi\u0105zanie 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 Kubernetesie, a wi\u0119c s\u0105 konteneryzowane. Aby przechowywa\u0107 kontenery i obrazy, potrzebny jest rejestr (registry). Jako taki rejestr w firmie wykorzystywany jest Docker Hub z jednym kontem. FIRMA<\/code>. Podobnie jak w 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 FIRMA\/PROJEKT\/OBRAZ<\/code>. W takim przypadku\u2026 jak poradzi\u0107 sobie z tym ograniczeniem przy przechowywaniu nierelacyjnych aplikacji w rejestrze, nie tworz\u0105c oddzielnego konta dla ka\u017cdego projektu? <\/p>\n

\"Wsparcie
\n
\nMo\u017cliwe, \u017ce opisana sytuacja jest komu\u015b dobrze znana, ale zastan\u00f3wmy si\u0119 nad organizacj\u0105 przechowywania aplikacji w og\u00f3le, tj. bez odniesienia do powy\u017cszego przyk\u0142adu i Docker Hub.<\/p>\n

Mo\u017cliwo\u015bci rozwi\u0105zania<\/h3>\n

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

Kiedy aplikacja jest reprezentowana przez kilka komponent\u00f3w, mikroserwis\u00f3w<\/b>, konieczne jest wybranie odpowiedniego podej\u015bcia. Na przyk\u0142adzie typowej aplikacji webowej sk\u0142adaj\u0105cej si\u0119 z dw\u00f3ch obraz\u00f3w: frontend<\/code> i backend<\/code> \u2014 mo\u017cliwe warianty to:<\/p>\n

    \n
  1. Przechowywanie obraz\u00f3w w oddzielnych zagnie\u017cd\u017conych repozytoriach:\n

    \"Wsparcie<\/li>\n

  2. Przechowywanie wszystkiego w jednym repozytorium, a nazwa obrazu jako tag, na przyk\u0142ad, w nast\u0119puj\u0105cy spos\u00f3b:\n

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

    \nNB<\/b>: W\u0142a\u015bciwie jest jeszcze opcja z przechowywaniem w r\u00f3\u017cnych repozytoriach, PROJEKT-frontend<\/code> i PROJEKT-backend<\/code>, ale nie b\u0119dziemy go rozwa\u017ca\u0107 z powodu z\u0142o\u017cono\u015bci wsparcia, organizacji i przydzielania uprawnie\u0144 mi\u0119dzy u\u017cytkownikami.<\/i><\/p>\n

    Wsparcie w werf<\/h2>\n

    \nPocz\u0105tkowo werf ogranicza\u0142 si\u0119 do repozytori\u00f3w zagnie\u017cd\u017conych \u2014 na szcz\u0119\u015bcie wi\u0119kszo\u015b\u0107 rejestr\u00f3w wspiera t\u0119 funkcjonalno\u015b\u0107. Od wersji v1.0.4-alpha.3<\/a><\/noindex>, dodano obs\u0142ug\u0119 rejestr\u00f3w, w kt\u00f3rych nie jest wspierana zagnie\u017cd\u017cono\u015b\u0107<\/b>, w tym Docker Hub. Od tego momentu u\u017cytkownik zyska\u0142 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>, tzn. 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 podczas u\u017cycia g\u0142\u00f3wnych polece\u0144, a wszystko inne pozostanie bez zmian.<\/p>\n

    Poniewa\u017c wi\u0119kszo\u015b\u0107 opcji werf mo\u017cna ustawi\u0107 zmiennymi \u015brodowiskowymi<\/b>, w systemach CI\/CD tryb przechowywania mo\u017cna zazwyczaj \u0142atwo ustawi\u0107 globalnie dla ca\u0142ego projektu. Na przyk\u0142ad, w przypadku GitLab<\/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 chodzi o publikacj\u0119 obraz\u00f3w i wdra\u017canie aplikacji (o tych procesach mo\u017cna przeczyta\u0107 w odpowiednich artyku\u0142ach dokumentacji: Proces publikacji<\/a><\/noindex> i Proces wdra\u017cania<\/a><\/noindex>), to tryb okre\u015bla szablon, 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 polega na procesie czyszczenia rejestru (mo\u017cliwo\u015bci czyszczenia wspierane w werf, patrz Proces czyszczenia<\/a><\/noindex>)<\/i>.<\/p>\n

    Podczas czyszczenia werf uwzgl\u0119dnia obrazy u\u017cywane w klastrach Kubernetes, a tak\u017ce polityki ustalane przez u\u017cytkownika. W podstawie polityk le\u017cy podzia\u0142 tag\u00f3w na strategie. Strategie aktualnie wspierane to:<\/p>\n

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

      \nInformacje o strategii taga przechowujemy podczas publikacji obrazu w etykietach ko\u0144cowego obrazu. Samo znaczenie \u2013 tzw. metatag<\/b> \u2013 jest niezb\u0119dne do zastosowania cz\u0119\u015bci polityk. Na przyk\u0142ad przy usuwaniu ga\u0142\u0119zi lub taga z repozytorium Git logiczne jest usuni\u0119cie r\u00f3wnie\u017c powi\u0105zanych nieu\u017cywanych<\/i> obraz\u00f3w z rejestru, co jest obj\u0119te cz\u0119\u015bci\u0105 naszych polityk.<\/p>\n

      Podczas przechowywania w jednym repozytorium (monorepo<\/code>), w tagu obrazu, opr\u00f3cz metatagu, mo\u017ce by\u0107 r\u00f3wnie\u017c przechowywana nazwa obrazu: PROJEKT:frontend<\/b>-META-TAG<\/code>. Aby je oddzieli\u0107, nie wprowadzili\u015bmy \u017cadnego specyficznego separatora, lecz po prostu dodali\u015bmy potrzebn\u0105 warto\u015b\u0107 do etykiety ko\u0144cowego obrazu przy publikacji.<\/p>\n

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

      W tym artykule nie po\u015bwi\u0119cimy wi\u0119cej uwagi problematyce i uzasadnieniu naszego podej\u015bcia: o strategiach tagowania, przechowywaniu danych w etykietach oraz o procesie publikacji w ca\u0142o\u015bci \u2014 szczeg\u00f3\u0142owo opisano to 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\u017ce\u0144 nie by\u0142 czynnikiem blokuj\u0105cym dla nas ani dla znanych nam u\u017cytkownik\u00f3w werf \u2014 zawsze mo\u017cna podnie\u015b\u0107 oddzielny rejestr obraz\u00f3w (lub przej\u015b\u0107 na tzw. Container Registry w Google Cloud)\u2026 Jednak zniesienie takiego ograniczenia wydawa\u0142o si\u0119 logiczne, aby narz\u0119dzie by\u0142o bardziej przyjazne dla szerszej spo\u0142eczno\u015bci DevOps. Realizuj\u0105c to, napotkali\u015bmy g\u0142\u00f3wny problem z przetwarzaniem mechanizmu czyszczenia rejestru kontener\u00f3w. Teraz, kiedy wszystko jest gotowe, cieszy nas, \u017ce komu\u015b jest \u0142atwiej, a my (jako g\u0142\u00f3wni deweloperzy projektu) nie przewidujemy znacz\u0105cych trudno\u015bci w dalszym wsparciu tej funkcji.<\/p>\n

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

      P.S.<\/h2>\n

      \nPrzeczytaj r\u00f3wnie\u017c na naszym blogu:<\/p>\n