Share via

CI/CD-Workflow mit GitOps (Flux v2)

  • Artikel

Moderne Kubernetes-Bereitstellungen umfassen mehrere Anwendungen, Cluster und Umgebungen. Mit GitOps können Sie diese komplexen Setups leichter verwalten und den gewünschten Zustand der Kubernetes-Umgebungen deklarativ mit Git nachverfolgen. Mithilfe gängiger Git-Tools zum Deklarieren des Clusterzustands können Sie die Verantwortlichkeit erhöhen, die Untersuchung von Fehlern vereinfachen sowie Automatisierungen für die Umgebungsverwaltung ermöglichen.

In diesem Artikel wird beschrieben, wie GitOps in den vollständigen Lebenszyklus von Anwendungsänderungen mit Azure Arc, Azure Repos und Azure Pipelines passt. Zudem finden Sie hier ein Beispiel für eine einzelne Anwendungsänderung in GitOps-gesteuerte Kubernetes-Umgebungen.

Aufbau

Dieses Diagramm zeigt den CI/CD-Workflow für eine Anwendung, die in einer oder mehreren Kubernetes-Umgebungen bereitgestellt wird.

Diagramm mit GitOps CI/CD-Architektur.

Repository für Anwendungscode

Das Anwendungsrepository enthält den Anwendungscode, an dem Entwickler während der inneren Schleife arbeiten. Die Bereitstellungsvorlagen der Anwendung sind in generischer Form (wie z. B. Helm oder Kustomize) in diesem Repository vorhanden. Umgebungsspezifische Werte werden nicht im Repository gespeichert.

Durch Änderungen an diesem Repository wird eine PR- oder CI-Pipeline aufgerufen, die den Bereitstellungsprozess startet.

Containerregistrierung

Die Containerregistrierung enthält alle Erst- und Drittanbieterimages, die in den Kubernetes-Umgebungen verwendet werden. Anwendungsimages von Erstanbietern werden mit lesbaren Tags und dem Git-Commit für die Imageerstellung versehen. Bilder von Drittanbietern können zwischengespeichert werden, um Sicherheit, Geschwindigkeit und Resilienz zu unterstützen. Legen Sie einen Plan für zeitnahe Tests und die Integration von Sicherheitsupdates fest.

Weitere Informationen finden Sie unter Verwenden und Verwalten von öffentlichen Inhalten mit Azure Container Registry Tasks.

PR-Pipeline

Pull-Anforderungen von Entwicklern, die an das Anwendungs-Repository vorgenommen wurden, werden an einer erfolgreichen Ausführung der PR-Pipeline gehindert. Von dieser Pipeline werden die grundlegenden Quality Gates (wie Linten und Komponententests) für den Anwendungscode ausgeführt. Die Pipeline testet die Anwendung und lintet Dockerfiles und Helm-Vorlagen, die für die Bereitstellung in einer Kubernetes-Umgebung verwendet werden. Docker-Images sollten erstellt und getestet, aber nicht gepusht werden. Halten Sie die Pipelinedauer relativ kurz, um schnelle Iterationen zu ermöglichen.

CI-Pipeline

Über die Anwendungs-CI-Pipeline werden alle PR-Pipelineschritte ausgeführt und dadurch das Testen und die Bereitstellungsüberprüfungen erweitert. Die Pipeline kann für jeden einzelnen Commit zum Mainbranch oder in regelmäßigen Abständen mit einer Gruppe von Commits ausgeführt werden.

In dieser Phase können Anwendungstests durchgeführt werden, die für die PR-Pipeline zu ressourcenintensiv sind, einschließlich:

  • Pushen von Images in die Containerregistrierung
  • Erstellen, Linten und Testen von Images
  • Vorlagengenerierung von YAML-Rohdateien

Am Ende des CI-Builds werden Artefakte generiert. Diese Artefakte können vom CD-Schritt verwendet werden, um die Bereitstellung vorzubereiten.

Flux-Clustererweiterung

Flux ist ein Agent, der in jedem Cluster als Clustererweiterung läuft. Diese Flux-Clustererweiterung ist für die Aufrechterhaltung des gewünschten Zustands verantwortlich. Der Agent fragt das GitOps-Repository in einem benutzerdefinierten Intervall ab und gleicht den Clusterzustand dann mit dem im Git-Repository deklarierten Zustand ab.

Weitere Informationen finden Sie unter Tutorial: Bereitstellen von Anwendungen mithilfe von GitOps mit Flux v2.

CD-Pipeline

Die CD-Pipeline wird automatisch durch erfolgreiche CI-Buildvorgänge ausgelöst. In dieser Pipelineumgebung werden die zuvor veröffentlichten Vorlagen durch umgebungsspezifische Werte ersetzt, und mit diesen Werten wird ein neuer Pull Request an das GitOps-Repository ausgelöst. Dieser Pull Request enthält die vorgeschlagenen Änderungen am gewünschten Zustand mindestens eines Kubernetes-Clusters. Clusteradministratoren überprüfen den Pull Request und genehmigen die Zusammenführung im GitOps-Repository. Die Pipeline wartet auf die Zusammenführung durch den Pull Request. Anschließend werden die Zustandsänderungen von Flux synchronisiert und angewendet.

Anwendungskonfiguration

Das GitOps-Repository stellt clusterübergreifend den aktuellen gewünschten Zustand aller Umgebungen dar. Änderungen an diesem Repository werden vom Flux-Dienst in jedem Cluster aufgegriffen und bereitgestellt. Änderungen am gewünschten Zustand der Cluster werden als Pull Requests dargestellt, die dann überprüft und schließlich nach der Genehmigung der Änderungen zusammengeführt werden. Diese Pull Requests enthalten Änderungen an Bereitstellungsvorlagen sowie Änderungen an den resultierenden gerenderten Kubernetes-Manifesten. Gerenderte Manifeste auf niedriger Ebene ermöglichen eine sorgfältigere Überprüfung von Änderungen, die in der Regel auf Vorlagenebene nicht sichtbar sind.

GitOps-Connector

Vom GitOps-Connector wird eine Verbindung zwischen dem Flux-Agenten und dem GitOps-Repository bzw. der CD-Pipeline hergestellt. Beim Anwenden von Änderungen auf dem Cluster wird der GitOps-Connector von Flux über jede durchgeführte Phasenänderung und Integritätsprüfung benachrichtigt. Diese Komponente dient als Adapter. Es versteht wie mit einem Git-Repository kommuniziert wird, und aktualisiert den Git-Commitstatus, sodass der Synchronisierungsfortschritt im GitOps-Repository sichtbar ist. Nach Abschluss der Bereitstellung (ganz gleich, ob erfolgreich oder nicht) wird die CD-Pipeline vom Connector benachrichtigt, damit diese nach der Bereitstellung erforderliche Aktivitäten wie etwa Integrationstests durchführen kann.

Kubernetes-Cluster

Die verschiedenen von der Anwendung benötigten Umgebungen werden von mindestens einem Kubernetes-Cluster mit Azure Arc-Unterstützung oder einem Azure Kubernetes Service (AKS) bereitgestellt. Über unterschiedliche Namespaces kann von einem einzelnen Cluster beispielsweise sowohl die Entwicklungs- als auch die Qualitätssicherungsumgebung bereitgestellt werden. Die Verwendung eines zweiten Clusters ermöglicht eine einfachere Trennung der Umgebungen sowie eine präzisere Steuerung.

Beispielworkflow

Als Anwendungsentwickler führt Alice folgende Schritte aus:

  • Sie schreibt Anwendungscode.
  • Sie bestimmt, wie die Anwendung in einem Docker-Container ausgeführt werden soll.
  • Sie definiert die Vorlagen für die Ausführung des Containers und der abhängigen Dienste in einem Kubernetes-Cluster.

Alice möchte sicherstellen, dass die Anwendung in mehreren Umgebungen ausführbar ist, kennt aber nicht die spezifischen Einstellungen für jede Umgebung.

Angenommen, Alice möchte eine Anwendungsänderung vornehmen, die eine Änderung des Docker-Images zur Folge hat, das in der Vorlage für die Anwendungsbereitstellung verwendet wird.

  1. Alice ändert die Bereitstellungsvorlage, pusht sie in einen Remotebranch namens alice im Anwendungsrepository und öffnet einen Pull Request zur Überprüfung anhand des main-Branch.

  2. Alice bittet ihr Team, die Änderung zu überprüfen.

    • Von der PR-Pipeline wird eine Validierung durchgeführt.
    • Nach einer erfolgreichen Ausführung der PR-Pipeline und der Genehmigung durch das Team werden die Änderungen zusammengeführt.

  3. Die CI-Pipeline wird gestartet, und die Änderung von Alice wird überprüft und erfolgreich abgeschlossen.

    • Die Änderung kann gefahrlos im Cluster bereitgestellt werden, und die Artefakte werden in der CI-Pipelineausführung gespeichert.

  4. Durch die erfolgreiche Ausführung der CI-Pipeline wird die CD-Pipeline ausgelöst.

    • Die CD-Pipeline greift die Artefakte auf, die in der CI-Pipelineausführung von Alice gespeichert wurden.
    • Die CD-Pipeline ersetzt die Vorlagen durch umgebungsspezifische Werte und staged alle Änderungen für den vorhandenen Clusterzustand im GitOps-Repository.
    • Die CD-Pipeline erstellt einen Pull Request für den Produktionsbranch des GitOps-Repositorys mit den gewünschten Änderungen am Clusterzustand.

  5. Das Team von Alice überprüft und genehmigt ihren Pull Request.

    • Die Änderung wird in dem Zielbranch zusammengeführt, der der Umgebung entspricht.

  6. Innerhalb weniger Minuten erkennt Flux eine Änderung im GitOps-Repository und pullt die Änderung von Alice.

    • Aufgrund der Änderung des Docker-Images muss der Anwendungspod aktualisiert werden.
    • Flux wendet die Änderung auf den Cluster an.
    • Flux meldet den Bereitstellungsstatus über den GitOps-Connector an das GitOps-Repository zurück.

  7. Die CD-Pipeline führt automatisierte Tests aus, um zu überprüfen, ob die neue Bereitstellung erfolgreich abgeschlossen wurde und wie erwartet funktioniert.

    Hinweis

    Ist eine Bereitstellung in weiteren Umgebungen vorgesehen, wird die CD-Pipeline erneut durchlaufen, indem ein Pull Request für die nächste Umgebung erstellt wird und die Schritte 4 bis 7 wiederholt werden. Für riskantere Bereitstellungen oder Umgebungen (beispielsweise für eine sicherheitsbezogene Änderung oder eine Produktionsumgebung) ist ggf. eine zusätzliche Genehmigung erforderlich.

  8. Wenn die Bereitstellung für alle Umgebungen erfolgreich war, wird die Pipeline abgeschlossen.

Nächste Schritte