Skip to main content
  • »
  • KUBERNETES »
  • GitOps z Argo CD na NSIS Kubernetes

GitOps z Argo CD na NSIS Kubernetes

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 definiujemy taki pożądany stan.

W tym artykule zademonstrujemy instalację Argo CD na klastrze Kubernetes i wdrożenie aplikacji za pomocą tego narzędzia.

Co będziemy omawiać

  • Zainstaluj Argo CD

  • Dostęp do Argo CD z poziomu przeglądarki

  • Utwórz repozytorium Git i wypchnij konfiguracje wdrożenia aplikacji

  • Tworzenie i wdrażanie zasobów aplikacji Argo CD

  • Wyświetlanie wdrożonych zasobów

Wymagania wstępne

Nr 1 Konto

Potrzebne jest 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ść sterów

Oto jak zainstalować i rozpocząć korzystanie z wykresów Helm:

Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS Cloud

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 źródła opartymi na git.

Nr 6 git CLI operacyjne

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

Powinieneś mieć 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:

  • Ten artykuł został przetestowany na Kubernetes w wersji 1.25.

  • używać tylko GUI (CLI nie jest używane w tym przewodniku)

  • wdrożyć Argo CD bez certyfikatów TLS.

Oto szczegółowy przewodnik instalacji.

W przypadku scenariuszy produkcyjnych zaleca się stosowanie TLS.

Najpierw utwórzmy dedykowaną przestrzeń nazw w ramach istniejącego klastra Kubernetes. Przestrzeń nazw powinna mieć jawną 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 to włączyć, 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 mamy Argo CD uruchomione na adresie IP 185.254.233.247:

../_images/image-2024-5-14_14-54-101.png

Wpisz adres IP, który wyodrębniłeś do przeglądarki (w twoim przypadku będzie to inny adres IP, więc pamiętaj, aby zastąpić 185.254.233.247 cytowany tutaj własnym adresem). Oczekuje się, że pojawi się ostrzeżenie o nieprawidłowym certyfikacie. Aby zignorować ostrzeżenie, kliknij „Zaawansowane”, a następnie „Przejdź do niebezpiecznego” i zostaniesz przeniesiony do ekranu logowania Argo CD:

../_images/image-2024-5-14_15-4-211.png

Login to admin. Aby uzyskać hasło, należy wyodrębnić je z wdrożonego sekretu 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 zostaniesz przeniesiony do następującego ekranu:

../_images/image-2024-5-14_15-34-01.png

Krok 3 Utworzenie 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 oddzielne repozytorium od kodu aplikacji, aby uniknąć uruchamiania potoków CI za każdym razem, gdy zmieniamy konfigurację.

Skopiujesz do tego nowo utworzonego repozytorium pliki już dostępne w (innym) repozytorium GitHub wspomnianym w Wymaganiu wstępnym nr 5 Git CLI operacyjny.

Najpierw utwórz repozytorium, my nazywamy nasze argocd-sample. Podczas wypełniania formularza zaznacz inicjalizację za pomocą README i wybierz widoczność publiczną:

../_images/image-2024-5-22_10-38-531.png

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 rozwijanym menu.

Krok 4 Pobierz aplikację Flask

Następnym celem jest pobranie dwóch plików yaml do folderu o nazwie ArgoCD-sample i jego podfolderu deployment.

Po przesłaniu formularza „Utwórz projekt” otrzymasz listę poleceń do pracy z repozytorium. Przejrzyj je i przełącz się na CLI z punktu 6. Sklonuj całe repozytorium próbek CloudFerro K8s, a następnie wyodrębnij podfolder o nazwie Flask-K8s-deployment. Dla przejrzystości zmieniamy nazwę jego zawartości na nowy folder, ArgoCD-sample. Użyj

mkdir ~/ArgoCD-sample

jeśli po raz pierwszy korzystasz z tego artykułu. Następnie zastosuj 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 wystawiają ją jako usługę. Są to typowe minimalne przykłady wdrożenia i usługi, które można pobrać z repozytorium próbek CloudFerro Kubernetes.

Krok 5 Wypchnięcie konfiguracji 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 repo ze zdalnym. Najpierw zainicjuj repozytorium lokalnie, a następnie prześlij pliki do zdalnego za pomocą następujących poleceń (zamień na własną instancję repozytorium git):

cd ArgoCD-sample
git init
git remote add origin [email protected]: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 folderze deployment:

../_images/image-2024-5-17_11-20-271.png

Krok 6 Tworzenie zasobu 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 folderze ArgoCD-sample utwórz plik application.yaml, który będzie reprezentował aplikację; pamiętaj, aby zastąpić gitlab.mysampledomain.info własną domeną.

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 appproject CRD 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 spec.destination.namespace) zostanie automatycznie utworzona na naszym klastrze, jeśli jeszcze nie istnieje.

spec.syncPolicy.automated.selfHeal: true

Zapewnia, że wszelkie ręczne zmiany w klastrze (np. 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 folderu 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 Wdrożenie aplikacji Argo CD

Po utworzeniu pliku application.yaml, następnym krokiem jest zatwierdzenie go i wypchnięcie do zdalnego repozytorium. Możemy 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świetlanie wdrożonych zasobów

Po wykonaniu powyższych kroków przełączamy widok na interfejs Argo CD. Widzimy, że nasza aplikacja pojawiła się na liście aplikacji i że stan, który ma zostać zastosowany w klastrze, został poprawnie przechwycony z repozytorium Git. Zakończenie wdrażania zasobów na klastrze zajmie kilka minut:

../_images/image-2024-5-22_10-23-581.png

To jest widok naszej aplikacji po prawidłowym wdrożeniu:

../_images/image-2024-5-22_10-27-251.png

Po kliknięciu pola aplikacji możemy również zobaczyć szczegóły wszystkich zasobów, które przyczyniają się do tego wdrożenia, zarówno wysokopoziomowych, jak i niskopoziomowych.

../_images/image-2024-5-22_11-17-121.png

Przy ustawieniach domyślnych Argo CD będzie sprawdzać repozytorium Git co 3 minuty, aby uchwycić pożądany stan klastra. Jeśli wykryte zostaną jakiekolwiek zmiany w repozytorium, aplikacje w klastrze zostaną automatycznie ponownie uruchomione z zastosowaną nową konfiguracją.

Co robić dalej

  • przetestować zastosowanie zmian do wdrożenia w repozytorium (np. 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

  • integracja Argo CD z narzędziem do zarządzania tożsamością; szczegółowe informacje można znaleźć w Wdrożenie Keycloak na Kubernetes z przykładową aplikacją na NSIS.

Interesujący może być również następujący artykuł: Potoki CI/CD z GitLab na NSIS Kubernetes - tworzenie obrazu Docker.