Temat monorepozytorium był poruszany nie raz i z reguły budzi bardzo żywe kontrowersje. Tworząc jako narzędzie typu open source zaprojektowane w celu usprawnienia procesu budowania kodu aplikacji z obrazów Git do Docker (a następnie dostarczania ich do Kubernetes), nie zastanawiamy się zbytnio nad tym, który wybór jest najlepszy. Dla nas najważniejsze jest zapewnienie wszystkiego, co niezbędne dla zwolenników odmiennych poglądów (oczywiście, jeśli nie jest to sprzeczne ze zdrowym rozsądkiem).
Niedawne wsparcie mono-repo przez werf jest tego dobrym przykładem. Ale najpierw zastanówmy się, jak ogólnie ta obsługa jest powiązana z używaniem werf i co ma z tym wspólnego Rejestr Dockera…
Problemy
Wyobraźmy sobie taką sytuację. Firma posiada wiele zespołów programistycznych pracujących nad niezależnymi projektami. Większość aplikacji działa na platformie Kubernetes i dlatego jest konteneryzowana. Do przechowywania kontenerów, obrazów potrzebny jest rejestr (rejestr). Jako taki rejestr firma używa Docker Hub z jednym kontem COMPANY. Podobnie jak większość systemów przechowywania kodu źródłowego, Docker Hub nie zezwala na zagnieżdżoną hierarchię repozytoriów, Jak na przykład COMPANY/PROJECT/IMAGE. W takim razie… jak można przechowywać w rejestrze niemonolityczne aplikacje z takim ograniczeniem bez tworzenia osobnego konta dla każdego projektu?
Być może opisana sytuacja jest komuś znana z pierwszej ręki, ale rozważmy ogólnie kwestię organizacji przechowywania aplikacji, tj. bez odniesienia do powyższego przykładu i Docker Hub.
Rozwiązania
Jeśli aplikacja monolityczny, jest w jednym obrazie, nie ma żadnych pytań i po prostu zapisujemy obrazy w rejestrze kontenerów projektu.
Gdy aplikacja jest prezentowana jako wiele komponentów, mikroserwisy, to wymagane jest pewne podejście. Na przykładzie typowej aplikacji internetowej składającej się z dwóch obrazów: frontend и backend - możliwe opcje to:
- Przechowuj obrazy w oddzielnych zagnieżdżonych repozytoriach:
- Przechowuj wszystko w jednym repozytorium i weź pod uwagę nazwę obrazu w tagu, na przykład w następujący sposób:
NB: Właściwie istnieje inna opcja zapisywania w różnych repozytoriach, PROJECT-frontend и PROJECT-backend, ale nie będziemy tego rozważać ze względu na złożoność obsługi, organizacji i dystrybucji uprawnień między użytkownikami.
wsparcie werf
Początkowo werf ograniczał się do zagnieżdżonych repozytoriów - na szczęście większość rejestrów obsługuje tę funkcję. Począwszy od wersji , dodano pracę z rejestrami, w których zagnieżdżanie nie jest obsługiwane, a Docker Hub jest jednym z nich. Od tego momentu użytkownik ma wybór sposobu przechowywania obrazów aplikacji.
Wdrożenie dostępne w opcji --images-repo-mode=multirepo|monorepo (domyślny multirepo, tj. przechowywanie w zagnieżdżonych repozytoriach). Definiuje wzorce, według których obrazy są przechowywane w rejestrze. Wystarczy wybrać żądany tryb podczas korzystania z podstawowych poleceń, a wszystko inne pozostanie niezmienione.
Ponieważ większość opcji werf można ustawić Zmienne środowiska, w systemach CI/CD tryb przechowywania jest zazwyczaj łatwy do ustawienia globalnie dla całego projektu. Na przykład, w przypadku GitLaba po prostu dodaj zmienną środowiskową w ustawieniach projektu: Ustawienia -> CI/CD -> Zmienne: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Jeśli mówimy o publikowaniu obrazów i wdrażaniu aplikacji (szczegółowe informacje na temat tych procesów można znaleźć w odpowiednich artykułach dokumentacji: и ), wówczas tryb określa wyłącznie szablon, według którego można pracować z obrazem.
Diabeł tkwi w szczegółach
Różnica i główna trudność podczas dodawania nowej metody przechowywania polega na czyszczeniu rejestru (aby zapoznać się z funkcjami czyszczenia obsługiwanymi przez werf, zobacz ).
Podczas czyszczenia werf bierze pod uwagę obrazy używane w klastrach Kubernetes, a także polityki skonfigurowane przez użytkownika. Polityki opierają się na podziale tagów na strategie. Obecnie obsługiwane strategie:
- 3 strategie połączone przez prymitywy Git, takie jak tag, branch i commit;
- 1 strategia dla dowolnych niestandardowych tagów.
Zapisujemy informacje o strategii tagowania podczas publikowania obrazu w etykietach ostatecznego obrazu. Samo znaczenie to tzw znacznik meta - Wymagane do zastosowania niektórych zasad. Na przykład podczas usuwania gałęzi lub tagu z repozytorium Git logiczne jest usunięcie powiązanych nie używany obrazów z rejestru, co jest objęte częścią naszych zasad.
Po zapisaniu w jednym repozytorium (monorepo), w tagu obrazu, oprócz metatagu, można również zapisać nazwę obrazu: PROJECT:frontend-META-TAG. Aby je rozdzielić, nie wprowadziliśmy żadnego specjalnego separatora, ale po prostu dodaliśmy niezbędną wartość do etykiety końcowego obrazu podczas publikacji.
NB: Jeśli jesteś zainteresowany spojrzeniem na wszystko opisane w kodzie źródłowym werf, to punkt wyjścia może być .
W tym artykule nie będziemy zwracać większej uwagi na problemy i uzasadnienie naszego podejścia: na temat strategii tagowania, przechowywania danych w etykietach i procesu wydawniczego jako całości - wszystko to zostało szczegółowo opisane w niedawnym raporcie Dmitrija Stolyarova: „".
Podsumowanie
Brak obsługi niezagnieżdżonych rejestrów nie był czynnikiem blokującym ani dla nas, ani dla znanych nam użytkowników werf – wszak zawsze można założyć osobny rejestr obrazu (lub przełączyć się na warunkowy Container Registry w Google Cloud)… Jednak usunięcie takiego ograniczenia wydawało się logiczne, aby narzędzie było wygodniejsze dla szerszej społeczności DevOps. Wdrażając go, napotkaliśmy główną trudność polegającą na przerobieniu mechanizmu czyszczenia rejestru kontenerów. Teraz, gdy wszystko jest gotowe, miło jest zdać sobie sprawę, że stało się to dla kogoś łatwiejsze, a my (jako główni twórcy projektu) nie będziemy mieć żadnych zauważalnych trudności w dalszym wspieraniu tej funkcji.
Zostań z nami, a już wkrótce opowiemy Ci o innych innowacjach w !
PS
Przeczytaj także na naszym blogu:
- «";
- «".
Źródło: www.habr.com
