Tutorial: Implementieren von CI/CD mit GitOps (Flux v2)

In diesem Tutorial richten Sie eine CI/CD-Lösung mithilfe von GitOps (Flux v2) und Kubernetes- oder AKS-Clustern (Azure Kubernetes Service) mit Azure Arc-Unterstützung ein. Unter Verwendung der Azure Vote-Beispiel-App können Sie folgende Schritte ausführen:

• Verbinden Ihrer Anwendung und GitOps-Repositorys mit Azure DevOps (Azure Repos) oder GitHub
• Implementieren des CI/CD-Flows mit Azure Pipelines oder GitHub
• Verbinden von Azure Container Registry mit Azure DevOps und Kubernetes
• Erstellen von Gruppen aus Umgebungsvariablen oder Geheimnissen
• 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.

Voraussetzungen

• Schließen Sie das vorherige Tutorial ab, um sich mit den Schritten zum Bereitstellen von GitOps für Ihre CI/CD-Umgebung vertraut zu machen.

• Machen Sie sich mit dem Nutzen und der Architektur dieser Funktion vertraut.

• Überprüfen Sie, ob Folgendes vorhanden ist:

  • Ein verbundener Kubernetes-Cluster mit Azure Arc-Unterstützung, dessen Name arc-cicd-cluster lautet
  • Eine verbundene ACR-Instanz (Azure Container Registry) mit AKS-Integration oder einer anderen Clusterauthentifizierung als AKS

• Installieren Sie die neuesten Versionen der folgenden CLI-Erweiterungen für Kubernetes und Kubernetes-Konfigurationen mit Azure Arc-Unterstützung:

  az extension add --name connectedk8s
  az extension add --name k8s-configuration
  

• Oder führen Sie die folgenden Befehle aus, um diese Erweiterungen auf die aktuelle Version zu aktualisieren:

  az extension update --name connectedk8s
  az extension update --name k8s-configuration
  

Verbinden von Azure Container Registry mit Kubernetes

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

Verbinden von Azure Container Registry mit vorhandenen AKS-Clustern

Integrieren Sie eine vorhandene Azure Container Registry-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 Azure Container Registry zu verbinden, erstellen Sie ein Geheimnis zum Pullen von Images. 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.

Abhängig von Ihrem bevorzugten CI/CD-Orchestrator können Sie mit den Anweisungen für Azure DevOps oder für GitHub fortfahren.

Implementieren von CI/CD mit Azure DevOps

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

Schließen Sie unbedingt zuerst die folgenden Schritte ab:

• Melden Sie sich bei Azure DevOps Services an.
• Vergewissern Sie sich, dass Sie über die Berechtigungen „Buildadministrator“ und „Projektadministrator“ für Azure Repos und Azure Pipelines verfügen.

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:

• das Anwendungsrepository arc-cicd-demo-src

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Enthält die Azure Vote-Beispiel-App, die Sie mithilfe von GitOps bereitstellen
  • Importieren des Repositorys mit Namen arc-cicd-demo-src

• das GitOps-Repository arc-cicd-demo-gitops

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Dieses Repository dient als Grundlage für Ihre Clusterressourcen, die für die Azure Vote-App verwendet werden.
  • Importieren des Repositorys mit Namen arc-cicd-demo-gitops

Weitere Informationen finden Sie unter 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.

Die von Ihnen erstellte GitOps-Verbindung synchronisiert die Manifeste automatisch im Manifestverzeichnis und aktualisiert den 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 flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace flux-system \
      --resource-group myResourceGroup \
      -u 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 \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

   Tipp

   Verwenden Sie -cluster-type managedClusters für einen AKS-Cluster (anstelle eines Arc-fähigen Clusters).

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

   • Bei erfolgreicher Bereitstellung werden in Ihrem Cluster die Namespaces dev und stage erstellt.
   • Sie können auch überprüfen, ob auf der Azure-Portalseite Ihres Clusters die Konfiguration cluster-config auf der Registerkarte GitOps erstellt wird.

Importieren der CI/CD-Pipelines

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

Das Anwendungsrepository enthält einen Ordner .pipeline mit den Pipelines, die für PRs, CI und CD verwendet werden. 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 Azure Container Registry 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 Speichern aus, um die Verbindung zu erstellen.

Konfigurieren der PR-Dienstverbindung

Die CD-Pipeline bearbeitet Pull Requests (PRs) im GitOps-Repository, wofür eine Dienstverbindung erforderlich ist. So konfigurieren Sie diese Verbindung

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 als Typ Generic aus.
3. Geben Sie die Parameter für die Dienstverbindung ein. Verwenden Sie für dieses Tutorial Folgendes:
   • Server-URL https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
   • Lassen Sie Benutzernamen und Kennwort leer.
   • Benennen Sie die Dienstverbindung mit azdo-pr-connection.
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 Speichern aus, um die Verbindung zu erstellen.

Installieren des GitOps-Connectors

1. Fügen Sie das Repository des GitOps-Connectors den Helm-Repositorys hinzu:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Installieren Sie den Connector im Cluster:

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=AZDO \
         --set ciCdOrchestratorType=AZDO \
         --set gitOpsOperatorType=FLUX \
         --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
         --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
         --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
         --set orchestratorPAT=<Azure Repos PAT token>
   

   Hinweis

   Azure Repos PAT token muss die Berechtigungen Build: Read & execute und Code: Full aufweisen.

3. Konfigurieren Sie Flux so, dass Benachrichtigungen an den GitOps-Connector gesendet werden:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config 
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Ausführliche Informationen zur Installation finden Sie im Repository GitOps Connector.

Erstellen von Gruppen aus Umgebungsvariablen

Variablengruppe des App-Repositorys

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

Variable	Wert
AZURE_SUBSCRIPTION	(Ihre Azure-Dienstverbindung, in diesem Fall die weiter oben in diesem Tutorial genannte Verbindung arc-demo-acr)
AZ_ACR_NAME	ACR-Name, z. B. arc-demo-acr
ENVIRONMENT_NAME	Dev
MANIFESTS_BRANCH	master
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
VOTE_APP_TITLE	Voting-Anwendung
AKS_RESOURCE_GROUP	AKS-Ressourcengruppe. Erforderlich für automatisierte Tests.
AKS_NAME	AKS-Name. Erforderlich für automatisierte Tests.

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.

Erstellen von Umgebungen

Erstellen Sie in Ihrem Azure DevOps-Projekt Dev- und Stage-Umgebungen. Weitere Details finden Sie unter Erstellen von Umgebungen und Verwenden dieser als Ziel.

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. So aktivieren Sie diese Berechtigungen

1. Öffnen Sie in Azure DevOps Projekteinstellungen.
2. Wählen Sie unter Repositorys die Option Repositorys aus.
3. Wählen Sie Sicherheit aus.
4. Suchen Sie <Project Name> Build Service (<Organization Name>) und Project Collection Build Service (<Organization Name>) (verwenden Sie die Suche, wenn sie nicht angezeigt werden), und erlauben Sie Mitwirken, An Pull Requests mitwirken und Branch erstellen.
5. Wählen Sie unter Pipelines die Option Settings (Einstellungen) aus.
6. Deaktivieren Sie die Option Zugriff auf Repositorys in YAML-Pipelines schützen.

Weitere Informationen finden Sie unter Zuweisen von Versionssteuerungsberechtigungen zum Builddienst und Verwalten von Berechtigungen für Builddienstkonten.

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. Gehen Sie in diesem Fall wie folgt vor:

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 müssen Sie der Pipeline Zugriff auf das GitOps-Repository 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. Suchen Sie den PR, der von der Pipeline für das GitOps-Repository erstellt wurde.

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. Überwachen Sie den git commit-Status auf der Registerkarte Commitverlauf. Wenn er succeeded lautet, startet die CD-Pipeline automatisierte Tests.

6. 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
   

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

8. 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 Änderungen am Code oder an Vorlagen vornehmen, aber unbeabsichtigt auch Vorgänge ausführen, aufgrund derer ein ungültiger Zustand des Clusters ausgelöst wird.

Wenn in der Entwicklungsumgebung nach der Bereitstellung eine Unterbrechung auftritt, hilft das Aktivieren von Umgebungsgenehmigungen, das Problem in späteren Umgebungen zu verhindern.

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 Informationen finden Sie unter Definieren von Genehmigungen und Überprüfungen.

Bei der nächsten Ausführung der CD-Pipeline wird die Pipeline angehalten, nachdem der GitOps-PR erstellt wurde. Stellen Sie sicher, dass die Änderung ordnungsgemäß synchronisiert wurde und die grundlegenden Funktionen bereitstellt. 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. Diese Abfolge von Schritten 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.

Fehler, die beim Linting gefunden wurden, reichen von falsch formatierten YAML-Dateien bis hin zu 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 ersetzen Sie die Werte, durch solche, 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. Continuous Integration 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 unter Branchrichtlinien und -einstellungen.

CD-Prozessgenehmigungen

Bei erfolgreicher Ausführung der CI-Pipeline wird das Abschließen des Bereitstellungsvorgangs durch die CD-Pipeline ausgelöst. 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. Ü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.
4. Wenn alles gut aussieht, bestätigen Sie den PR, und führen Sie ihn aus.
5. Warten Sie, bis die Bereitstellung abgeschlossen ist.
6. 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.
7. Wiederholen Sie die Schritte 1-7 für die stage-Umgebung.

Die Bereitstellung ist jetzt abgeschlossen.

Eine ausführliche Übersicht über alle Schritte und Techniken, die in den CI/CD-Workflows dieses Tutorials implementiert wurden, finden Sie im GitOps-Flussdiagramm für Azure DevOps.

Implementieren von CI/CD mit GitHub

In diesem Tutorial wird davon ausgegangen, dass Sie mit GitHub und GitHub Actions vertraut sind.

Forken der Anwendungs- und GitOps-Repositorys

Forken Sie ein Anwendungsrepository und ein GitOps-Repository. Verwenden Sie für dieses Tutorial die folgenden Beispielrepositorys:

• das Anwendungsrepository arc-cicd-demo-src

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Enthält die Azure Vote-Beispiel-App, die Sie mithilfe von GitOps bereitstellen

• das GitOps-Repository arc-cicd-demo-gitops

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Dieses Repository dient als Grundlage für Ihre Clusterressourcen, die für die Azure Vote-App verwendet werden.

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 geforkten Repository arc-cicd-demo-gitops in GitHub.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace cluster-config \
      --resource-group myResourceGroup \
      -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

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

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

Installieren des GitOps-Connectors

1. Fügen Sie das Repository des GitOps-Connectors den Helm-Repositorys hinzu:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Installieren Sie den Connector im Cluster:

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=GITHUB \
         --set ciCdOrchestratorType=GITHUB \
         --set gitOpsOperatorType=FLUX \
         --set gitHubGitOpsRepoName=arc-cicd-demo-src \
         --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
         --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
         --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
         --set orchestratorPAT=<GitHub PAT token>
   

3. Konfigurieren Sie Flux so, dass Benachrichtigungen an den GitOps-Connector gesendet werden:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Einzelheiten zur Installation finden Sie im Repository für den GitOps-Connector.

Erstellen von GitHub-Geheimnissen

Der nächste Schritt besteht darin, Geheimnisse für das GitHub-Repository und die Umgebung zu erstellen.

Erstellen von Geheimnissen für GitHub-Repositorys

Verwenden Sie die folgenden Werte für die Geheimnisse Ihres GitHub-Repositorys:

`Secret`	Wert
AZURE_CREDENTIALS	Anmeldeinformationen für Azure im folgenden Format: {"Client-ID":"GUID","geheimer_Clientschlüssel":"GUID","Abonnement-ID":"GUID","Mandanten-ID":"GUID"}
AZ_ACR_NAME	ACR-Name, z. B. arc-demo-acr
MANIFESTS_BRANCH	master
MANIFESTS_FOLDER	arc-cicd-cluster
MANIFESTS_REPO	https://github.com/your-organization/arc-cicd-demo-gitops
VOTE_APP_TITLE	Voting-Anwendung
AKS_RESOURCE_GROUP	AKS-Ressourcengruppe. Erforderlich für automatisierte Tests.
AKS_NAME	AKS-Name. Erforderlich für automatisierte Tests.
PAT	PAT-Token in GitHub mit der Berechtigung für Pull Requests in diesem GitOps-Repository

Erstellen von Geheimnissen für die GitHub-Umgebung

1. Erstellen Sie mithilfe der folgenden Geheimnisse eine az-vote-app-dev-Umgebung:

`Secret`	Wert
ENVIRONMENT_NAME	Dev
TARGET_NAMESPACE	dev

1. Erstellen Sie mithilfe der folgenden Geheimnisse eine az-vote-app-stage-Umgebung:

`Secret`	Wert
ENVIRONMENT_NAME	Phase
TARGET_NAMESPACE	stage

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

CI/CD-Entwicklungsworkflow

Ändern Sie den Quellcode, um den CI/CD-Entwicklungsworkflow zu starten. Aktualisieren Sie im Anwendungsrepository die Werte in der Datei .azure-vote/src/azure-vote-front/config_file.cfg, und pushen Sie die Änderungen an das Repository.

Der CI/CD-Entwicklungsworkflow:

• 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.
• Überprüft, ob das Docker-Image geändert wurde und das neue Image per Push übertragen wird.
• Veröffentlicht die Artefakte (Docker-Imagetags, Manifestvorlagen, Tools), die bei nachfolgenden CD-Phasen verwendet werden
• Stellt die Anwendung in der Entwicklungsumgebung bereit
  • Generieren von Manifesten für das GitOps-Repository
  • Erstellen eines PR für das GitOps-Repository zur Genehmigung

Nachdem diese Schritte abgeschlossen wurden:

1. Suchen Sie den PR, der von der Pipeline für das GitOps-Repository erstellt wurde.

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. Überwachen Sie den git commit-Status auf der Registerkarte „Commitverlauf“. Wenn er succeeded lautet, wird der CD Stage-Workflow gestartet.

6. 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
   

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

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

CD-Phasenworkflow

Der CD-Phasenworkflow wird automatisch gestartet, sobald Flux die Anwendung erfolgreich in der Entwicklungsumgebung bereitgestellt und GitHub Actions über den GitOps-Connector benachrichtigt.

Folgende Aktionen werden im CD-Phasenworkflow ausgeführt:

• Ausführen von Buildüberprüfungstest für die Anwendung in der Entwicklungsumgebung
• Bereitstellen der Anwendung in der Stagingumgebung
  • Generieren von Manifesten für das GitOps-Repository
  • Erstellen eines PR für das GitOps-Repository zur Genehmigung

Sobald der Manifest-PR für die Stagingumgebung zusammengeführt wurde und Flux alle Änderungen erfolgreich angewendet hat, wird der Git-Commitstatus im GitOps-Repository aktualisiert. Die Bereitstellung ist jetzt abgeschlossen.

Eine ausführliche Übersicht über alle Schritte und Techniken, die in den CI/CD-Workflows dieses Tutorials implementiert wurden, finden Sie im GitOps-Flussdiagramm für GitHub.

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 flux delete \
         --name cluster-config \
         --cluster-name arc-cicd-cluster \
         --resource-group myResourceGroup \
         -t connectedClusters --yes
   

2. Löschen Sie den GitOps-Connector:

   helm uninstall gitops-connector -n flux-system
   kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
   kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system
   

Nächste Schritte

In diesem Tutorial haben Sie einen vollständigen CI/CD-Workflow eingerichtet, bei dem DevOps von der Anwendungsentwicklung bis hin zur Bereitstellung 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.

Konzept: CD-Prozess mit GitOps-Beispielimplementierung: Erkunden des CI/CD-Flows mit GitOpsBeispielimplementierung: Erkunden des CI/CD-Flows mit GitOps.