Freigeben über

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

  • Artikel

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 führen Sie folgende Schritte aus:

  • Erstellen eines Kubernetes- oder AKS-Clusters mit Azure Arc-Unterstützung
  • Verbinden Ihrer Anwendung und GitOps-Repositorys mit 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.

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: Beispiel von „Jetzt testen“ für 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. Schaltfläche zum Starten von Azure Cloud Shell.
Wählen Sie im Azure-Portal rechts oben im Menü die Schaltfläche Cloud Shell aus. Screenshot: Schaltfläche „Cloud Shell“ im 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

  • 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:

  • 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

    • 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:

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

  • das GitOps-Repository 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.

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 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 wurden 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 OK aus, um die Verbindung zu erstellen.

Konfigurieren der PR-Dienstverbindung

Die CD-Pipeline bearbeitet PRs im GitOps-Repository. Hierzu ist eine Dienstverbindung erforderlich. 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 OK 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

Einzelheiten zur Installation finden Sie im Repository für den 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 Entwicklung
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 einer Umgebung und Verwenden der Umgebung 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.

  1. Wechseln Sie von der Hauptseite des Azure DevOps-Projekts zu Project settings.
  2. Wählen Sie Repos/Repositories aus.
  3. Wählen Sie Security aus.
  4. Lassen Sie für <Project Name> Build Service (<Organization Name>) und Project Collection Build Service (<Organization Name>) (Eingabe im Suchfeld, falls nicht angezeigt) Contribute, Contribute to pull requests und Create branch zu.
  5. Besuchen Sie Pipelines/Settings.
  6. Deaktivieren Sie die Option Protect access to repositories in YAML pipelines.

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 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 Status des Git-Commits auf der Registerkarte „Commitverlauf“. Wenn er succeeded lautet, startet die CD-Pipeline mit den automatisierten 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 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. 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 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. 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:

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 wurden 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

Erstellen von Geheimnissen für 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.
Persönliche Zugriffstoken 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 Entwicklung
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 von den 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

  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 Status des Git-Commits auf der Registerkarte „Commitverlauf“. Wenn er succeeded lautet, startet der CD Stage-Workflow.

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

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