W tym artykule skupię się na ArgoCD Multi-Repo, czyli istotnym temacie radzenia sobie z rosnącą konfiguracją klastrów w środowisku ArgoCD. Pokazuję koncepcję zarządzania tym rosnącym zasobem poprzez wykorzystanie większej liczby repozytoriów git, co pozwala na bardziej efektywne i zorganizowane zarządzanie konfiguracją.
Zagadnienia omawiane:
- Zalety korzystania z wielu repozytoriów (ArgoCD Multi-Repo)
- Strategie zarządzania konfiguracją ArgoCD Multi-Repo
- Konfiguracja ArgoCD do obsługi wielu repozytoriów
- Łącznie konfiguracji w ramach jednej aplikacji ArgoCD
Wprowadzenie
ArgoCD to narzędzie do zarządzania aplikacjami na klastrach Kubernetes, które korzysta z podejścia GitOps, ułatwiając automatyzację wdrożeń i monitorowanie stanu aplikacji. O ArgoCD pisałem więcej w jednym z poprzednich artykułów (ArgoCD – Zarządzanie aplikacjami z wielu klastrów w jednym miejscu). Zarządzanie konfiguracją klastrów Kubernetes w środowiskach wieloklastrowych często stanowi wyzwanie dla zespołów DevOps. Podział rosnącej konfiguracji na wiele repozytoriów może być rozwiązaniem tego problemu.
Zalety korzystania z ArgoCD Multi-Repo
Zarządzanie konfiguracją klastrów Kubernetes za pomocą wielu repozytoriów ma wiele zalet:
- Izolacja i bezpieczeństwo: Oddzielne repozytoria pozwalają na lepszą kontrolę dostępu i zarządzanie uprawnieniami. Na przykład, różne zespoły mogą mieć dostęp do różnych repozytoriów, zgodnie z ich rolami i uprawnieniami.
- Modularność: Konfiguracje można podzielić na mniejsze, łatwiejsze do zarządzania moduły, co ułatwia ich utrzymanie i rozwój. Na przykład, konfiguracje związane z bazą danych mogą być przechowywane w jednym repozytorium, a konfiguracje związane z front-endem w innym.
- Skalowalność: Ułatwia zarządzanie dużą liczbą aplikacji i klastrów. Na przykład, różne projekty mogą mieć swoje własne repozytoria, co pozwala na łatwe zarządzanie i rozwijanie każdego z nich niezależnie.
- Wersjonowanie: Umożliwia lepsze śledzenie zmian i umożliwia powrót do poprzednich wersji w przypadku problemów z częścią konfiguracji.
- Ciągłość pracy: Dzięki izolacji konfiguracji, problemy z jednym modułem nie zakłócają pracy nad pozostałymi.
- Przejrzystość: Każde repozytorium jest dedykowane do konkretnego celu, co ułatwia zrozumienie struktury i celu konfiguracji. Na przykład, repozytorium o nazwie “database” jasno wskazuje, że zawiera konfiguracje związane z bazą danych.
Strategie zarządzania konfiguracją ArgoCD Multi-Repo
Jedno repozytorium na projekt
W tej strategii każdy projekt posiada jedno repozytorium zawierające zarówno kod aplikacji, jak i konfigurację klastrów. Jest to podejście najprostsze, ale jednocześnie najmniej zalecane.
Zalety:
- Prostota zarządzania jednym repozytorium na projekt.
- Łatwość śledzenia zmian w kodzie i konfiguracji w danym projekcie.
Wady:
- Trudność w skalowaniu przy dużych projektach.
- Możliwe konflikty między zespołami programistycznymi a zespołami DevOps.
Repozytorium per projekt z kodem i jedno na konfigurację ArgoCD
W tej strategii każdy projekt posiada swoje repozytorium z kodem, a konfiguracje ArgoCD są przechowywane w osobnym, centralnym repozytorium.
Zalety:
- Poprawa modularności oraz izolacja kodu od konfiguracji.
- Centralne zarządzanie konfiguracją za pomocą ArgoCD.
Wady:
- Zwiększona złożoność procesu wdrożeniowego z powodu rozproszenia konfiguracji.
- Brak oddzielenia konfiguracji klastrów dla poszczególnych projektów.
Jest to najprostsze podejście, gdy chcemy oddzielić kod projektu od konfiguracji klastra.
Dwa repozytoria na projekt (dev + konfiguracja klastra)
W tej strategii każdy projekt posiada dwa repozytoria: jedno na kod aplikacji (dev) i drugie na konfigurację klastra.
Zalety:
- Lepsza separacja kodu od konfiguracji.
- Izolacja konfiguracji klastrów dla poszczególnych projektów.
Wady:
- Większa liczba repozytoriów do zarządzania.
- Zwiększona złożoność procesu wdrożeniowego z powodu rozproszenia konfiguracji.
To jest najprostsze rozwiązanie, gdy chcemy oddzielić kod projektu od konfiguracji klastra, a także izolować konfigurację klastrów między projektami.
Wspólna konfiguracja i dwa repozytoria na projekt
W tej strategii konfiguracja wspólna dla wszystkich projektów jest przechowywana w oddzielnym repozytorium, a każdy projekt posiada dwa repozytoria: jedno na kod aplikacji (dev) i drugie na konfigurację klastra.
Zalety:
- Centralizacja i izolacja wspólnej konfiguracji.
- Wyższa modularność i oddzielenie kodu od konfiguracji.
Wady:
- Konieczność zarządzania większą liczbą repozytoriów.
- Zwiększona złożoność procesu wdrożeniowego ze względu na rozproszenie konfiguracji.
To rozwiązanie jest dobre, gdy mamy wiele powtarzającej się konfiguracji między projektami, które chcemy uwspólnić, oraz gdy mamy część konfiguracji niezwiązaną z żadnym projektem, na przykład związanej z monitorowaniem klastrów.
Wspólna konfiguracja dla organizacji, repozytorium dla klientów i dwa repozytoria na projekt
W tej strategii konfiguracja wspólna dla całej organizacji jest przechowywana w oddzielnym repozytorium, każde repozytorium dla klientów zawiera oddzielną konfigurację klastra, a każdy projekt posiada dwa repozytoria: jedno na kod aplikacji (dev) i drugie na konfigurację klastra.
Zalety:
- Centralne zarządzanie konfiguracją organizacji.
- Poprawa modularności i oddzielenie kodu od konfiguracji.
- Możliwość dostosowania konfiguracji dla różnych klientów.
Wady:
- Duża liczba repozytoriów do zarządzania.
- Zwiększona złożoność procesu wdrożeniowego z powodu rozproszenia konfiguracji.
Mimo że jest to podejście skomplikowane, umożliwia nam to organizację konfiguracji w dużych organizacjach. Pozwala na współdzielenie części konfiguracji per klient i per projekt, a także na utrzymanie oddzielnej konfiguracji dla każdego klienta.
Konfiguracja ArgoCD Multi-Repo do obsługi wielu repozytoriów
Dodawanie kolejnych repozytoriów do nasłuchiwania przez ArgoCD może być przeprowadzone na dwa sposoby: za pośrednictwem interfejsu użytkownika (UI) lub poprzez linię poleceń (CLI).
Konfiguracja za pośrednictwem UI
Proces ten jest naprawdę prosty, ponieważ składa się tak naprawdę tylko z 3 kroków:
- Przechodzimy do zakładki Settings/Repositories
- Dodajemy połączenie, klikając przycisk +Connect repo.
- Wprowadzamy dane i klikamy przecisk Connect.
Konfiguracja za pośrednictwem CLI
Po pierwsze, musimy oczywiście mieć zainstalowane CLI na maszynie, z której będziemy dodawać repozytorium. Poniżej znajduje się link do strony, zawierającej wszystkie niezbędne informacje na temat instalacji CLI: https://argo-cd.readthedocs.io/en/stable/cli_installation/.
Po zalogowaniu do odpowiedniej instancji ArgoCD, dodanie kolejnego repozytorium sprowadza się do wykonania dwóch kroków:
- Dodanie danych autoryzacyjnych
argocd repocreds add https://wkontenerach/repos –username test –password test
- Dodanie repozytorium
argocd repo add https://wkontenerach/repos/argocd-example-apps
Użycie dodanego repozytorium
Możemy użyć dodanego repozytorium na dwa sposoby w naszej aplikacji ArgoCD. Możemy wybrać repozytorium w interfejsie użytkownika lub w konfiguracji deklaratywnej wybranej aplikacji.
Konfiguracja w UI:
Konfiguracja w yaml:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-test
spec:
destination:
namespace: default
server: <https://kubernetes.default.svc>
project: default
source:
path: app-test
repoURL: <https://wkontenerach/repos/argocd-example-apps>
targetRevision: HEADW obu przypadkach, oprócz podania adresu URL do danego repozytorium, istotnym elementem jest ścieżka w ramach tego repozytorium. Ta ścieżka prowadzi do konfiguracji określonej aplikacji, jeśli przechowujemy wiele konfiguracji w jednym repozytorium.
Łącznie konfiguracji w ramach jednej aplikacji ArgoCD
Istotnym punktem rozpraszania konfiguracji na wiele repozytorium jest współdzielenie części konfiguracji pomiędzy kilka aplikacji. ArgoCD daje nam taką możliwość przy podejściu deklaratywnym poprzez podanie kilku repozytoriów jako źródło aplikacji.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-billing-app
namespace: argocd
spec:
project: default
destination:
server: <https://kubernetes.default.svc>
namespace: default
sources:
- repoURL: https://github.com/wkontenerach/shared
path: config
targetRevision: HEAD
- repoURL: https://wkontenerach/repos/argocd-example-apps
path: app-test
targetRevision: HEADTa funkcjonalność umożliwia nam posiadanie indywidualnej konfiguracji w ramach aplikacji. Możemy również korzystać z konfiguracji dla określonego klienta lub całej organizacji bez potrzeby dodatkowej synchronizacji.
⚠️ Jest to funkcjonalność w fazie Beta w momencie pisania tego artykułu. Aktualny stan funkcjonalności można znaleźć pod adresem: https://argo-cd.readthedocs.io/en/stable/user-guide/multiple_sources/
Podsumowanie
ArgoCD oferuje efektywne rozwiązania do zarządzania konfiguracją klastrów Kubernetes za pomocą wielu repozytoriów. Dzięki temumożemy odizolować poszczególne projekty i klientów poprzez podział konfiguracji na różne repozytoria. Taki zabieg jest pomocny nie tylko w organizacji pracy i jej współdzieleniu, ale także w zwiększeniu bezpieczeństwa pracy nad danym projektem w kontekście rosnącej skali organizacji. Dodatkowo to podejście nie ogranicza nas w kwestii współdzielenia konfiguracji w ramach jednego repozytorium, na przykład poprzez Kustomize, lub wyizolowania do Helm Chartów. Wiele repozytoriów daje nam dodatkowe możliwości w kwestii organizacji i zabezpieczenia naszej konfiguracji.
Autor
Emil Juchnikowski — pracuje jako Architekt Oprogramowania. Swoją karierę rozpoczął jako .NET Developer ponad 10 lat temu. Teraz już z technologią .NET ma bardzo mało wspólnego. Rozwija się w technologiach JS, w różnych kierunkach: frontend Angular i Ionic, backend NodeJS i NestJS, bazy danych MongoDB. Poza tym zajmuje się też zagadnieniami DevOps, GitOps opartymi o konteneryzację w Kubernetes. Poza pracą lubi biegać na długie dystanse oraz trenuje boks. Jego motto to: Jedynym ograniczeniem jest nasza wyobraźnia… a niektórzy twierdzą, że jeszcze czas i pieniądze.
