GitOps mit Argo CD implementieren

Tutorials
Git Kubernetes

Einführung

Argo CD ist eine beliebte Open-Source-Implementierung für die Durchführung von GitOps-Continuous-Delivery auf Kubernetes. Ihre Anwendungen, Definitionen, Konfigurationen und Umgebungen sollten deklarativ und versionsgesteuert sein. Auch die Bereitstellung und Lebenszyklusverwaltung von Anwendungen sollte automatisiert, nachvollziehbar und leicht verständlich sein. All dies kann mit Argo erreicht werden.

Argo CD folgt den gleichen GitOps-Mustern und -Prinzipien und verwaltet daher den Zustand Ihres Clusters auf deklarative Weise. Die Synchronisierung erfolgt über ein Git-Repository, in dem Ihre Kubernetes-Manifeste gespeichert sind. Kubernetes-Manifeste können auf verschiedene Arten angegeben werden:

  • Kustomize-Anwendungen.
  • Helm-Charts.
  • Ksonnet-Anwendungen.
  • Jsonnet-Dateien.
  • Einfaches Verzeichnis von YAML-/JSON-Manifesten.
  • Jedes benutzerdefinierte Konfigurationsverwaltungstool, das als Konfigurationsverwaltungs-Plugin konfiguriert ist.

Wie bei jeder Anwendung, die in einem Kubernetes-Cluster ausgeführt wird, wird Argo CD über benutzerdefinierte Ressourcendefinitionen (CRDs) konfiguriert, die in YAML-Manifesten gespeichert sind. Die wichtigste ist die CRD „Anwendung“. In einer Argo CD-Anwendung legen Sie fest, welches Git-Repository zum Synchronisieren mit welchem Kubernetes-Cluster verwendet werden soll. Es kann sich um denselben Kubernetes-Cluster handeln, in dem Argo CD bereitgestellt ist, oder um einen externen.

Argo CD ist als Kubernetes-Controller implementiert, der kontinuierlich laufende Anwendungen überwacht und den aktuellen (oder Live-) Zustand mit dem gewünschten Zielzustand vergleicht (wie im Git-Repository angegeben). Eine bereitgestellte Anwendung, deren Live-Zustand vom Zielzustand abweicht, gilt als OutOfSync. Argo CD meldet und visualisiert die Unterschiede und bietet Möglichkeiten, den Live-Zustand automatisch oder manuell wieder mit dem gewünschten Zielzustand zu synchronisieren.

Argo CD bietet viele Funktionen, darunter insbesondere:

  • Unterstützung für mehrere Konfigurationsverwaltungs-/Vorlagewerkzeuge wie: Kustomize, Helm, Ksonnet, Jsonnet, plain-YAML.
  • Möglichkeit zur Verwaltung und Bereitstellung in mehreren Clustern.
  • SSO-Integration (OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft, LinkedIn).
  • Mehrmandantenfähigkeit und RBAC-Richtlinien für Autorisierung.
  • Gesundheitsstatusanalyse von Anwendungsressourcen.
  • Rückgängig machen / Überallhin rollen zu jeder in Git-Repository festgelegten Anwendungs konfiguration.
  • Automatisierte Erkennung und Visualisierung von Konfigurationsabweichungen.
  • Web-Benutzeroberfläche, die einen Echtzeitüberblick über die Anwendungsaktivität bietet.
  • CLI für Automatisierung und CI-Integration.
  • Webhook-Integration (GitHub, BitBucket, GitLab).
  • Vor-Synchronisierungs-, Synchronisierungs- und Nach-Synchronisierungs-Hooks zur Unterstützung komplexer Anwendungseinführungen (z. B. Blue/Green- und Canary-Upgrades).
  • Prometheus-Metriken.

In diesem Tutorial lernen Sie:

  • Verwenden Sie Helm, um Argo CD auf Ihrem DOKS-Cluster bereitzustellen.
  • Halten Sie den Zustand der Anwendungen in Ihrem Kubernetes-Cluster mit einem Git-Repository synchronisiert (verwenden Sie die Prinzipien von GitOps).
  • Bereitstellen und Verwalten von Anwendungen über Argo CD.

Nach Abschluss aller Schritte dieses Tutorials sollten Sie über einen DOKS-Cluster mit bereitgestelltem Argo CD verfügen, der Folgendes bewirken wird:

  • Behandeln Sie die Cluster-Abstimmung über Anwendungs-CRDs.
  • Bearbeiten Sie Helm-Releases unter Verwendung von Helm-Quellen, die innerhalb von Anwendungs-CRDs definiert sind.

DOKS und Argo CD für Helm Releases Übersicht

Das folgende Diagramm zeigt, wie Argo CD Helm-Anwendungen verwaltet, die in einem Git-Repository gehostet werden:

Inhaltsverzeichnis

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

  1. A working DOKS cluster that you have access to. Please follow the Starter Kit DOKS Setup Guide to find out more.to find out more.
  2. A GitHub repository and branch, to store Argo CD and your applications manifests. Must be created beforehand.
  3. A Git client, for cloning the Starter Kit repository.
  4. Kubectl-Befehlszeilenschnittstelle für die Interaktion mit Kubernetes. Befolgen Sie diese Anweisungen, um sich mit Ihrem Cluster mit kubectl und doctl zu verbinden.
  5. Argo CLI zur Interaktion mit Argo CD über die Befehlszeilenschnittstelle.
  6. Kubeseal zum Verschlüsseln von Geheimnissen und zur Interaktion mit dem Sealed Secrets Controller.
  7. Helm zur Verwaltung von Argo CD-Veröffentlichungen und Upgrades (optional, aber generell empfohlen für Produktionssysteme).

Verständnis der Argo CD-Konzepte für die Bereitstellung von Anwendungen

Argo CD verwendet das Kernkonzept der Anwendung, um Bereitstellungen und den Lebenszyklus von Anwendungen zu verwalten. In einer Argo CD-Anwendungsmanifestdatei definieren Sie das Git-Repository, das Ihre Anwendungsdefinitionen hostet, sowie den entsprechenden Kubernetes-Cluster zur Bereitstellung von Anwendungen. Mit anderen Worten, eine Argo CD-Anwendung definiert die Beziehung zwischen einem Quellrepository und einem Kubernetes-Cluster. Es handelt sich um ein sehr prägnantes und skalierbares Design, in dem Sie mehrere Quellen (Git-Repositorys) und entsprechende Kubernetes-Cluster verknüpfen können.

A major benefit of using applications is that you don’t need to deploy Argo to each cluster individually. You can use a dedicated cluster for Argo, and deploy applications to all clusters at once from a single place. This way, you avoid Argo CD downtime or loss, in case other environments have issues or get decommissioned.

Darüber hinaus können Sie ähnliche Anwendungen in einem Projekt gruppieren. Projekte ermöglichen eine logische Gruppierung von Anwendungen und zugehörigen Rollen/Berechtigungen bei der Arbeit mit mehreren Teams. Wenn nicht anders angegeben, gehört jede neue Anwendung zum Standardprojekt. Das Standardprojekt wird automatisch erstellt und hat keine Einschränkungen. Das Standardprojekt kann geändert, aber nicht gelöscht werden.

Starter Kit verwendet das Standard-Projekt, um einen schnellen Start mit Argo CD zu ermöglichen. Anschließend lernen Sie, wie Sie eine Anwendung für jedes Starter Kit-Komponente erstellen und Helm-Charts als Anwendungsquelle verwenden. Argo CD ist nicht nur auf Helm-Quellen beschränkt, sondern Sie können auch die Leistung von Kustomize, Ksonnet, Jsonnet usw. nutzen. Bitte werfen Sie einen Blick auf die Seite der Anwendungsquellen für weitere Details.

Obwohl Sie die grafische Benutzeroberfläche (Webinterface) von Argo CD verwenden können, um Anwendungen zu erstellen, setzt Starter Kit auf den deklarativen GitOps-Weg über YAML-Manifeste. Jede YAML-Konfiguration fungiert als Rezept für jede Anwendung und kann daher in einem Git-Repository gespeichert werden. Das bedeutet, dass Sie Ihre Argo CD-Einrichtung immer wieder neu erstellen können, wenn Sie Ihre Umgebung neu erstellen oder zu einem anderen Cluster wechseln. Noch wichtiger ist, dass Sie Audits durchführen und jede Änderung über die Git-Historie nachverfolgen können. Es ist bewährte Praxis, auch die Argo CD-Konfigurationsdateien in einem separaten Git-Repository zu haben, als das, das für die Entwicklung Ihrer Anwendung verwendet wird. Sie können die beste Praktiken-Seite von der offiziellen Argo CD-Dokumentationswebsite für weitere Informationen zum Thema lesen.

Wichtiger Hinweis:
Ein wichtiger Aspekt, den man im Kopf behalten sollte, ist, dass Argo CD standardmäßig nicht automatisch Ihre neuen Anwendungen synchronisiert. Wenn eine ArgoCD-Anwendung zum ersten Mal erstellt wird, ist ihr Zustand OutOfSync. Das bedeutet, dass der Zustand des Git-Repositories, auf das die ArgoCD-Anwendung zeigt, nicht mit dem Zustand des Kubernetes-Clusters übereinstimmt. Das Erstellen einer neuen ArgoCD-Anwendung löst keine automatische Bereitstellung im Zielcluster aus.

Um eine automatische Synchronisierung und Löschung verwaister Ressourcen (Pruning) zu ermöglichen, müssen Sie eine syncPolicy erstellen. Sie können auch Argo CD konfigurieren, um manuelle Änderungen, die über kubectl vorgenommen wurden, automatisch zurückzusetzen. Mehr über Auto-Synchronisierungsrichtlinien erfahren Sie auf der offiziellen Dokumentationswebsite.

Ein typischer Application CRD mit einer Git-Repository-Quelle sieht wie folgt aus:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myrepo/my-apps.git
    targetRevision: HEAD
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: my-apps
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Erklärungen für die obige Konfiguration:

  • spec.project: Gibt Argo CD an, welches Projekt für die Anwendung verwendet werden soll (default in diesem Beispiel).
  • spec.source.repoURL: Git-Repository-URL, die für die Synchronisierung des Clusterzustands verwendet wird.
  • spec.source.targetRevision: Git-Repository-Revision, die für die Synchronisierung verwendet wird (kann auch ein Branch- oder Tag-Name sein).
  • spec.source.path: Pfad im Git-Repository, in dem Quelldateien (YAML-Manifeste) gespeichert sind.
  • spec.destination.server: Zieladresse des Kubernetes-Clusters. Zeigt in der Regel auf https://kubernetes.default.svc, wenn Argo CD den gleichen Cluster verwendet, in dem es bereitgestellt ist.
  • spec.destination.namespace: Kubernetes-Namespace, der für Ihre Anwendung verwendet werden soll.
  • spec.syncPolicy.automated: Aktiviert die automatische Synchronisierung von Anwendungen in Ihrem Cluster mit einem Git-Repository.
  • spec.syncPolicy.automated.prune: Prune gibt an, ob Ressourcen aus dem Cluster gelöscht werden sollen, die nicht mehr in den Quellen gefunden werden, als Teil der automatischen Synchronisierung.
  • spec.syncPolicy.automated.selfHeal: Gibt an, ob Ressourcen bei manuellen Änderungen im Cluster (z. B. über kubectl) auf ihren gewünschten Zustand zurückgesetzt werden sollen.

Sie können auch Helm-Repositories als Quelle für die Installation von Anwendungen in Ihrem Cluster verwenden. Eine typische Application CRD, die eine Helm-Repository-Quelle verwendet, sieht wie folgt aus (ähnlich wie das Beispiel mit dem Git-Repository, nur dass stattdessen ein Helm-Chart-Repository verwendet wird):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sealed-secrets
  namespace: argocd
spec:
  project: default
  source:
    chart: sealed-secrets
    repoURL: https://bitnami-labs.github.io/sealed-secrets
    targetRevision: 2.4.0
    helm:
      releaseName: sealed-secrets
      values: |
        replicaCount: 2
  destination:
    server: "https://kubernetes.default.svc"
    namespace: kubeseal

Erklärungen für die obige Konfiguration:

  • spec.source.chart: Helm-Chart, das als Quelle für die Anwendung verwendet werden soll.
  • spec.source.repoURL: URL des Helm-Chart-Repositorys.
  • spec.source.targetRevision: Helm-Chart-Version, die für die Anwendung verwendet werden soll.
  • spec.source.helm.releaseName: Name der Helm-Veröffentlichung, die in Ihrem Kubernetes-Cluster erstellt werden soll.
  • spec.source.helm.values: Gibt die Helm-Werte an, die an helm template übergeben werden sollen, typischerweise als Block definiert.
  • spec.destination.server: Zieladresse des Kubernetes-Clusters. Zeigt normalerweise auf https://kubernetes.default.svc, wenn Argo CD denselben Cluster verwendet, in dem es bereitgestellt ist.
  • spec.destination.namespace: Kubernetes-Namespace für Ihre Anwendung verwenden.

Bitte lesen Sie mehr über die Kernkonzepte von Argo CD auf der offiziellen Dokumentationswebsite. Als nächstes werden Sie die verfügbaren Installationsoptionen entdecken, um Argo CD in Ihrem Kubernetes-Cluster bereitzustellen.

Argo CD installieren

Argo CD kann entweder mit kubectl oder Helm installiert werden:

  1. Verwendung von kubectl und einer Installationsmanifestdatei. Diese Methode bietet keine direkte Steuerung für verschiedene Installationsparameter. Wenn Sie nicht sehr vertraut mit Helm-basierten Installationen sind, ist dies die einfachste Option, um zu beginnen.
  2. Helm-basierte Installation. Bietet eine granulare Steuerung für die Bereitstellung und Lebenszyklus der Argo CD-Anwendung. Empfohlen für HA (High Availability)-Einrichtungen und wenn Argo CD in Produktion verwendet wird.

Anschließend haben Sie, abhängig von den gewünschten Funktionen, zwei Optionen:

  • Mehrbenutzer-Modus. Diese Art der Installation wird typischerweise verwendet, um mehrere Anwendungsentwicklerteams in der Organisation zu bedienen und wird von einem Plattformteam verwaltet. Die Endbenutzer können über den API-Server mit der Webbenutzeroberfläche oder dem argocd-CLI auf Argo CD zugreifen.
  • Kern-Modus nur. Dies ist eine abgespeckte Installation ohne grafische Benutzeroberfläche, API-Server, SSO usw. und installiert die leichte (nicht-HA) Version jedes Komponenten.

Das Starter Kit verwendet die Modi Mehrmandanten und Hochverfügbarkeit, um Argo CD in Ihrem DOKS-Cluster zu installieren. Auf diese Weise haben Sie eine zuverlässige Einrichtung und können alle verfügbaren Funktionen erkunden, einschließlich der Benutzeroberfläche. Bitte besuchen Sie die Dokumentationsseite zu den Installationsmethoden, um weitere Informationen zu erhalten.

Kubectl-basierte Installation

Diese Methode erfordert kubectl und ist ein zweistufiger Prozess:

  1. Erstellen Sie einen Namespace, um Argo CD selbst bereitzustellen.
  2. Führen Sie das HA-Installationsmanifest über kubectl aus.

Führen Sie bitte die folgenden Befehle in der angegebenen Reihenfolge aus:

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

Überprüfen Sie nun, ob die Installation erfolgreich war. Überprüfen Sie zunächst, ob alle Bereitstellungen von Argo CD gesund sind:

kubectl get deployments -n argocd

Die Ausgabe sieht ähnlich aus (überprüfen Sie die Spalte READY – alle Pods müssen laufen):

Output
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
argocd-applicationset-controller   1/1     1            1           51s
argocd-dex-server                  1/1     1            1           50s
argocd-notifications-controller    1/1     1            1           50s
argocd-redis-ha-haproxy            3/3     3            3           50s
argocd-repo-server                 2/2     2            2           49s
argocd-server                      2/2     2            2           49s

Argo CD-Server muss einen Replikensatz Mindestwert von 2 für den HA-Modus haben. Wenn aus irgendeinem Grund einige Bereitstellungen nicht gesund sind, überprüfen Sie bitte die Kubernetes-Ereignisse und Protokolle für die betroffenen Komponenten-Pods.

Installation über Helm

Diese Methode erfordert, dass Helm auf Ihrem lokalen Rechner installiert ist. Das Starter-Kit bietet eine gebrauchsfertige Helm-Werte-Datei zum Einstieg an und installiert Argo CD im HA-Modus (ohne automatische Skalierung).

Bitte befolgen Sie die folgenden Schritte, um die Installation über Helm abzuschließen:

  1. Zuerst klonen Sie das Verzeichnis des Starter-Kits (falls noch nicht geschehen) und wechseln in das Verzeichnis Ihrer lokalen Kopie:
git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git
cd Kubernetes-Starter-Kit-Developers
  1. Anschließend fügen Sie das Helm-Repository von Argo CD hinzu:
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update argo
  1. Suchen Sie nun im argo Helm-Repository nach verfügbaren Charts zur Installation:
helm search repo argo

Die Ausgabe sieht ähnlich aus wie:

Output
NAME                            CHART VERSION   APP VERSION     DESCRIPTION 
argo/argo                       1.0.0           v2.12.5         A Helm chart for Argo Workflows  
argo/argo-cd                    4.9.4           v2.4.0          A Helm chart for Argo CD, a declarative, GitOps...
...
  1. Dann öffnen und inspizieren Sie die von Starter Kit bereitgestellte Helm-Werte-Datei im Repository mit einem Editor Ihrer Wahl (vorzugsweise mit YAML-Lint-Unterstützung). Sie können beispielsweise VS Code verwenden:
code 14-continuous-delivery-using-gitops/assets/manifests/argocd/argocd-values-v4.9.4.yaml
  1. Schließlich deployen Sie Argo CD auf Ihren DOKS-Cluster:
HELM_CHART_VERSION="4.9.4"
helm install argocd argo/argo-cd --version "${HELM_CHART_VERSION}" \
  --namespace argocd \
  --create-namespace \
  -f "14-continuous-delivery-using-gitops/assets/manifests/argocd/argocd-values-v${HELM_CHART_VERSION}.yaml"

–create-namespace \

Hinweis:
Eine spezifische Version des Helm-Charts wird verwendet. In diesem Fall wird 4.9.4 ausgewählt, was der Version 2.4.0 der Anwendung entspricht. Es ist eine gute Praxis im Allgemeinen, sich auf eine bestimmte Version festzulegen. Dies hilft, vorhersehbare Ergebnisse zu erzielen, und ermöglicht eine Versionskontrolle über Git.

helm ls -n argocd

Überprüfen Sie nun, ob die Helm-Veröffentlichung erfolgreich war:

NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
argocd  argocd          1               2022-03-23 11:22:48.486199 +0200 EET    deployed        argo-cd-4.9.4   v2.4.0

Die Ausgabe sieht ähnlich aus wie (der Wert der STATUS-Spalte sollte auf deployed gesetzt werden):

kubectl get deployments -n argocd

Zum Schluss überprüfen Sie den Bereitstellungsstatus der Argo CD-Anwendung:

Output
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
argocd-applicationset-controller   1/1     1            1           2m9s
argocd-dex-server                  1/1     1            1           2m9s
argocd-notifications-controller    1/1     1            1           2m9s
argocd-redis-ha-haproxy            3/3     3            3           2m9s
argocd-repo-server                 2/2     2            2           2m9s
argocd-server                      2/2     2            2           2m9s

Die Ausgabe sieht ähnlich aus wie (überprüfen Sie die READY-Spalte – alle Pods müssen ausgeführt werden):

Der Argo CD-Server muss einen minimalen Wert von 2 für den replicaset im HA-Modus haben. Wenn aus irgendeinem Grund einige Bereitstellungen nicht gesund sind, überprüfen Sie bitte die Kubernetes-Ereignisse und Protokolle für die betroffenen Komponenten-Pods.

Sie können auch weitere Informationen zum Argo CD Helm-Chart erhalten, indem Sie das von der Community gepflegte Repository aufrufen.

Als nächstes erfahren Sie, wie Sie auf die wichtigsten Funktionen der grafischen Benutzeroberfläche von Argo CD zugreifen und diese erkunden können.

Aufrufen und Erkunden der Argo CD-Webbenutzeroberfläche

Eine der praktischen Funktionen, die Argo CD bietet, ist die Web-Benutzeroberfläche, die zur Durchführung verschiedener administrativer Aufgaben und zur Anzeige des Anwendungsdeploymentsstatus verwendet wird. Sie können Anwendungen mithilfe der grafischen Benutzeroberfläche erstellen und auf verschiedene Weise mit Argo CD interagieren. Eine weitere wichtige Funktion ist die Möglichkeit, den Zustand jeder Anwendung zu überprüfen und auf Kubernetes-Ereignisse sowie auf die Protokolle Ihrer Anwendung zuzugreifen. Darüber hinaus bietet Argo CD eine visuelle Darstellung aller von jedem Anwendungsdeployment verwendeten Kubernetes-Objekte (Replikasets, Pods usw.).

kubectl port-forward svc/argocd-server -n argocd 8080:443

Die Web-Benutzeroberfläche kann durch Port-Weiterleitung des Kubernetes-Dienstes argocd-server aufgerufen werden. Bitte führen Sie den folgenden Befehl in einem Shell-Terminal aus:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Öffnen Sie nun einen Webbrowser und navigieren Sie zu localhost:8080 (Bitte ignorieren Sie vorerst die ungültigen TLS-Zertifikate). Sie werden mit der Anmeldeseite von Argo CD begrüßt. Der Standardadministrator-Benutzername lautet admin, und das Passwort wird zufällig zur Installationszeit generiert. Sie können es abrufen, indem Sie den folgenden Befehl ausführen:

Anschließend werden Sie zur Anwendungs-Dashboard-Seite weitergeleitet. Von hier aus können Sie Anwendungen über die Benutzeroberfläche anzeigen, erstellen oder verwalten (ein YAML-Editor ist ebenfalls verfügbar), sowie Synchronisierungs- oder Aktualisierungsvorgänge durchführen:

Wenn Sie auf eine beliebige Anwendungskachel klicken, wird auch eine visuelle Darstellung aller beteiligten Objekte angezeigt:

In der nächsten Sektion können Sie Ihre Anwendungsprojekte, Repositories und Cluster verwalten:

Zuletzt zeigt der Benutzerinfo-Bereich die verfügbaren Benutzer an und ermöglicht die Aktualisierung des Administratorpassworts:

Sie können mit jedem Abschnitt und Unterabschnitt herumspielen und diese detailliert erkunden, um alle verfügbaren Funktionen zu sehen. Als nächstes lernen Sie, wie Sie das CLI-Gegenstück namens argocd verwenden.

Kennenlernen des Argo CD CLI

argocd
Usage:
  argocd [flags]
  argocd [command]

Available Commands:
  account     Manage account settings
  admin       Contains a set of commands useful for Argo CD administrators and requires direct Kubernetes access
  app         Manage applications
  cert        Manage repository certificates and SSH known hosts entries
  cluster     Manage cluster credentials
  completion  output shell completion code for the specified shell (bash or zsh)
  context     Switch between contexts
  gpg         Manage GPG keys used for signature verification
  help        Help about any command
...

Argo CD ermöglicht die Verwendung desselben Satzes von Funktionen sowohl über die Web-Schnittstelle als auch über die Befehlszeilenschnittstelle (CLI). Um das argocd-CLI zu verwenden, müssen Sie ein separates Shell-Fenster öffnen und einfach argocd ohne Argumente eingeben. Standardmäßig werden die verfügbaren Befehle und Optionen angezeigt:

argocd app --help

Für jeden Befehl oder Subbefehl können Sie die entsprechende Hilfe-Seite mit dem folgenden Muster aufrufen: argocd <Befehl/Subbefehl> --help. Wenn Sie beispielsweise überprüfen möchten, welche Optionen für den Befehl app verfügbar sind:

Manage Applications
Usage:
  argocd app [flags]
  argocd app [command]

Examples:
  Die Ausgabe sieht ähnlich aus:
  argocd app list
  
  # Listet alle Anwendungen auf.
  argocd app get my-app
...

# Ruft die Details einer Anwendung ab

Bitte erkunden Sie auch andere Befehle/Subbefehle, um alle verfügbaren Optionen zu sehen. Als nächstes lernen Sie, wie Sie Ihre erste Argo CD-Anwendung initialisieren, die automatisch alle Komponenten des Starter Kits bereitstellt.

Bootstrapping Argo CD Anwendungen

Bei einer frischen Installation weiß Argo CD nicht, woher es Ihre Anwendungen synchronisieren soll oder welche Git-Repositorys zum Beziehen von Anwendungsmanifesten verfügbar sind. Der erste Schritt besteht daher darin, eine einmalige Operation namens Bootstrapping durchzuführen. Sie können alle in diesem Abschnitt vorgestellten Operationen entweder über die argocd-Befehlszeilenschnittstelle oder die grafische Benutzeroberfläche ausführen.

Es gibt mehrere Möglichkeiten, Ihren Cluster zu bootstrappen (z. B. über Skripte), aber normalerweise verwenden Argo CD-Benutzer das Muster App von Apps. Das bedeutet, dass Sie damit beginnen, eine übergeordnete Anwendung mithilfe der good-Befehlszeile (oder der Web-Benutzeroberfläche) zu erstellen, die wiederum auf die übrigen Anwendungen in Ihrem Kubernetes-Cluster verweist und diese bootstrapped.

Vorbereiten des Git-Repository-Layouts

clusters
└── dev
    └── helm
        ├── cert-manager-v1.8.0.yaml
        ├── nginx-v4.1.3.yaml
        ├── prometheus-stack-v35.5.1.yaml
        ├── sealed-secrets-v2.4.0.yaml
        └── velero-v2.29.7.yaml

Zuerst müssen Sie Ihr Git-Repository vorbereiten, um ein konsistentes Layout zu verwenden. Im folgenden Beispiel erstellen Sie eine Git-Repository-Layoutstruktur ähnlich wie:

  1. Bitte öffnen Sie ein Terminal und befolgen Sie die untenstehenden Schritte, um das Layout für Ihr Git-Repository zu erstellen:
git clone <YOUR_ARGOCD_GIT_REPOSITORY_ADDRESS>
  1. Zuerst klonen Sie Ihr Git-Repository, das für das Testen von Argo CD verwendet wird (stellen Sie sicher, dass Sie die Platzhalter <> entsprechend ersetzen):
cd <YOUR_GIT_REPO_LOCAL_COPY_DIRECTORY>
mkdir -p clusters/dev/helm
  1. Anschließend wechseln Sie in Ihr lokales Verzeichnis und erstellen die Verzeichnisstruktur (stellen Sie sicher, dass Sie die Platzhalter <> entsprechend ersetzen):
CERT_MANAGER_CHART_VERSION="1.8.0"
NGINX_CHART_VERSION="4.1.3"
PROMETHEUS_CHART_VERSION="35.5.1"
SEALED_SECRETS_CHART_VERSION="2.4.0"
VELERO_CHART_VERSION="2.29.7"

curl "https://raw.githubusercontent.com/digitalocean/Kubernetes-Starter-Kit-Developers/main/14-continuous-delivery-using-gitops/assets/manifests/argocd/applications/helm/cert-manager-v${CERT_MANAGER_CHART_VERSION}.yaml" > "clusters/dev/helm/cert-manager-v${CERT_MANAGER_CHART_VERSION}.yaml"

curl "https://raw.githubusercontent.com/digitalocean/Kubernetes-Starter-Kit-Developers/main/14-continuous-delivery-using-gitops/assets/manifests/argocd/applications/helm/nginx-v${NGINX_CHART_VERSION}.yaml" > "clusters/dev/helm/nginx-v${NGINX_CHART_VERSION}.yaml"

curl "https://raw.githubusercontent.com/digitalocean/Kubernetes-Starter-Kit-Developers/main/14-continuous-delivery-using-gitops/assets/manifests/argocd/applications/helm/prometheus-stack-v${PROMETHEUS_CHART_VERSION}.yaml" > "clusters/dev/helm/prometheus-stack-v${PROMETHEUS_CHART_VERSION}.yaml"

curl "https://raw.githubusercontent.com/digitalocean/Kubernetes-Starter-Kit-Developers/main/14-continuous-delivery-using-gitops/assets/manifests/argocd/applications/helm/sealed-secrets-v${SEALED_SECRETS_CHART_VERSION}.yaml" > "clusters/dev/helm/sealed-secrets-v${SEALED_SECRETS_CHART_VERSION}.yaml"

curl "https://raw.githubusercontent.com/digitalocean/Kubernetes-Starter-Kit-Developers/main/14-continuous-delivery-using-gitops/assets/manifests/argocd/applications/helm/velero-v${VELERO_CHART_VERSION}.yaml" > "clusters/dev/helm/velero-v${VELERO_CHART_VERSION}.yaml"
  1. Kopieren Sie die Anwendungsmanifeste, die für jeden Bestandteil im Starter Kit-Repository bereitgestellt werden (Sie können auch einen Blick darauf werfen und sehen, wie jedes Manifest strukturiert ist):

Zum Schluss übernehmen Sie die Änderungen und pushen sie zum Ursprung.

Als Nächstes erstellen Sie die Bereitstellung der übergeordneten Anwendung und lassen Argo CD alle Starter Kit-Anwendungen automatisch auf Ihrem DOKS-Cluster synchronisieren.

Verwendung des App-of-Apps-Musters über die Argo CD-Befehlszeilenschnittstelle

In diesem Abschnitt erfahren Sie, wie Sie die argocd-Befehlszeilenschnittstelle verwenden, um das App-of-Apps-Muster zu erstellen und zu nutzen, um alle Bestandteile des Starter Kits in Ihrem DOKS-Cluster bereitzustellen. Das folgende Bild veranschaulicht das Hauptkonzept:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Zuerst müssen Sie den Hauptserver von Argo CD auf Ihrem lokalen Rechner in einem separaten Terminalfenster weiterleiten:

ADMIN_USER="admin"
ADMIN_PASSWD="$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)"
argocd login localhost:8080 --username $ADMIN_USER --password $ADMIN_PASSWD --insecure

Als nächstes ist der Zugriff auf den Argo CD-API-Server erforderlich, damit das argocd-CLI funktioniert. Verwenden Sie ein weiteres Terminalfenster, um den argocd-Client mit Ihrer Argo CD-Serverinstanz zu authentifizieren:

Output
'admin:login' logged in successfully
Context 'localhost:8080' updated

Die Ausgabe sieht ähnlich aus:

argocd app create starter-kit-apps \
    --dest-namespace argocd \
    --dest-server https://kubernetes.default.svc \
    --repo https://github.com/<YOUR_GITHUB_USERNAME>/<YOUR_ARGOCD_GITHUB_REPO_NAME>.git \
    --path clusters/dev/helm

Dann führen Sie bitte den folgenden Befehl aus, um die Elternanwendung starter-kit-apps zu erstellen (stellen Sie sicher, dass Sie die Platzhalter <> entsprechend ersetzen):

  • –dest-namespace argocd \
  • –dest-server https://kubernetes.default.svc \
  • Der obige Befehl erstellt eine neue Argo CD-Anwendung namens starter-kit-apps im Namespace argocd, konfiguriert für:

Zielen Sie auf denselben Kubernetes-Cluster ab, in dem Argo CD bereitgestellt ist, da --dest-server auf https://kubernetes.default.svc gesetzt ist.

argocd app sync starter-kit-apps

Verwenden Sie das GitHub-Repository, das durch das Argument --repo festgelegt ist, um Ihren Cluster zu synchronisieren.

Output
TIMESTAMP                  GROUP        KIND             NAMESPACE   NAME                       STATUS     HEALTH  ...
2022-03-23T17:39:38+02:00  argoproj.io  Application      argocd      sealed-secrets-controller  OutOfSync  Missing ...            
2022-03-23T17:39:38+02:00  argoproj.io  Application      argocd      velero                     OutOfSync  Missing ...             
2022-03-23T17:39:38+02:00  argoproj.io  Application      argocd      ingress-nginx              OutOfSync  Missing ...
...
GROUP        KIND         NAMESPACE  NAME                       STATUS  HEALTH  HOOK  MESSAGE
argoproj.io  Application  argocd     sealed-secrets-controller  Synced                application.argoproj.io/sealed-secrets-controller created
argoproj.io  Application  argocd     ingress-nginx              Synced                application.argoproj.io/ingress-nginx created
argoproj.io  Application  argocd     kube-prometheus-stack      Synced                application.argoproj.io/kube-prometheus-stack created
argoproj.io  Application  argocd     velero                     Synced                application.argoproj.io/velero created
argoproj.io  Application  argocd     cert-manager               Synced                application.argoproj.io/cert-manager created

Scannen und anwenden aller Anwendungsmanifeste, die im Verzeichnis clusters/dev/helm gefunden wurden (--path Argument).

Als nächstes müssen Sie die Anwendung starter-kit-apps synchronisieren (denken Sie daran, dass Argo CD standardmäßig nichts synchronisiert, es sei denn, es wird explizit angegeben):

argocd app list

Die Ausgabe sieht ähnlich aus:

Output
NAME                       CLUSTER                         NAMESPACE       PROJECT  STATUS     HEALTH   SYNCPOLICY  ...
ingress-nginx              https://kubernetes.default.svc  ingress-nginx   default  OutOfSync  Missing  Auto-Prune  ...
cert-manager               https://kubernetes.default.svc  cert-manager    default  OutOfSync  Missing  Auto-Prune  ...
kube-prometheus-stack      https://kubernetes.default.svc  monitoring      default  OutOfSync  Missing  Auto-Prune  ...
sealed-secrets-controller  https://kubernetes.default.svc  sealed-secrets  default  OutOfSync  Missing  Auto-Prune  ...
starter-kit-apps           https://kubernetes.default.svc  argocd          default  Synced     Healthy  <none>      ...  
velero                     https://kubernetes.default.svc  velero          default  OutOfSync  Missing  Auto-Prune  ...

Nachdem der obige Befehl abgeschlossen ist, sollten Sie eine neue Anwendung im Hauptdashboard Ihres Argo CD-Servers sehen. Öffnen Sie einen Webbrowser und navigieren Sie zu http://localhost:8080. Wählen Sie dann den Applications-Tab aus und klicken Sie auf die Kachel starter-kit-apps (achten Sie auf das App von Apps-Muster, indem Sie sich den Kompositionsgraphen ansehen):

argocd app sync -l argocd.argoproj.io/instance=starter-kit-apps

Sie können auch die neuen Anwendungen über die Befehlszeilenschnittstelle inspizieren:

Die Ausgabe sieht ähnlich aus wie:

argocd app list

Die Elternanwendung starter-kit-apps erscheint als in Sync, aber die Kindanwendungen sind nicht synchron. Als nächstes können Sie entweder alles über die Web-Schnittstelle oder über die Befehlszeile synchronisieren:

Output
NAME                       CLUSTER                         NAMESPACE       PROJECT  STATUS    HEALTH   SYNCPOLICY  CONDITIONS ...
ingress-nginx              https://kubernetes.default.svc  ingress-nginx   default  Synced    Healthy  Auto-Prune  <none>     ...
cert-manager               https://kubernetes.default.svc  cert-manager    default  Synced    Healthy  Auto-Prune  <none>     ...
kube-prometheus-stack      https://kubernetes.default.svc  monitoring      default  Synced    Healthy  Auto-Prune  <none>     ...
sealed-secrets-controller  https://kubernetes.default.svc  sealed-secrets  default  Synced    Healthy  Auto-Prune  <none>     ...
starter-kit-apps           https://kubernetes.default.svc  argocd          default  Synced    Healthy  <none>      <none>     ...
velero                     https://kubernetes.default.svc  velero          default  OutOfSync Missing  Auto-Prune  SyncError  ...

Die Synchronisierungsoperation kann einige Zeit dauern (sogar bis zu 5-10 Minuten), abhängig von der Komplexität und Anzahl der Kubernetes-Objekte aller bereitgestellten Anwendungen.

Nach einer Weile listen Sie bitte erneut alle Anwendungen auf:

argocd app create starter-kit-apps \
  --dest-namespace argocd \
  --dest-server https://kubernetes.default.svc \
  -repo https://github.com/<YOUR_GITHUB_USERNAME>/<YOUR_ARGOCD_GITHUB_REPO_NAME>.git \
  --path clusters/dev/helm \
   --sync-policy automated \
  --auto-prune \
  --self-heal
  • Die Ausgabe sieht ähnlich aus wie (achten Sie darauf, dass jetzt alle Anwendungen synchronisiert sind):
argocd app get velero

Die Bereitstellung der Velero-Anwendung wird absichtlich fehlschlagen und im Zustand SyncError belassen, damit der Leser sich mit der Diagnose von Anwendungsproblemen in Argo CD vertraut machen und lernen kann. Bitte konsultieren Sie den Abschnitt Hinweise unten, um zu sehen, wie Sie Argo CD-Anwendungsprobleme diagnostizieren können.
Das Bootstrapping der übergeordneten Anwendung ist eine einmalige Operation. Bei nachfolgenden Git-Änderungen für jede Anwendung erkennt Argo CD die Abweichung und wendet die erforderlichen Änderungen an. Argo CD verwendet standardmäßig einen Abfragemechanismus, um Änderungen in Ihrem Git-Repository zu erkennen. Das Standard-Aktualisierungsintervall ist auf 3 Minuten eingestellt. Anstatt sich auf einen Abfragemechanismus zu verlassen, können Sie auch die Leistung von Git-Webhooks nutzen. Bitte besuchen Sie die offizielle Dokumentationswebsite, um zu erfahren, wie Sie Argo CD konfigurieren und einrichten können, um Git-Webhooks zu verwenden.

Output
 Name:               velero
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          velero
URL:                https://argocd.example.com/applications/velero
Repo:               https://vmware-tanzu.github.io/helm-charts
Target:             2.27.3
 Path:               
SyncWindow:         Sync Allowed
Sync Policy:        Automated (Prune)
Sync Status:        OutOfSync from 2.27.3
Health Status:      Missing
CONDITION  MESSAGE                                                                                          LAST TRANSITION
SyncError  Failed sync attempt to 2.27.3: one or more objects failed to apply (dry run) (retried 5 times).  2022-03-24 12:14:21 +0200 EET
 GROUP                      KIND                      NAMESPACE  NAME                               STATUS     HEALTH      HOOK      MESSAGE
velero.io                  VolumeSnapshotLocation    velero     default                            Failed     SyncFailed  PostSync  error validating data: ValidationError(VolumeSnapshotLocation.spec): missing required field "provider" in io.velero.v1.VolumeSnapshotLocation.spec
velero.io                  BackupStorageLocation     velero     default                            Failed     SyncFailed  PostSync  error validating data: [ValidationError(BackupStorageLocation.spec.objectStorage): missing required field "bucket" in io.velero.v1.BackupStorageLocation.spec.objectStorage, ValidationError(BackupStorageLocation.spec): missing required field "provider" in io.velero.v1.BackupStorageLocation.spec]
...

Hinweise: Wenn gewünscht, können Sie die übergeordnete Anwendung so konfigurieren, dass sie automatisch synchronisiert wird (und auch Selbstheilung und automatisches Beschneiden aktivieren). Verwenden Sie dazu den folgenden Befehl (vergessen Sie nicht, die Platzhalter <> entsprechend zu ersetzen):

–dest-namespace argocd \

–dest-server https://kubernetes.default.svc \

–sync-policy automated \

–auto-prune \

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Im Falle von Synchronisierungsfehlern können Sie immer die Kubernetes-Ereignisse für die betreffende Anwendung überprüfen (über argocd app get <application_name>):

Die Ausgabe sieht ähnlich aus:

  • Als nächstes lernen Sie, wie Sie das App of Apps-Muster verwenden und dieselben Schritte über die grafische Benutzeroberfläche von Argo CD ausführen.
  • Verwendung des App-of-Apps-Musters über die Argo CD-Webbenutzeroberfläche
  • In diesem Abschnitt lernen Sie, wie Sie die Argo CD-Webbenutzeroberfläche verwenden, um das App of Apps-Muster zu erstellen und alle Starter-Kit-Komponenten in Ihrem DOKS-Cluster bereitzustellen. Das folgende Bild veranschaulicht das Hauptkonzept:
  • Wie das obige Diagramm zeigt, ist das Bootstrapping einer neuen Anwendung über die Webbenutzeroberfläche sehr ähnlich wie beim CLI-Gegenstück. Der einzige Unterschied besteht darin, dass Sie zwischen verschiedenen Panels/Fenstern navigieren und point-and-click-Operationen verwenden. Hinter den Kulissen wird Argo CD die erforderlichen Anwendungs-CRDs erstellen und Änderungen an Ihrem Kubernetes-Cluster vornehmen.
  • Öffnen Sie zuerst einen Webbrowser und melden Sie sich in der Argo CD-Webkonsole an. Der Standardbenutzername lautet admin, und das Standardpasswort erhalten Sie über:
  • Sobald Sie angemeldet sind, werden Sie zur Dashboard-Seite der Anwendungen weitergeleitet (bei einer frischen Installation ist das Dashboard leer). Klicken Sie dann auf die Schaltfläche Anwendung erstellen. Es erscheint ein neues Panel, das nach Anwendungsdetails fragt:
  • Bitte füllen Sie jedes Feld entsprechend aus:

Anwendungsname: Der neue Anwendungsname (z.B. starter-kit-apps).

Projekt: Der Name des Projekts, zu dem diese Anwendung gehört (wenn Sie Argo CD zum ersten Mal verwenden, können Sie default verwenden).

Synchronisierungsrichtlinie und Synchronisierungsoptionen: Konfigurieren Sie die Synchronisierungsrichtlinie und -optionen (z.B. Manuell, Automatisch, Anzahl der Wiederholungsversuche, Intervall zwischen Wiederholungsversuchen, usw.).

Repository-URL der Quelle: Die URL Ihres GitHub-Repositorys – z.B. https://github.com/<IHR_GITHUB_BENUTZERNAME>/<IHR_ARGOCD_GITHUB_REPO_NAME>.git.

Pfad der Quelle: Pfad im GitHub-Repository, in dem Anwendungsmanifeste gespeichert sind (z.B. clusters/dev/helm).

Cluster-URL des Ziels: Ziel-Kubernetes-Cluster, der mit Ihrem GitHub-Repository synchronisiert werden soll (z.B. https://kubernetes.default.svc für den lokalen Cluster, auf dem Argo CD bereitgestellt ist).

Namespace des Ziels: Ziel-Kubernetes-Cluster-Namespace, der für Argo CD-Anwendungen verwendet werden soll (argocd, normalerweise).

Nachdem Sie alle Anwendungsdetails ausgefüllt haben, klicken Sie oben auf die Schaltfläche „Erstellen“. Ein neues Anwendungskachel wird auf der Dashboard-Seite angezeigt:

Wenn Sie auf das Anwendungskachel klicken, können Sie das App von Apps-Muster beobachten, indem Sie sich den Kompositionsgraphen ansehen:

Wenn Sie das obige Bild betrachten, werden Sie feststellen, dass alle Anwendungen als OutOfSync markiert sind. Der nächste Schritt besteht darin, einen Synchronisierungsvorgang auf der übergeordneten Anwendung auszulösen. Dann werden auch alle untergeordneten Anwendungen synchronisiert. Bitte drücken Sie die Sync-Schaltfläche auf der Kachel der übergeordneten Anwendung. Auf der rechten Seite wird ein neues Panel geöffnet (beachten Sie, dass alle untergeordneten Apps unten ausgewählt sind):

Lassen Sie die Standardwerte wie sie sind, drücken Sie dann auf die Schaltfläche Synchronisieren oben und beobachten Sie, wie Argo CD den Synchronisierungsvorgang auf alle Anwendungen überträgt:

Die Bereitstellung der Velero-Anwendung wird fehlschlagen und absichtlich im Zustand SyncError belassen, damit der Leser sich mit der Diagnose von Anwendungsproblemen in Argo CD vertraut machen und lernen kann. Bitte konsultieren Sie den Abschnitt Hinweise unten, um zu sehen, wie Sie Argo CD Anwendungsprobleme diagnostizieren können.

Wenn alles gut läuft, sollten alle Anwendungen einen grünen Rand haben und der Status sollte Healthy und Synced sein. Der Bootstrap-Vorgang ist ein einmaliger Vorgang. Bei nachfolgenden Git-Änderungen für jede Anwendung erkennt Argo CD die Abweichung und wendet die erforderlichen Änderungen an. Argo CD verwendet standardmäßig einen Abfrage-Mechanismus, um Änderungen in Ihrem Git-Repository zu erkennen. Das Standard-Aktualisierungsintervall ist auf 3 Minuten festgelegt. Anstatt sich auf einen Abfrage-Mechanismus zu verlassen, können Sie auch die Leistungsfähigkeit von Git-Webhooks nutzen. Besuchen Sie bitte die offizielle Dokumentationswebsite, um zu erfahren, wie Sie Argo CD konfigurieren und einrichten können, um Git-Webhooks.

Hinweise:
Wenn gewünscht, können Sie die übergeordnete Anwendung so konfigurieren, dass sie automatisch synchronisiert wird, indem Sie den Wert des Felds SYNC POLICY auf Automatisch setzen. Um die Selbstheilung und das automatische Bereinigen zu aktivieren, aktivieren Sie die Kontrollkästchen PRUNE RESOURCES und SELF HEAL:

Im Falle von Synchronisierungsfehlern können Sie jederzeit die Kubernetes-Ereignisse für die betroffene Anwendung überprüfen. Über die Webschnittstelle können Sie zur betroffenen Anwendungskachel navigieren:

Dann klicken Sie auf den Sync failed-Nachrichtslink, der in roter Farbe markiert ist, aus dem Abschnitt LAST SYNC RESULT im Header der Anwendungsseite. Es öffnet sich ein neues Panel, das nützliche Informationen darüber anzeigt, warum die Synchronisierungsoperation fehlgeschlagen ist:

Application Sets ist eine weitere leistungsstarke Funktion, die von Argo CD angeboten wird. Der ApplicationSet Controller ist ein Unterprojekt von Argo CD, das Anwendungsautomatisierung über vordefinierte Vorlagen hinzufügt. Diese Funktion hilft Ihnen, Wiederholungen in Ihren Anwendungsmanifesten zu vermeiden (nutzt das DRY-Prinzip aus).

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app
spec:
  generators:
    - list:
        elements:
          - cluster: dev
            url: https://kubernetes.dev.svc
          - cluster: qa
            url: https://kubernetes.qa.svc
          - cluster: prod
            url: https://kubernetes.prod.svc
  template:
    metadata:
      name: '{{cluster}}-app'
    spec:
      project: default
      source:
        repoURL: https://github.com/myrepo/my-applicationset.git
        targetRevision: HEAD
        path: clusters/{{cluster}}/my-apps
      destination:
        server: '{{url}}'
        namespace: argocd

Der ApplicationSet-Controller ist neben Argo CD installiert (im selben Namespace), und er generiert automatisch Argo CD-Anwendungen basierend auf dem Inhalt eines neuen ApplicationSet-Custom Resources (CR).

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: dev-app
spec:
  project: default
  source:
    repoURL: https://github.com/myrepo/my-applicationset.git
    targetRevision: HEAD
    path: clusters/dev/my-apps
  destination:
    server: https://kubernetes.dev.svc
    namespace: argocd

Hinweis:
Ab Version 2.3.x von Argo CD müssen Sie den ApplicationSet Controller nicht separat installieren, da er Teil der Hauptinstallation von Argo CD ist. Das Starter-Kit verwendet Version >= 2.3.1, daher müssen Sie nichts ändern.

Die Hauptidee eines ApplicationSet basiert darauf, eine Liste von Werten als Generator zu haben und eine Vorlage, die durch die Eingabewerte der Liste bevölkert wird. Für jedes Element aus der Liste wird eine neue Anwendungs-Vorlage nacheinander generiert. Im Wesentlichen definieren Sie einen ApplicationSet CRD und lassen ihn dann für Sie so viele ArgoCD Application CRDs generieren, wie Sie möchten, basierend auf den Eingabewerten. Dadurch verwalten Sie alles über ein einzelnes Manifest – das ApplicationSet.

Dieses Konzept vereinfacht auch die Verwaltung von Mehr-Cluster– und Mehr-Umgebungs-Setups durch die Verwendung von parametrisierten Anwendungsvorlagen. Application-Sets enthalten neben Listengeneratoren auch andere Generatoren:

Cluster-Generator: Verwendet von Argo CD definierte Cluster, um Anwendungsvorlagen zu erstellen.

argocd app delete starter-kit-apps

Git-Generator: Verwendet die Dateien/Verzeichnisse eines Git-Repositories, um Anwendungsvorlagen zu erstellen.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
...

Ein typischer ApplicationSet CRD, der einen Listengenerator verwendet, sieht wie folgt aus:

Das Anwenden des obigen ApplicationSet auf Ihren Kubernetes-Cluster wird drei Argo CD-Anwendungen erzeugen. Zum Beispiel wird die Anwendung für die Umgebung dev wie folgt dargestellt:

Template-Engines sind von Natur aus sehr leistungsfähig und bieten viele Möglichkeiten. Besuchen Sie die Hauptdokumentationswebsite von ApplicationSet, um mehr über dieses Feature zu erfahren.

Deinstallieren von Argo CD-Anwendungen

Das Deinstallieren (oder Löschen) von Anwendungen, die von Argo CD verwaltet werden, erfolgt durch Löschen des entsprechenden Manifests aus der Git-Repository-Quelle. Bei Anwendungen, die nach dem App of Apps-Muster erstellt wurden, müssen Sie nur die übergeordnete App löschen (entweder über die Befehlszeile oder die Webschnittstelle). Dann werden alle untergeordneten Anwendungen im Rahmen des Prozesses ebenfalls gelöscht.

  • So löschen Sie die übergeordnete Anwendung starter-kit-apps (einschließlich der Unteranwendungen) mit dem argocd-CLI:
  • Wenn Sie sicherstellen möchten, dass Unteranwendungen und alle ihre Ressourcen gelöscht werden, wenn die übergeordnete Anwendung gelöscht wird, stellen Sie bitte sicher, dass der entsprechende Finalizer zu Ihrer Anwendungsdefinition hinzugefügt wird:

Source:
https://www.digitalocean.com/community/developer-center/implementing-gitops-using-argo-cd