Tutorial: Implementieren von Continuous Integration und Continuous Delivery (CI/CD) mit GitOps unter Verwendung von Kubernetes-Clustern mit Azure Arc-Unterstützung

  • Artikel

Wichtig

In diesem Tutorial wird GitOps mit Flux v1 verwendet. GitOps with Flux v2 ist jetzt für Azure Arc-fähige Kubernetes- und Azure Kubernetes Service (AKS)-Cluster verfügbar. Wechseln Sie zu dem Tutorial, in dem GitOps mit Flux v2 verwendet wird. Wir empfehlen, so schnell wie möglich zu Flux v2 zu migrieren.

Die Unterstützung für Flux v1-basierte Clusterkonfigurationsressourcen, die vor dem 1. Januar 2024 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Januar 2024 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen mehr erstellen.

In diesem Tutorial richten Sie eine CI/CD-Lösung mithilfe von GitOps und Kubernetes-Clustern mit Azure Arc-Unterstützung ein. Unter Verwendung der Azure Vote-Beispiel-App führen Sie folgende Schritte aus:

  • Erstellen eines Kubernetes-Clusters mit Azure Arc-Unterstützung
  • Verbinden Ihrer Anwendung und GitOps-Repositorys mit Azure Repos.
  • Importieren von CI/CD-Pipelines.
  • Verbinden von Azure Container Registry (ACR) mit Azure DevOps und Kubernetes.
  • Erstellen von Gruppen aus Umgebungsvariablen.
  • Bereitstellen der dev- und stage-Umgebungen.
  • Testen der Anwendungsumgebungen.

Wenn Sie kein Azure-Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.

Azure Cloud Shell

Azure hostet Azure Cloud Shell, eine interaktive Shell-Umgebung, die Sie über Ihren Browser nutzen können. Sie können entweder Bash oder PowerShell mit Cloud Shell verwenden, um mit Azure-Diensten zu arbeiten. Sie können die vorinstallierten Befehle von Cloud Shell verwenden, um den Code in diesem Artikel auszuführen, ohne etwas in Ihrer lokalen Umgebung installieren zu müssen.

Starten von Azure Cloud Shell:

Option Beispiel/Link
Wählen Sie rechts oben in einem Code- oder Befehlsblock die Option Ausprobieren aus. Durch die Auswahl von Ausprobieren wird der Code oder Befehl nicht automatisch in Cloud Shell kopiert. Screenshot that shows an example of Try It for Azure Cloud Shell.
Rufen Sie https://shell.azure.com auf, oder klicken Sie auf die Schaltfläche Cloud Shell starten, um Cloud Shell im Browser zu öffnen. Button to launch Azure Cloud Shell.
Wählen Sie im Azure-Portal rechts oben im Menü die Schaltfläche Cloud Shell aus. Screenshot that shows the Cloud Shell button in the Azure portal

So verwenden Sie Azure Cloud Shell:

  1. Starten Sie Cloud Shell.

  2. Wählen Sie die Schaltfläche Kopieren für einen Codeblock (oder Befehlsblock) aus, um den Code oder Befehl zu kopieren.

  3. Fügen Sie den Code oder Befehl mit STRG+UMSCHALT+V unter Windows und Linux oder CMD+UMSCHALT+V unter macOS in die Cloud Shell-Sitzung ein.

  4. Drücken Sie die EINGABETASTE, um den Code oder Befehl auszuführen.

Voraussetzungen

In diesem Tutorial wird davon ausgegangen, dass Sie mit Azure DevOps, Azure Repos und Pipelines sowie der Azure CLI vertraut sind.

Importieren von Anwendungs- und GitOps-Repositorys in Azure Repos

Importieren Sie ein Anwendungsrepository und ein GitOps-Repository in Azure Repos. Verwenden Sie für dieses Tutorial die folgenden Beispielrepositorys:

Weitere Informationen zum Importieren von Git-Repositorys.

Hinweis

Durch den Import und die Verwendung von zwei separaten Repositorys als Anwendungs- und GitOps-Repository lässt sich die Sicherheit verbessern. Außerdem werden die Abläufe vereinfacht. Darüber hinaus lassen sich die Berechtigungen und die Transparenz des Anwendungs- und GitOps-Repositorys einzeln optimieren. Für den Clusteradministrator können die Änderungen am Anwendungscode z. B. möglicherweise für den gewünschten Zustand des Clusters irrelevant sein. Ein Anwendungsentwickler wiederum muss die spezifischen Parameter für die einzelnen Umgebungen nicht kennen. Für ihn sind gegebenenfalls einige Testwerte für die Parameter ausreichend.

Verbinden des GitOps-Repositorys

Verbinden Sie das Anwendungsrepository für eine kontinuierliche Bereitstellung Ihrer App über GitOps mit Ihrem Cluster. Ihr GitOps-Repository arc-cicd-demo-gitops enthält die grundlegenden Ressourcen, um Ihre App in Ihrem arc-cicd-cluster-Cluster bereitzustellen und auszuführen.

Das anfängliche GitOps-Repository umfasst lediglich ein Manifest zum Erstellen der Namespaces dev und stage für die Bereitstellungsumgebungen.

Durch die von Ihnen erstellte GitOps-Verbindung werden automatisch folgende Schritte ausgeführt:

  • Synchronisieren des Manifests im Manifestverzeichnis.
  • Aktualisieren des Clusterstatus.

Der CI/CD-Workflow füllt das Manifestverzeichnis mit zusätzlichen Manifesten zum Bereitstellen der App.

  1. Erstellen Sie eine neue GitOps-Verbindung mit Ihrem neu importierten Repository arc-cicd-demo-gitops in Azure Repos.

    az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

  2. Stellen Sie sicher, dass Flux nur das Verzeichnis arc-cicd-cluster/manifests als Basispfad verwendet. Definieren Sie den Pfad mithilfe des folgenden Operatorparameters:

    --git-path=arc-cicd-cluster/manifests

    Hinweis

    Wenn Sie eine HTTPS-Verbindungszeichenfolge verwenden und Verbindungsprobleme auftreten, stellen Sie sicher, dass Sie das Benutzernamenpräfix in der URL auslassen. Bei https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops muss z. B. alice@ entfernt werden. Der Benutzer wird stattdessen mit --https-user angegeben (z. B. --https-user alice).

  3. Überprüfen Sie den Status der Bereitstellung im Azure-Portal.

    • Bei erfolgreicher Bereitstellung wurden in Ihrem Cluster die Namespaces dev und stage erstellt.

Importieren der CI/CD-Pipelines

Nachdem Sie eine GitOps-Verbindung synchronisiert haben, müssen Sie die CI/CD-Pipelines importieren, mit denen die Manifeste erstellt werden.

Das Anwendungsrepository enthält einen Ordner .pipeline mit den Pipelines, die Sie für PRs, CI und CD verwenden. Importieren Sie die drei Pipelines aus dem Beispielrepository, und benennen Sie sie um:

Pipelinedateiname BESCHREIBUNG
.pipelines/az-vote-pr-pipeline.yaml Die PR-Pipeline der Anwendung mit dem Namen arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Die CI-Pipeline der Anwendung mit dem Namen arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml Die CD-Pipeline der Anwendung mit dem Namen arc-cicd-demo-src CD

Verbinden von ACR

Sowohl Ihre Pipelines als auch Ihr Cluster verwenden ACR zum Speichern und Abrufen von Docker-Images.

Verbinden von ACR mit Azure DevOps

Während des CI-Prozesses stellen Sie Ihre Anwendungscontainer in einer Registrierung bereit. Erstellen Sie dazu zunächst eine Azure-Dienstverbindung:

  1. Öffnen Sie in Azure DevOps auf der Seite mit den Projekteinstellungen die Seite Dienstverbindungen. Öffnen Sie in TFS über das Symbol Einstellungen in der oberen Menüleiste die Seite Dienste.
  2. Wählen Sie + Neue Dienstverbindung und dann den Typ der Dienstverbindung aus, den Sie benötigen.
  3. Geben Sie die Parameter für die Dienstverbindung ein. Verwenden Sie für dieses Tutorial Folgendes:
    • Geben Sie für die Dienstverbindung den Namen arc-demo-acr ein.
    • Wählen Sie als Ressourcengruppe myResourceGroup aus.
  4. Wählen Sie die Option Allen Pipelines die Zugriffsberechtigung gewähren aus.
    • Mit dieser Option werden YAML-Pipelinedateien für Dienstverbindungen autorisiert.
  5. Wählen Sie OK aus, um die Verbindung zu erstellen.

Verbinden von ACR mit Kubernetes

Ermöglichen Sie es Ihrem Kubernetes-Cluster, Images aus ACR zu pullen. Bei einer privaten Konfiguration ist eine Authentifizierung erforderlich.

Verbinden von ACR mit vorhandenen AKS-Clustern

Integrieren Sie eine vorhandene ACR-Instanz über den folgenden Befehl mit vorhandenen AKS-Clustern:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Erstellen eines Geheimnisses für Imagepullvorgänge

Um Nicht-AKS- und lokale Cluster mit ACR zu verbinden, erstellen Sie ein Geheimnis für den Imagepullvorgang. Kubernetes verwendet Geheimnisse für Imagepullvorgänge, um die erforderlichen Informationen für die Authentifizierung Ihrer Registrierung zu speichern.

Verwenden Sie den folgenden kubectl-Befehl, um ein Geheimnis für Imagepullvorgänge zu erstellen. Wiederholen Sie diesen Schritt für die Namespaces dev und stage.

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Um zu vermeiden, dass für jeden Pod ein Geheimnis für Imagepullvorgänge festgelegt werden muss, kann das Geheimnis für Imagepullvorgänge gegebenenfalls zum Dienstkonto in den Namespaces dev und stage hinzugefügt werden. Weitere Informationen finden Sie im Kubernetes-Tutorial.

Erstellen von Gruppen aus Umgebungsvariablen

Variablengruppe des Anwendungsrepositorys

Erstellen Sie eine Variablengruppe mit dem Namen az-vote-app-dev. Legen Sie die folgenden Werte fest:

Variable Wert
AZ_ACR_NAME (Ihre ACR-Instanz, z. B. azurearctest.azurecr.io)
AZURE_SUBSCRIPTION (Ihre Azure-Dienstverbindung, in diesem Fall die weiter oben in diesem Tutorial genannte Verbindung arc-demo-acr)
AZURE_VOTE_IMAGE_REPO Der vollständige Pfad zum Repository der Azure Vote-App (z. B. azurearctest.azurecr.io/azvote)
ENVIRONMENT_NAME Entwicklung
MANIFESTS_BRANCH master
MANIFESTS_FOLDER azure-vote-manifests
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Dies ist der Name der Azure DevOps-Organisation.
PROJECT_NAME Dies ist der Name des GitOps-Projekts in Azure DevOps.
REPO_URL Dies ist die vollständige URL für das GitOps-Repository.
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev

Stagen der Gruppe aus Umgebungsvariablen

  1. Klonen Sie die Variablengruppe az-vote-app-dev.
  2. Ändern Sie den Namen in az-vote-app-stage.
  3. Stellen Sie sicher, dass die folgenden Werte für die entsprechenden Variablen festgelegt sind:
Variable Wert
ENVIRONMENT_NAME Phase
TARGET_NAMESPACE stage

Sie können die dev- und stage-Umgebungen jetzt bereitstellen.

Erteilen von weiteren Berechtigungen für den Builddienst

Die CD-Pipeline verwendet das Sicherheitstoken des ausgeführten Builds zur Authentifizierung beim GitOps-Repository. Für die Pipeline sind weitere Berechtigungen erforderlich, um einen neuen Branch zu erstellen, Änderungen zu pushen und Pull Requests zu erstellen.

  1. Wechseln Sie von der Hauptseite des Azure DevOps-Projekts zu Project settings.
  2. Wählen Sie Repositories aus.
  3. Wählen Sie <GitOps Repo Name> aus.
  4. Wählen Sie Security aus.
  5. Lassen Sie für <Project Name> Build Service (<Organization Name>) die Optionen Contribute, Contribute to pull requests und Create branch zu.

Weitere Informationen finden Sie unter

Erstmaliges Bereitstellen der Entwicklungsumgebung

Nachdem Sie die CI- und CD-Pipelines erstellt haben, führen Sie die CI-Pipeline aus, um die App erstmalig bereitzustellen.

CI-Pipeline

Bei der ersten Ausführung der CI-Pipeline wird möglicherweise ein Ressourcenautorisierungsfehler beim Lesen des Dienstverbindungsnamens ausgegeben.

  1. Überprüfen Sie, ob auf die Variable AZURE_SUBSCRIPTION zugegriffen wird.
  2. Autorisieren Sie die Verwendung.
  3. Führen Sie die Pipeline erneut aus.

Die CI-Pipeline:

  • Stellt sicher, dass die Anwendungsänderung alle automatisierten Qualitätsprüfungen für die Bereitstellung besteht.
  • Führt zusätzliche Validierungsschritte durch, die in der PR-Pipeline nicht abgeschlossen werden konnten.
    • Bei GitOps veröffentlicht die Pipeline zudem die Artefakte für den Commit, die durch die CD-Pipeline bereitgestellt werden.
  • Überprüft, ob das Docker-Image geändert wurde und das neue Image per Push übertragen wird.

CD-Pipeline

Während der ersten Ausführung der CD-Pipeline werden Sie aufgefordert, der Pipeline Zugriff auf das GitOps-Repository zu geben. Wählen Sie „Anzeigen“ aus, wenn angegeben wird, dass die Pipeline die Berechtigung für den Zugriff auf eine Ressource benötigt. Wählen Sie dann Zulassen aus, um die Berechtigung zum Verwenden des GitOps-Repositorys für die aktuellen und zukünftigen Pipelineausführungen zu erteilen.

Bei erfolgreicher Ausführung der CI-Pipeline wird das Abschließen des Bereitstellungsvorgangs durch die CD-Pipeline ausgelöst. Die einzelnen Umgebungen werden inkrementell bereitgestellt.

Tipp

Falls die CD-Pipeline nicht automatisch ausgelöst wird:

  1. Überprüfen Sie, ob der Name mit dem Branchauslöser in .pipelines/az-vote-cd-pipeline.yaml übereinstimmt
    • Dort sollte arc-cicd-demo-src CI stehen.
  2. Führen Sie die CI-Pipeline erneut aus.

Nachdem die Vorlagen- und Manifeständerungen für das GitOps-Repository generiert wurden, erstellt die CD-Pipeline einen Commit, führt einen Push aus und erstellt einen PR zur Genehmigung.

  1. Öffnen Sie den PR-Link in der Create PR-Taskausgabe.

  2. Überprüfen Sie die Änderungen am GitOps-Repository. Folgendes sollte angezeigt werden:

    • High-Level-Änderungen der Helm-Vorlage.
    • Low-Level-Kubernetes-Manifeste, die die zugrunde liegenden Änderungen am gewünschten Zustand zeigen. Diese Manifeste werden über Flux bereitgestellt.

  3. Wenn alles gut aussieht, bestätigen Sie den PR, und führen Sie ihn aus.

  4. Nach ein paar Minuten erkennt Flux die Änderung und startet die Bereitstellung.

  5. Leiten Sie den Port lokal mithilfe von kubectl weiter, und stellen Sie sicher, dass die App korrekt funktioniert. Verwenden Sie dazu folgenden Befehl:

    kubectl port-forward -n dev svc/azure-vote-front 8080:80

  6. Rufen Sie die Azure Vote-App in Ihrem Browser unter http://localhost:8080/ auf.

  7. Stimmen Sie für Ihre Favoriten ab, und bereiten Sie sich darauf vor, einige Änderungen an der App vorzunehmen.

Einrichten von Genehmigungen für Umgebungen

Bei der App-Bereitstellung können Sie nicht nur Änderungen am Code oder an Vorlagen vornehmen, sondern unbeabsichtigt auch Vorgänge ausführen, aufgrund derer ein ungültiger Zustand des Clusters ausgelöst wird.

Wenn es in der Entwicklungsumgebung nach der Bereitstellung zu einer Unterbrechung kommt, sollten Sie daher mithilfe von Genehmigungen verhindern, dass diese Probleme in spätere Umgebungen übertragen werden.

  1. Navigieren Sie in Ihrem Azure DevOps-Projekt zur Umgebung, die geschützt werden soll.
  2. Navigieren Sie zu Genehmigungen und Prüfungen für die Ressource.
  3. Klicken Sie auf Erstellen.
  4. Geben Sie die genehmigenden Personen und eine optionale Nachricht ein.
  5. Wählen Sie erneut Erstellen aus, um den Vorgang zum Hinzufügen der manuellen Genehmigungsprüfung abzuschließen.

Weitere Einzelheiten finden Sie im Tutorial zum Definieren von Genehmigungen und Prüfungen.

Bei der nächsten Ausführung der CD-Pipeline wird die Pipeline angehalten, nachdem der GitOps-PR erstellt wurde. Überprüfen Sie, ob die Änderung ordnungsgemäß synchronisiert wurde und die grundlegende Funktionalität bietet. Bestätigen Sie die Überprüfung in der Pipeline, damit die Änderung für die nächste Umgebung übernommen wird.

Ändern der Anwendung

Mit diesem Basissatz an Vorlagen und Manifesten für den Zustand des Clusters nehmen Sie nun eine geringfügige Änderung an der App vor.

  1. Bearbeiten Sie im Repository arc-cicd-demo-src die Datei azure-vote/src/azure-vote-front/config_file.cfg.

  2. Da für die Abstimmung zwischen „Cats“ und „Dogs“ nicht genügend Stimmen abgegeben werden, soll nun zwischen „Tabs“ und „Spaces“ abgestimmt werden, um die Anzahl von Stimmen zu erhöhen.

  3. Committen Sie die Änderung in einen neuen Branch, führen Sie dann einen Push durch, und erstellen Sie einen Pull Request.

    • Dies ist der typische Entwicklerflow, der den CI/CD-Lebenszyklus startet.

PR-Validierungspipeline

Die PR-Pipeline ist die erste Schutzebene gegen eine fehlerhafte Änderung. Zu den üblichen Qualitätsprüfungen für Anwendungscode zählen das Linten und eine statische Analyse. Aus GitOps-Sicht müssen Sie dieselbe Qualität für die resultierende Infrastruktur sicherstellen, die bereitgestellt werden soll.

In den Dockerfile- und Helm-Diagrammen der Anwendung kann das Linten auf ähnliche Weise für die Anwendung verwendet werden.

Beim Linten wird u. a. Folgendes ermittelt:

  • Falsch formatierte YAML-Dateien
  • Empfehlungen für bewährte Methoden, z. B. das Festlegen von CPU- und Speichergrenzen für Ihre Anwendung.

Hinweis

Für ein möglichst umfangreiches Helm-Linten in einer echten Anwendung müssen Sie Werte ersetzen, die den in einer echten Umgebung verwendeten Werten am ehesten entsprechen.

Die bei einer Pipelineausführung ermittelten Fehler werden im Abschnitt mit den Testergebnissen der Ausführung angezeigt. Hier können Sie Folgendes tun:

  • Nachverfolgen nützlicher Statistiken für die Fehlertypen.
  • Suchen nach dem ersten Commit, bei dem die Fehler ermittelt wurden.
  • Überwachungslinks zu Codeabschnitten, die den Fehler verursacht haben.

Nachdem die Pipelineausführung abgeschlossen wurde, ist eine fehlerfreie Qualität des Anwendungscodes und der Vorlage für die Bereitstellung sichergestellt. Sie können den PR jetzt bestätigen und abschließen. Die CI-Pipeline wird erneut ausgeführt, und die Vorlagen und Manifeste werden erneut generiert, bevor die CD-Pipeline ausgelöst wird.

Tipp

Vergessen Sie in einer realen Umgebung nicht, Branchrichtlinien festzulegen, um sicherzustellen, dass der PR Ihre Qualitätsprüfungen besteht. Weitere Informationen finden Sie im Artikel zum Festlegen von Branchrichtlinien.

CD-Prozessgenehmigungen

Bei erfolgreicher Ausführung der CI-Pipeline wird das Abschließen des Bereitstellungsvorgangs durch die CD-Pipeline ausgelöst. Ähnlich wie zuvor können Sie Genehmigungen für die CD-Pipeline konfigurieren, die Sie für jede Umgebung inkrementell bereitstellen. Dieses Mal müssen Sie jede Bereitstellungsumgebung genehmigen.

  1. Genehmigen Sie die Bereitstellung für die dev-Umgebung.
  2. Nachdem die Vorlagen- und Manifeständerungen für das GitOps-Repository generiert wurden, erstellt die CD-Pipeline einen Commit, führt einen Push aus und erstellt einen PR zur Genehmigung.
  3. Öffnen Sie den PR-Link im Task.
  4. Überprüfen Sie die Änderungen am GitOps-Repository. Folgendes sollte angezeigt werden:
    • High-Level-Änderungen der Helm-Vorlage.
    • Low-Level-Kubernetes-Manifeste, die die zugrunde liegenden Änderungen am gewünschten Zustand zeigen.
  5. Wenn alles gut aussieht, bestätigen Sie den PR, und führen Sie ihn aus.
  6. Warten Sie, bis die Bereitstellung abgeschlossen ist.
  7. Navigieren Sie zur Anwendungsseite, und überprüfen Sie, ob in der Abstimmungs-App jetzt „Tabs“ und „Spaces“ angezeigt werden.
    • Leiten Sie den Port lokal mithilfe von kubectl weiter, und stellen Sie sicher, dass die App korrekt funktioniert. Verwenden Sie dazu folgenden Befehl: kubectl port-forward -n dev svc/azure-vote-front 8080:80
    • Rufen Sie die Azure Vote-App in Ihrem Browser unter http://localhost:8080/ auf, und überprüfen Sie, ob die Auswahl für die Abstimmung in „Tabs“ und „Spaces“ geändert wurde.
  8. Wiederholen Sie die Schritte 1-7 für die stage-Umgebung.

Die Bereitstellung ist jetzt abgeschlossen. Der CI/CD-Workflow ist damit beendet.

Bereinigen von Ressourcen

Falls Sie diese Anwendung nicht weiterverwenden möchten, löschen Sie die Ressourcen wie folgt:

  1. Löschen Sie die Verbindung für die Azure Arc-GitOps-Konfiguration:

    az k8s-configuration delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

  2. Entfernen Sie den Namespace dev:

    • kubectl delete namespace dev

  3. Entfernen Sie den Namespace stage:

    • kubectl delete namespace stage

Nächste Schritte

In diesem Tutorial haben Sie einen vollständigen CI/CD-Workflow eingerichtet, bei dem von der Anwendungsentwicklung bis hin zur Bereitstellung DevOps implementiert wird. Bei Änderungen an der App werden automatisch Validierungs- und Bereitstellungsschritte ausgelöst, die manuell genehmigt werden müssen.

Fahren Sie mit unserem konzeptionellen Artikel fort, um mehr über GitOps und Konfigurationen mit Kubernetes mit Azure Arc-Unterstützung zu erfahren.

CI/CD-Workflow mit GitOps: Kubernetes mit Azure Arc-Unterstützung