Bearbeiten

Freigeben über

CI/CD für AKS-Apps mit GitHub Actions und GitFlow

Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Pipelines

GitOps ist ein Betriebsmodell für cloudnative Anwendungen, die den Anwendungs- und deklarativen Infrastrukturcode in Git als zentrale verlässliche Informationsquelle für automatisierte Continuous Delivery speichern. Mit GitOps beschreiben Sie den gewünschten Zustand Ihres gesamten Systems in einem Git-Repository, und ein GitOps-Operator stellt ihn in Ihrer Umgebung bereit, was häufig ein Kubernetes-Cluster ist. Weitere Informationen zu GitOps für Kubernetes auf Azure finden Sie unter GitOps für Azure Kubernetes Service oder CI/CD und GitOps-Disziplinen mit Azure Arc-aktiviertem Kubernetes.

Das Beispielszenario in diesem Artikel trifft auf Unternehmen zu, die die End-to-End-Anwendungsentwicklung mithilfe von Containern, Continuous Integration (CI) für Build und GitOps für Continuous Deployment (CD) modernisieren möchten. In diesem Szenario wird eine Flask-App als Beispiel verwendet. Diese Web-App besteht aus einem Front-End, das mithilfe von Python und dem Flask-Framework geschrieben wurde.

Aufbau

Die folgenden Optionen untersuchen Push-basierte und Pull-basierte CI/CD-Ansätze.

Option 1: Push-basiertes CI/CD

Diagramm der Push-basierten Architektur mit GitHub Actions.

Push-basierte Architektur mit GitHub Actions für CI und CD.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

In diesem Szenario wird eine Push-basierte DevOps-Pipeline für eine zweistufige Webanwendung mit einer Front-End-Webkomponente und einem Back-End behandelt, das Redis verwendet. Diese Pipeline verwendet GitHub Actions, um Build und Bereitstellung zu ermöglichen. Die Daten durchlaufen das Szenario wie folgt:

  1. Der App-Code wird entwickelt.
  2. Der App-Code wird in ein GitHub-Git-Repository übertragen.
  3. GitHub Actions erstellt ein Containerimage aus dem App-Code und pusht das Containerimage an die Azure Container Registry-Instanz.
  4. Ein GitHub Actions Auftrag stellt die App, wie in den Manifestdateien beschrieben, mithilfe von kubectl oder der Clusteraktion In Kubernetes bereitstellen im Azure Kubernetes Service-Cluster (AKS) bereit bzw. pusht diese in den Cluster.

Option 2: Pull-basiertes CI/CD (GitOps)

Diagramm der Pull-basierten Architektur mi GitHub Actions und Argo CD.

Pull-basierte Architektur mit GitHub Actions für CI und Argo CD für CD.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

In diesem Szenario wird eine Pull-basierte DevOps-Pipeline für eine zweistufige Webanwendung mit einer Front-End-Webkomponente und einem Back-End behandelt, das Redis verwendet. Diese Pipeline verwendet GitHub Actions, um Build zu ermöglichen. Für die Bereitstellung wird Argo CD als GitOps-Operator verwendet, um die App zu pullen/synchronisieren. Die Daten durchlaufen das Szenario wie folgt:

  1. Der App-Code wird entwickelt.
  2. Der App-Code wird in ein GitHub-Repository übertragen.
  3. GitHub Actions erstellt ein Containerimage aus dem App-Code und pusht das Containerimage an die Azure Container Registry-Instanz.
  4. GitHub Actions aktualisiert eine Kubernetes-Manifestbereitstellungsdatei mit der aktuellen Imageversion basierend auf der Versionsnummer des Containerimages in der Azure Container Registry.
  5. Argo CD synchronisiert sich mit dem Git-Repository oder führt daraus einen Pull aus.
  6. Argo CD stellt die App im AKS-Cluster bereit.

Komponenten

  • GitHub Actions ist eine Automatisierungslösung, die in Azure-Dienste für Continuous Integration (CI) integriert werden kann. In diesem Szenario orchestriert GitHub Actions die Erstellung neuer Containerimages auf der Grundlage von Commits in der Quellcodeverwaltung, pusht die Images an die Azure Container Registry-Instanz und aktualisiert anschließend die Kubernetes-Manifestdateien im GitHub Repository.
  • Azure Kubernetes Service (AKS) ist eine Managed Kubernetes-Plattform, mit der Sie Containeranwendungen ganz ohne Kenntnisse auf dem Gebiet der Containerorchestrierung bereitstellen und verwalten können. Azure führt als gehosteter Kubernetes-Dienst wichtige Aufgaben für Sie aus, z.B. Systemüberwachung und Wartung.
  • Azure Container Registry speichert und verwaltet Containerimages, die vom AKS-Cluster verwendet werden. Images werden sicher gespeichert und können von der Azure-Plattform in anderen Regionen repliziert werden, um die Bereitstellung zu beschleunigen.
  • GitHub ist ein webbasiertes Quellcodeverwaltungssystem, das auf Git ausgeführt wird und von Entwicklern verwendet wird, um ihren Anwendungscode zu speichern und zu versionieren. In diesem Szenario wird GitHub verwendet, um den Quellcode in einem Git-Repository zu speichern, und dann wird GitHub Actions verwendet, um im Push-basierten Ansatz Erstellen und Pushen des Containerimages in Azure Container Registry auszuführen.
  • Argo CD ist ein Open-Source-GitOps-Operator, der in GitHub und AKS integriert ist. Argo CD unterstützt Continuous Deployment (CD). Flux könnte für diesen Zweck verwendet werden, aber Argo CD zeigt, wie ein App-Team ein separates Tool für seine spezifische Anwendungslebenszyklus-Problematik auswählen kann, verglichen mit demselben Tool, das die Cluster-Operatoren für die Clusterverwaltung verwenden.
  • Azure Monitor dient zum Nachverfolgen der Leistung, Gewährleisten der Sicherheit und Identifizieren von Trends. Metriken von Azure Monitor können von anderen Ressourcen und Tools, wie z. B. Grafana, verwendet werden.

Alternativen

  • Azure Pipelines hilft Ihnen bei der Implementierung einer CI/DC- und Testpipeline für jede App.
  • Jenkins ist ein Open-Source-Automatisierungsserver, der sich in Azure-Dienste integrieren lässt, um CI/CD zu ermöglichen.
  • Flux kann als GitOps-Operator verwendet werden. Es kann die gleichen Aufgaben wie Argo CD ausführen und funktioniert auf dieselbe Weise mit AKS.

Szenariodetails

In diesem Szenario verwendet die automatisierte Erstellung und Bereitstellung Ihrer App mehrere Technologien. Der Code wird in VS Code entwickelt und in einem GitHub-Repository gespeichert. GitHub Actions wird verwendet, um die App als Container zu erstellen und dann das Container-Image an eine Azure Container Registry-Instanz zu pushen. GitHub Actions wird verwendet, um die erforderliche Kubernetes-Manifestbereitstellungsdatei zu aktualisieren, die auch im Git-Repository gespeichert wird, während der GitOps-Operator über Argo CD die Kubernetes-Manifestdateien von dort aus abruft und die App im AKS-Cluster bereitstellt.

Zu weiteren Beispielen gehören die Bereitstellung einer automatisierten Entwicklungsumgebung, die Überprüfung neuer Codecommits oder das Pushen neuer Bereitstellungen an Staging- oder Produktionsumgebungen. In der Vergangenheit mussten Unternehmen Anwendungen und Updates in der Regel manuell erstellen und kompilieren sowie eine umfangreiche monolithische Codebasis pflegen. Mit einem modernen Ansatz für die Anwendungsentwicklung, der auf CI und GitOps für CD setzt, können Sie Dienste schnell erstellen, testen und bereitstellen. Durch diesen modernen Ansatz können Sie Anwendungen und Updates schneller für Ihre Kunden bereitstellen und flexibler auf veränderte geschäftliche Anforderungen reagieren.

Mithilfe von Azure- und GitHub-Diensten, wie z. B. AKS, Container Registry, GitHub und GitHub Actions, können Unternehmen die neuesten Techniken und Tools für die Anwendungsentwicklung verwenden, um so die Implementierung von Hochverfügbarkeit zu vereinfachen. Durch die Verwendung von Open-Source-Technologien, wie z. B. Flux oder Argo CD für GitOps, vereinfachen Unternehmen auch die Bereitstellung und erzwingen den gewünschten Anwendungszustand.

Mögliche Anwendungsfälle

Zu den weiteren relevanten Anwendungsfällen zählen:

  • Modernisieren der Methoden zur Anwendungsentwicklung durch Anwenden eines Microservice- und Container-basierten Ansatzes.
  • Beschleunigen von Anwendungsentwicklung und Bereitstellungslebenszyklen.
  • Automatisieren von Bereitstellungen in Test- oder Akzeptanzumgebungen zu Überprüfungszwecken.
  • Sicherstellen der Konfigurationen und des gewünschten Anwendungszustands.
  • Automatisieren der Cluster-Lebenszyklusverwaltung.

CI/CD-Optionen

Dieses Dokument zeigt die Verwendung von GitOps für einen modernen Ansatz zur Handhabung der kontinuierlichen Bereitstellung in einer CI/CD-Pipeline. Jede Organisation unterscheidet sich jedoch. Bei der Bereitstellung von Anwendungen in Kubernetes-Clustern über automatisierte Zustellpipelines ist es wichtig, die verschiedenen Möglichkeiten zu verstehen, wie sie ausgeführt werden können.

Die beiden häufigsten CI/CD-Optionen für die Bereitstellung einer Anwendung in einem AKS-Cluster sind Push-basiert und Pull-basiert. Die Push-Option verwendet GitHub Actions für Continuous Deployment und die Pull-Option verwendet GitOps für Continuous Deployment.

Option 1: Push-basierte Architektur mit GitHub Actions für CI und CD

In diesem Ansatz beginnt der Code mit dem CI-Teil der Pipeline, der dafür sorgt, dass Änderungen als Bereitstellungen an den Kubernetes-Cluster gepusht werden. Die Bereitstellungen basieren auf einem Trigger. Es gibt verschiedene Trigger, die die Bereitstellung starten können, z. B. Commits für das Repository oder einen Trigger aus einer anderen CI-Pipeline. Mit diesem Ansatz hat das Pipeline-System Zugriff auf den Kubernetes-Cluster. Das Push-basierte Modul ist das häufigste Modell, das heute von CI/CD-Tools verwendet wird.

Gründe für die Verwendung eines Push-basierten Ansatzes sind wie folgt:

  • Flexibilität: Die meisten GitOps-Operatoren werden derzeit nur in Kubernetes ausgeführt. Wenn Ihre Organisation Anwendungen in anderen Systemen als Kubernetes bereitstellen möchte, müssen Sie die Anwendung über andere CI/CD-Tools wie GitHub Actions an diese Umgebung pushen.

  • Effizienz: Ein standardisierter Ansatz für die Bereitstellung Ihrer Cloud-nativen und herkömmlichen Anwendungen ist effizienter. Derzeit eignet sich GitOps am besten für cloudnative Anwendungen, die auf Kubernetes ausgeführt werden.

  • Einfachheit: Push-basiertes CI/CD ist bei den meisten Technikern in vielen Organisationen bekannt. Ein Push-basierter Ansatz kann einfacher sein als eine Mischung aus Push-basierten und Pull-basierten CI/CD-Ansätzen.

  • Struktur: Die aktuelle Repository-Struktur, die für Ihre Anwendung verwendet wird, eignet sich möglicherweise nicht für GitOps, was bedeutet, dass erhebliche Planung und Umstrukturierung für eine GitOps-Anpassung erforderlich wäre.

Option 2: Pull-basierte Architektur mit GitHub Actions für CI und GitOps-Operator Argo CD für CD

Bei diesem Ansatz sollen alle Änderungen innerhalb eines Kubernetes-Clusters angewendet werden. Der Kubernetes-Cluster enthält einen Operator, der ein Git-Repository auf den gewünschten Zustand des Clusters überprüft und dabei alle Änderungen übernimmt und anwendet, die vorgenommen werden müssen. In diesem Modell verfügt kein externer Client über Anmeldeinformationen auf Administratorebene für den Kubernetes-Cluster. Das Pull-Modell ist nicht neu, wurde aber von CI/CD-Tools nicht häufig verwendet. Mit der Einführung von GitOps hat sich das Pull-Modell in letzter Zeit immer mehr durchgesetzt. Viele Organisationen haben GitOps verwendet, um Continuous Deployment in ihren CD/CD-Pipelines zu erleichtern.

Gründe für die Verwendung eines Pull-basierten Ansatzes sind wie folgt:

  • Konsistenz: Mit GitOps vergleicht ein Operator den Zustand Ihrer Kubernetes-Cluster mit dem gewünschten Zustand Ihrer Konfiguration und Anwendungen in einem Git-Repository. Wenn es einen Drift zu der Konfiguration oder Anwendungen gibt, bringt der GitOps-Operator den Kubernetes-Cluster automatisch in den gewünschten Zustand zurück.

  • Sicherheit: Ein Pull-basierter Ansatz für CI/CD mit GitOps ermöglicht es Ihnen, Sicherheitsanmeldeinformationen in Ihren Kubernetes-Cluster zu verschieben, wodurch die Sicherheits- und Risikooberfläche reduziert wird, indem Anmeldeinformationen entfernt werden, die in Ihrem externen CI-Tool gespeichert werden. Sie können auch zulässige eingehende Verbindungen reduzieren und den Zugriff auf Administratorebene auf Ihre Kubernetes-Cluster einschränken.

  • Versionsverwaltung: Da GitOps ein Git-Repository als zentrale zuverlässige Informationsquelle verwendet, verfügt Continuous Deployment inhärent über Versionsverwaltungs-, Rollback- und Überwachungsfunktionen.

  • Mehrfachmandanten: Ein Pull-basierter Ansatz mit GitOps eignet sich für verteilte Teams und/oder Mehrfachmandanten. Mit GitOps können Sie separate Git-Repositorys, separate Zugriffsrechte und Bereitstellungen über verschiedene Namespaces nutzen.

  • Cloudnativ: Weitere Anwendungen werden modernisiert oder als cloudnativ entwickelt. Für jede Organisation, die die meisten ihrer Anwendungen in Kubernetes ausführt, ist die Verwendung eines GitOps-Operators für Continuous Deployment einfacher und effizienter als ein herkömmlicher Push-basierter Ansatz für CI/CD.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Bei diesem Szenario wird Azure Monitor verwendet, um die Leistung Ihrer Anwendung zu überwachen und Probleme zu melden. Damit können Sie die Leistung überwachen und entsprechende Probleme behandeln, für die ggf. Codeaktualisierungen erforderlich sind, die dann über die CI/CD-Pipeline bereitgestellt werden können.

Der AKS-Cluster verfügt über einen Lastenausgleich, der Anwendungsdatenverkehr an einen oder mehrere Container oder Pods verteilt, die Ihre Anwendung ausführen. Dieses Konzept der Ausführung von Containeranwendungen in Kubernetes stellt eine hochverfügbare Infrastruktur für Ihre Kunden bereit.

Hinweis

In diesem Artikel wird nicht direkt die CI/CD-Pipeline mit Hochverfügbarkeit behandelt. Weitere Informationen sind zu finden unter Hochverfügbarkeit für GitHub Actions und Argo CD Deklarative GitOps CD für Kubernetes.

Resilienz-Komponenten sind in Kubernetes integriert. Diese Komponenten überwachen Container oder Pods und starten sie neu, wenn ein Problem auftritt. Wenn mehrere Kubernetes-Knoten kombiniert werden, kann Ihre Anwendung die Nichtverfügbarkeit eines Pods oder Knotens tolerieren.

Allgemeine Informationen zur Entwicklung robuster Lösungen finden Sie unter Entwerfen zuverlässiger Azure-Anwendungen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Zur Trennung von Anmeldeinformationen und Berechtigungen verwendet dieses Szenario einen dedizierten Microsoft Entra ID-Dienstprinzipal. Die Anmeldeinformationen für diesen Dienstprinzipal werden als Objekt mit sicheren Anmeldeinformationen in GitHub als GitHub Actions-Geheimnisse gespeichert, damit sie nicht direkt in Skripts oder in der Buildpipeline verfügbar/sichtbar sind.

Einen allgemeinen Leitfaden zum Sichern von Anwendungen auf AKS-Clustern finden Sie unter Sicherheitskonzepte für Anwendungen und Cluster in AKS.

Zur Trennung von Belangen ist gemäß Leitfaden der Compute, der die Geschäftsanwendung ausführt, von den CD-Agenten oder dem GitOps-Operator zu trennen, indem die Geschäftsanwendung und der GitOps-Operator in separaten Namespaces im Kubernetes-Cluster ausgeführt werden. Für eine weitere Trennung von Belangen kann der GitOps-Operator auf einem Kubernetes-Cluster ausgeführt werden, der der GitOps-Instanz zugeordnet ist, welche vom Kubernetes-Cluster für die Produktion getrennt ist, der die Geschäftsanwendung ausführt.

Hinweis

In diesem Artikel wird nicht direkt behandelt, wie eine CI/CD-Pipeline gesichert wird.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

AKS ermöglicht die Skalierung der Anzahl von Clusterknoten, um den Anforderungen Ihrer Anwendungen gerecht zu werden. Mit zunehmender Größe Ihrer Anwendung können Sie die Anzahl von Kubernetes-Knoten für die Ausführung Ihres Dienstes hochskalieren.

Mit GitHub Actions skaliert der Cloudanbieter automatisch die Anzahl der Runner. Wenn selbstgehostete Runner verwendet werden, wäre der Host des Runners dafür verantwortlich, sie nach Bedarf zu skalieren.

Weitere Skalierbarkeitsthemen finden Sie in der Prüfliste zur Leistungseffizienz.

Bereitstellen dieses Szenarios

Führen Sie die Schritte in der AKS-Baseline-Automatisierungs-Referenzimplementierung aus, um das Szenario bereitzustellen. Das Referenzimplementierungs-Repository führt sowohl durch das Push-basierte CI/CD-Szenario als auch durch das Pull-basierte CI/CD (GitOps)-Szenario.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Dieses Szenario verwendet Azure Container Registry und AKS, um eine containerbasierte Anwendung zu speichern und auszuführen. Azure Container Apps oder Azur Container Instances kann ebenfalls zum Ausführen containerbasierter Anwendungen verwendet werden, ohne dafür Orchestrierungskomponenten bereitstellen zu müssen. Weitere Informationen finden Sie unter Azure Container Instances – Übersicht und Azure Container Apps – Übersicht.

Produktdokumentation:

Microsoft Learn-Module: