GitOps mit Argo CD auf EO-Lab Kubernetes

Argo CD ist ein Continuous-Deployment-Tool für Kubernetes, das nach den Prinzipien von GitOps und Infrastructure as Code (IaC) entwickelt wurde. Es stellt automatisch sicher, dass Anwendungen, die auf einem Kubernetes-Cluster bereitgestellt werden, immer mit einem dedizierten Git-Repository synchronisiert werden, in dem die gewünschten Versionen bereitstehen.

In diesem Artikel werden wir die Installation von Argo CD auf einem Kubernetes-Cluster und die Bereitstellung einer Anwendung mit diesem Tool demonstrieren.

Was wir behandeln werden

Installation von Argo-CD

Zugriff auf Argo CD von Ihrem Browser aus

Git-Repository erstellen und Ihre Anwendungsbereitstellungskonfigurationen pushen

Argo CD Anwendungsressourcen erstellen und einsetzen

Die bereitgestellten Ressourcen ansehen

Voraussetzungen

Nr. 1 Konto

Sie benötigen ein EO-Lab Konto mit Zugriff auf die Horizon-Schnittstelle: https://cloud.fra1-1.cloudferro.com/auth/login/?next=/.

Nr. 2 Kubernetes Cluster

Erstellen eines Kubernetes-Clusters mit EO-Lab OpenStack Magnum

Nr. 3 Zugang zum Cluster mit kubectl

Zugriff auf Kubernetes-Cluster nach der Bereitstellung mit Kubectl auf EO-Lab OpenStack Magnum

Nr. 4 Vertrautheit im Umgang mit Helm

Hier erfahren Sie, wie Sie Helm-Charts installieren und nutzen können:

Einsatz von Helm Charts auf Magnum Kubernetes-Clustern auf der EO-Lab FRA1-1 Cloud

Nr. 5 Zugang zu Ihrem eigenen Git-Repository

Sie können ein Repository für diesen Artikel auf einer GitLab-Instanz hosten, wie in Artikel Install GitLab on EO-Lab Kubernetes. Sie können es auch mit GitHub, GitLab oder anderen auf git basierenden Versionskontrollplattformen erstellen.

Nr. 6 git CLI einsatzbereit

Der git Befehl muss lokal installiert sein. Eine Anleitung finden sie auf GitHub, GitLab und andere auf git basierende Versionskontrollplattformen.

Nr. 7 Zugang zu einer beispielhaften Flask-Anwendung

Sie sollten Zugang haben zu einer Flask Anwendung, die in diesem Artikel von GitHub heruntergeladen werden soll. Sie dient als Beispiel für eine Minimalanwendung. Indem wir sie ändern, können wir zeigen, dass Argo CD diese Änderungen kontinuierlich erfasst.

Schritt 1 Argo-CD installieren

Installieren wir zunächst die Argo-CD unter den folgenden Annahmen:

dieser Artikel wurde mit Kubernetes Version 1.25 getestet

Nur GUI verwenden (in dieser Anleitung wird kein CLI verwendet)

Argo CD ohne TLS-Zertifikate einsetzen.

Hier finden Sie eine ausführliche Installationsanleitung.

Für Produktionsszenarien wird empfohlen, TLS zu verwenden.

Erstellen wir zunächst einen dedizierten Namespace innerhalb unseres bestehenden Kubernetes-Clusters. Der Namespace sollte explizit argocd genannt werden:

kubectl create namespace argocd

Installieren Sie dann Argo-CD:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Schritt 2 Greifen Sie über Ihren Browser auf Argo CD zu

Die Argo-CD-Webanwendung ist standardmäßig nicht über den Browser zugänglich. Um dies zu aktivieren, ändern Sie den entsprechenden Dienst vom Typ ClusterIP auf LoadBalancer mit dem Befehl:

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Rufen Sie nach 1-2 Minuten die IP-Adresse des Dienstes ab:

kubectl get service argocd-server -n argocd

In unserem Fall zeigt das Ergebnis, dass Argo CD auf der IP-Adresse 185.254.233.247 läuft:

Geben Sie die IP-Adresse in Ihrem Browser ein (in Ihrem Fall wird es sich um eine andere IP-Adresse handeln; ersetzen Sie daher die hier angegebene Adresse 185.254.233.247 durch Ihre eigene Adresse). Sie werden voraussichtlich eine Warnung über ein ungültiges Zertifikat erhalten. Um die Warnung zu unterdrücken, klicken Sie auf „Advanced“ (Erweitert) und dann auf „Proceed to Unsafe“ (Unsicher) und Sie werden zum Anmeldebildschirm von Argo CD weitergeleitet:

Die Anmeldung lautet admin. Um das Passwort zu erhalten, extrahieren Sie es mit dem folgenden Befehl aus dem bereitgestellten Kubernetes-„Secret“:

kubectl get secret argocd-initial-admin-secret -n argocd -ojsonpath='{.data.password}' | base64 --decode ; echo

Nachdem Sie Ihre Anmeldedaten in das Anmeldeformular eingegeben haben, werden Sie zu folgendem Bildschirm weitergeleitet:

Schritt 3 Erstellen eines Git-Repositorys

Sie müssen zunächst ein Git-Repository erstellen. Der Status der Anwendung auf Ihrem Kubernetes-Cluster wird mit dem Status dieses Repositorys synchronisiert. Es wird empfohlen, dass es sich um ein vom Anwendungscode getrenntes Repository handelt, um zu vermeiden, dass die CI-Pipelines bei jeder Änderung der Konfiguration ausgelöst werden.

Sie kopieren in dieses neu erstellte Repository Dateien, die bereits in einem (anderen) GitHub-Repository vorhanden sind, das in der Voraussetzung Nr. 6 Git CLI einsatzbereit erwähnt wird.

Erstellen Sie zunächst das Repository, wir nennen es argocd-sample. Während Sie das Formular ausfüllen, wählen Sie die Initialisierung mit README ab und wählen Sie Public Visibility aus:

In der obigen Ansicht ist die Projekt-URL bereits ausgefüllt und entspricht der URL Ihrer GitLab-Instanz. An der mit einem blauen Rechteck gekennzeichneten Stelle geben Sie Ihren Benutzernamen ein; in der Regel ist dies root, Sie können aber auch einen anderen Namen eingeben. Wenn bereits Benutzer in GitLab definiert sind, werden deren Namen in einem Dropdown-Menü angezeigt.

Schritt 4 Flask-Anwendung herunterladen

Als nächstes sollen zwei yaml-Dateien in einen Ordner namens ArgoCD-sample und dessen Unterordner deployment heruntergeladen werden.

Nach dem Absenden des Formulars „Projekt erstellen“ erhalten Sie eine Liste von Befehlen für die Arbeit mit Ihrem Repository. Prüfen Sie diese und wechseln Sie zum CLI aus Voraussetzung Nr. 6. Klonen Sie das gesamte CloudFerro K8s Samples Repository. Aus diesem benötigen wir nur den Unterordner namens Flask-K8s-deployment. Der Übersichtlichkeit halber benennen wir diesen Ordner um und kopieren ihn in einen neuen Ordner namens ArgoCD-sample. Erstellen Sie das Verzeichnis mit

mkdir ~/ArgoCD-sample

wenn Sie diesen Artikel zum ersten Mal durcharbeiten. Wenden Sie dann die folgende Befehlsfolge an:

git clone https://github.com/CloudFerro/K8s-samples
mv ~/K8s-samples/Flask-K8s-deployment ~/ArgoCD-sample/deployment
rm K8s-samples/ -rf

Die Dateien deployment.yaml und service.yaml stellen eine Flask-Beispielanwendung in Kubernetes bereit und stellen sie als Dienst bereit. Dies sind typische Minimalbeispiele für die Bereitstellung und den Service und können vom CloudFerro Kubernetes Beispiel Repository bezogen werden (siehe Voraussetzung Nr. 7).

Schritt 5 Push-Konfigurationen für die Anwendungsbereitstellung

Dann müssen Sie die Dateien deployment.yaml und service.yaml in das online Repository hochladen. Da Sie Git verwenden, führen Sie den Upload durch Synchronisierung Ihres lokalen Repositorys mit dem entfernten Repository durch. Starten Sie zunächst das lokale Repository und übertragen Sie dann die Dateien mit den folgenden Befehlen auf das entfernte Repository (ersetzen Sie diese durch Ihre eigene Git-Repository-Instanz)Dann müssen Sie die Dateien deployment.yaml und service.yaml in das online Repository hochladen. Da Sie Git verwenden, führen Sie den Upload durch Synchronisierung Ihres lokalen Repositorys mit dem remote Repository durch. Starten Sie zunächst das lokale Repository und übertragen Sie dann die Dateien mit den folgenden Befehlen auf das remote Repository (ersetzen Sie diese durch Ihre eigene Git-Repository-Instanz):

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

Als Ergebnis haben wir damit die beiden Dateien im Remote-Repository im Bereitstellungsordner:

Schritt 6 Erstellen der Argo-CD-Anwendungsressource

Die Argo-CD-Konfiguration für eine bestimmte Anwendung wird über eine anwendungsspezifische Ressource definiert. Eine solche Ressource verbindet einen Kubernetes-Cluster mit einem Repository, in dem Bereitstellungskonfigurationen gespeichert werden.

Erstellen Sie direkt im Ordner ArgoCD-sample die Datei application.yaml, die die Anwendung repräsentieren wird; ersetzen Sie gitlab.mysampledomain.info durch Ihre eigene Domain.

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

Einige Erläuterungen zu dieser Datei:

spec.project.default: Gibt an, dass unsere Anwendung mit dem Standardprojekt verbunden ist (in Kubernetes als appproject CRD dargestellt). Es können zusätzliche Projekte erstellt und für die Verwaltung mehrerer Anwendungen verwendet werden.
spec.syncPolicy.syncOptions.CreateNamespace=true: Stellt sicher, dass ein Namespace (angegeben in spec.destination.namespace) automatisch auf unserem Cluster erstellt wird, wenn er nicht bereits existiert.
spec.syncPolicy.automated.selfHeal: true: Stellt sicher, dass alle manuellen Änderungen im Cluster (z.B. mit kubectl) eine Synchronisation mit dem Git Repo auslösen, diese manuellen Änderungen überschreiben und somit die Konsistenz zwischen dem Cluster und dem Repository-Status sicherstellen.
spec.syncPolicy.automated.prune: true: Stellt sicher, dass das Löschen einer Ressourcendefinition im Repo auch diese Ressource aus dem Kubernetes-Cluster löscht.
spec.source.repoURL: Die URL unseres Git-Repositorys, in dem sich die Deployment-Artefakte befinden.
spec.source.targetRevision.HEAD: Stellt sicher, dass der Kubernetes-Cluster mit dem neuesten Update des Git-Repositorys synchronisiert wird.
spec.source.source.path: Der Ordners im Git-Repository, in dem die yaml-Manifeste gespeichert sind.
spec.destination.server: Die Adresse des Kubernetes-Clusters, in dem wir unsere Anwendung bereitstellen. Da dies derselbe Cluster ist, auf dem Argo CD läuft, kann auf ihn über die interne DNS-Adressierung des Clusters zugegriffen werden.
spec.destination.namespace: Der Namespace im Cluster, in dem die Anwendung bereitgestellt werden soll.

Schritt 7 Einsatz der Argo-CD-Anwendung

Nachdem wir die Datei application.yaml erstellt haben, besteht der nächste Schritt darin, sie zu committen und an das entfernte Repo zu pushen. Dies können wir mit den folgenden Befehlen tun:

git add -A
git commit -m "Added application.yaml file"
git push origin master

Der letzte Schritt besteht darin, die Konfiguration application.yaml mit dem folgenden Befehl auf den Cluster anzuwenden:

kubectl apply -f application.yaml

Schritt 8 Anzeigen der bereitgestellten Ressourcen

Nachdem Sie die obigen Schritte durchgeführt haben, wechseln Sie zum Argo CD UI. Wir können sehen, dass unsere Anwendung in der Liste der Anwendungen erscheint und dass der Status, der auf den Cluster angewendet werden soll, ordnungsgemäß aus dem Git Repository erfasst wurde. Es wird ein paar Minuten dauern, bis die Bereitstellung der Ressourcen auf dem Cluster abgeschlossen ist:

Dies ist die Ansicht unserer Anwendung, nachdem die Bereitstellung ordnungsgemäß durchgeführt wurde:

Wenn wir die Anwendung anklicken, können wir auch die Details für alle Ressourcen sehen, die zu dieser Bereitstellung beitragen, und zwar sowohl die High-Level- als auch die Low-Level-Ressourcen.

In der Standardeinstellung wird Argo CD das Git-Repository alle 3 Minuten abfragen, um den gewünschten Zustand des Clusters zu erfassen. Wenn Änderungen im Repository festgestellt werden, werden die Anwendungen auf dem Cluster automatisch mit der neuen Konfiguration neu gestartet.

Was als nächstes zu tun ist

Testen Sie die Anwendung von Änderungen an der Bereitstellung im Repository (z.B. übertragen Sie eine Bereitstellung mit einem anderen Image in der Container-Spezifikation), überprüfen Sie, ob ArgoCD die Änderung erfasst und den Cluster-Status ändert
das Deployment von Argo CD anpassen, um HTTPS zu aktivieren
Argo CD mit Ihrem Identitätsmanagement-Tool integrieren; für Details siehe Einsatz von Keycloak auf Kubernetes mit einer Beispielanwendung auf EO-Lab

Von Interesse ist auch der folgende Artikel: CI/CD-Pipelines mit GitLab auf EO-Lab Kubernetes - Erstellung eines Docker-Images