GitOps z Argo CD na Kubernetes w NSIS
Argo CD to narzędzie do ciągłego wdrażania dla Kubernetes, zaprojektowane z myślą o zasadach GitOps i Infrastructure as Code (IaC). Automatycznie zapewnia, że stan aplikacji wdrożonych na klastrze Kubernetes jest zawsze zsynchronizowany z dedykowanym repozytorium Git, w którym jest definiowany taki pożądany stan.
W tym artykule pokażemy, jak zainstalować Argo CD w klastrze Kubernetes i wdrożyć aplikację przy użyciu tego narzędzia.
Co zostanie omówione?
Instalacja Argo CD
Dostęp do Argo CD z poziomu przeglądarki
Utworzenie repozytorium Git i przesłanie konfiguracji wdrożenia aplikacji
Tworzenie i wdrażanie zasobów aplikacji Argo CD
Wyświetlanie wdrożonych zasobów
Wymagania wstępne
Nr 1 Konto
Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Klaster Kubernetes
Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
Nr 3 Dostęp do klastra za pomocą kubectl
Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?
Nr 4 Znajomość Helm
W poniższym artykule przedstawiono, jak zainstalować pakiety chart Helm i rozpocząć korzystanie z nich:
Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS
Nr 5 Dostęp do własnego repozytorium Git
Repozytorium dla tego artykułu można hostować na instancji GitLab utworzonej w artykule Instalacja GitLab na platformie NSIS Kubernetes. Można go również używać z GitHub, GitLab i innymi platformami kontroli wersji opartymi na git.
Nr 6 Działający git CLI
Polecenie git zainstalowane lokalnie. Można go używać z GitHub, GitLab i innymi platformami kontroli źródła opartymi na git.
Nr 7 Dostęp do przykładowej aplikacji Flask
Powinien być możliwy dostęp do przykładowej aplikacji Flask, która zostanie pobrana z GitHub w artykule. Posłuży ona jako przykład minimalnej aplikacji, a zmieniając ją, zademonstrujemy, że Argo CD przechwytuje te zmiany w sposób ciągły.
Krok 1 Zainstaluj Argo CD
Zainstalujmy najpierw Argo CD przy następujących założeniach:
treść tego artykułu została przetestowana na Kubernetes w wersji 1.25.
jest używany tylko graficzny interfejs użytkownika (CLI nie jest używany w tym przewodniku)
Argo CD jest wdrażany bez certyfikatów TLS.
Szczegółowy przewodnik instalacji znajduje się tutaj <https://argo-cd.readthedocs.io/en/stable/getting_started/>`_.
W przypadku scenariuszy produkcyjnych zaleca się stosowanie TLS <https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/>`_.
Najpierw utwórzmy dedykowaną przestrzeń nazw w ramach istniejącego klastra Kubernetes. Przestrzeń nazw powinna mieć nazwę argocd:
kubectl create namespace argocd
Następnie zainstaluj Argo CD:
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Krok 2 Uzyskaj dostęp do Argo CD z przeglądarki
Aplikacja internetowa Argo CD domyślnie nie jest dostępna z poziomu przeglądarki. Aby ją udostępnić, należy zmienić odpowiednią usługę z ClusterIP na LoadBalancer za pomocą polecenia:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
Po 1–2 minutach pobierz adres IP usługi:
kubectl get service argocd-server -n argocd
W naszym przypadku daje to poniższy wynik i wskazuje, że Argo CD jest uruchomiony na adresie IP 185.254.233.247:
Wpisz wyodrębniony adres IP do przeglądarki (w twoim przypadku będzie to inny adres IP, więc pamiętaj, aby zastąpić cytowany tutaj adres 185.254.233.247 własnym adresem). Prawdopodobnie pojawi się ostrzeżenie o nieprawidłowym certyfikacie. Aby zignorować ostrzeżenie, kliknij przycisk „Advanced”, a następnie „Proceed to Unsafe”, nastąpi wtedy przekierowanie do ekranu logowania Argo CD:
Login to admin. Aby uzyskać hasło, należy wyodrębnić je z wdrożonego tajnego kodu Kubernetes za pomocą następującego polecenia:
kubectl get secret argocd-initial-admin-secret -n argocd -ojsonpath='{.data.password}' | base64 --decode ; echo
Po wpisaniu poświadczeń w formularzu logowania nastąpi przekierowanie na poniższy ekran:
Krok 3 Utwórz repozytorium Git
Najpierw należy utworzyć repozytorium git. Stan aplikacji na klastrze Kubernetes będzie synchronizowany ze stanem tego repozytorium. Zaleca się, aby było to repozytorium oddzielne od kodu aplikacji, aby uniknąć uruchamiania potoków CI za każdym razem, gdy konfiguracja jest zmieniana.
Do tego nowo utworzonego repozytorium zostaną skopiowane pliki dostępne już w (innym) repozytorium GitHub, o którym mowa w sekcji Wymaganie wstępne nr 5 Działający git CLI.
Najpierw utwórz repozytorium, które w naszym przypadku nazywa się argocd-sample. Podczas wypełniania formularza zaznacz inicjalizację z README i wybierz widoczność publiczną:
W tym widoku adres URL projektu zostanie wstępnie wypełniony i będzie odpowiadał adresowi URL instancji GitLab. W miejscu oznaczonym niebieskim prostokątem należy wpisać nazwę użytkownika; zwykle będzie to root, ale może to być cokolwiek innego. Jeśli w GitLab są już zdefiniowani jacyś użytkownicy, ich nazwy pojawią się w menu rozwijanym.
Krok 4 Pobierz aplikację Flask
Następnym celem jest pobranie dwóch plików yaml do katalogu o nazwie ArgoCD-sample i jego podkatalogu deployment.
Po przesłaniu formularza „Create project” otrzymasz listę poleceń do pracy z repozytorium. Przejrzyj je i przełącz się na CLI z sekcji Wymaganie wstępne nr 6. Sklonuj całe repozytorium próbek CloudFerro K8s, a następnie wyodrębnij podkatalog o nazwie Flask-K8s-deployment. Dla większej przejrzystości zmieniamy nazwę jego zawartości na nowy folder, ArgoCD-sample. Jeśli po raz pierwszy pracujesz z tym folderem, użyj polecenia
mkdir ~/ArgoCD-sample
Następnie wykonaj następujący zestaw poleceń:
git clone https://github.com/CloudFerro/K8s-samples
mv ~/K8s-samples/Flask-K8s-deployment ~/ArgoCD-sample/deployment
rm K8s-samples/ -rf
Pliki deployment.yaml i service.yaml wdrażają przykładową aplikację Flask na Kubernetes i udostępniają ją jako usługę. Są to typowe minimalne przykłady wdrożenia i usługi, które można pobrać z repozytorium przykładów CloudFerro Kubernetes.
Krok 5 Prześlij konfiguracje wdrożenia aplikacji
Następnie należy przesłać pliki deployment.yaml i service.yaml do zdalnego repozytorium. Ponieważ używasz git, przesyłanie odbywa się poprzez synchronizację lokalnego repozytorium ze zdalnym. Najpierw zainicjuj repozytorium lokalnie, a następnie prześlij pliki do repozytorium zdalnego za pomocą następujących poleceń (zamień nazwę instancji repozytorium git własną nazwą):
cd ArgoCD-sample
git init
git remote add origin git@gitlab.mysampledomain.info:root/ArgoCD-sample.git
git add .
git commit -m "First commit"
git push origin master
W rezultacie w tym momencie mamy dwa pliki dostępne w zdalnym repozytorium, w katalogu deployment:
Krok 6 Utwórz zasób aplikacji Argo CD
Konfiguracja Argo CD dla konkretnej aplikacji jest definiowana przy użyciu niestandardowego zasobu aplikacji. Taki zasób łączy klaster Kubernetes z repozytorium, w którym przechowywane są konfiguracje wdrożeń.
Bezpośrednio w katalogu ArgoCD-sample utwórz plik application.yaml, który będzie reprezentował aplikację. Pamiętaj, aby zastąpić gitlab.mysampledomain.info nazwą własnej domeny.
application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp-application
namespace: argocd
spec:
project: default
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
selfHeal: true
prune: true
source:
repoURL: https://gitlab.mysampledomain.info/root/argocd-sample.git
targetRevision: HEAD
path: deployment
destination:
server: https://kubernetes.default.svc
namespace: myapp
Kilka wyjaśnień dotyczących tego pliku:
- spec.project.default
Określa, że nasza aplikacja jest powiązana z domyślnym projektem (reprezentowanym jako CRD appproject w Kubernetes). Dodatkowe projekty mogą być tworzone i wykorzystywane do zarządzania wieloma aplikacjami.
- spec.syncPolicy.syncOptions.CreateNamespace=true
Zapewnia, że przestrzeń nazw (określona w parametrze spec.destination.namespace) zostanie automatycznie utworzona w naszym klastrze, jeśli jeszcze nie istnieje.
- spec.syncPolicy.automated.selfHeal: true
Zapewnia, że wszelkie ręczne zmiany wykonane w klastrze (na przykład zastosowane przy użyciu kubectl) spowodują synchronizację z repozytorium Git, nadpisanie tych ręcznych zmian, a tym samym zapewnienie spójności między klastrem a stanem repozytorium.
- spec.syncPolicy.automated.prune: true
Gwarantuje, że usunięcie definicji zasobu w repozytorium spowoduje również usunięcie tego zasobu z klastra Kubernetes.
- spec.source.repoURL
Jest to adres URL naszego repozytorium git, w którym znajdują się artefakty wdrożenia.
- spec.source.targetRevision.HEAD
Zapewnia synchronizację klastra Kubernetes z najnowszą aktualizacją repozytorium git.
- spec.source.source.path
Nazwa katalogu w repozytorium Git, w którym przechowywane są manifesty yaml.
- spec.destination.server
Adres klastra Kubernetes, w którym wdrażamy naszą aplikację. Ponieważ jest to ten sam klaster, w którym działa Argo CD, można uzyskać do niego dostęp za pomocą wewnętrznego adresowania DNS klastra.
- spec.destination.namespace
Przestrzeń nazw w klastrze, w której aplikacja zostanie wdrożona.
Krok 7 Wdróż aplikację Argo CD
Po utworzeniu pliku application.yaml następnym krokiem jest zatwierdzenie go i przesłanie do zdalnego repozytorium. Można to zrobić za pomocą następujących poleceń:
git add -A
git commit -m "Added application.yaml file"
git push origin master
Ostatnim krokiem jest zastosowanie konfiguracji application.yaml do klastra za pomocą poniższego polecenia:
kubectl apply -f application.yaml
Krok 8 Wyświetl wdrożone zasoby
Po wykonaniu powyższych kroków przełączamy widok na interfejs Argo CD. Widać, że nasza aplikacja pojawiła się na liście aplikacji i że stan, który ma zostać zastosowany w klastrze, został poprawnie pobrany z repozytorium Git. Zakończenie wdrażania zasobów na klastrze zajmie kilka minut:
Po prawidłowym wdrożeniu nasza aplikacja wygląda następująco:
Po kliknięciu pola aplikacji można również zobaczyć informacje szczegółowe o wszystkich zasobach, które mają wpływ na to wdrożenie, zarówno wysokopoziomowych, jak i niskopoziomowych.
Przy ustawieniach domyślnych Argo CD będzie sprawdzać repozytorium Git co 3 minuty, aby pobrać pożądany stan klastra. Jeśli wykryte zostaną jakiekolwiek zmiany w repozytorium, aplikacje w klastrze zostaną automatycznie ponownie uruchomione z zastosowaną nową konfiguracją.
Co można zrobić dalej?
przetestować stosowanie zmian do wdrożenia w repozytorium (na przykład zatwierdzić wdrożenie z innym obrazem w specyfikacji kontenera), zweryfikować, czy ArgoCD przechwytuje zmianę i zmienia stan klastra
dostosować wdrożenie Argo CD, aby włączyć HTTPS
zintegrować Argo CD z narzędziem do zarządzania tożsamością; szczegółowe informacje zawiera artykuł Wdrożenie Keycloak na Kubernetes z przykładową aplikacją w NSIS
Interesujący może być również artykuł Pipelines CI/CD w GitLab na NSIS Kubernetes - tworzenie obrazu Docker.