Bereitstellen von hoch verfügbaren GitHub-Aktionen auf Azure Kubernetes Service (AKS) mithilfe der Azure Files-Übersicht

In diesem Leitfaden stellen Sie einen hoch verfügbaren GitHub Actions-Controller und selbst gehostete Agents bereit, die auf Azure Kubernetes Service (AKS) ausgeführt werden. Die selbst gehosteten Runner verwenden SMB Azure-Dateifreigaben für dauerhaften Speicher.

Von Bedeutung

Open-Source-Software wird überall in AKS-Dokumenten und -Beispielen erwähnt. Software, die Sie bereitstellen, ist von AKS-Vereinbarungen zum Servicelevel, der eingeschränkten Garantie und dem Azure-Support ausgeschlossen. Wenn Sie Open-Source-Technologie zusammen mit AKS nutzen, nutzen Sie die Supportoptionen, die von den jeweiligen Communitys und Projektbetreuenden angeboten werden, um einen Plan zu entwickeln.

Microsoft übernimmt die Verantwortung für die Erstellung der Open-Source-Pakete, die wir in AKS bereitstellen. Diese Verantwortung beinhaltet die vollständige Übernahme des Build-, Scan-, Signier-, Validierungs- und Hotfix-Prozesses sowie die Kontrolle über die Binärdateien in Container-Images. Weitere Informationen finden Sie unter Sicherheitsrisikomanagement für AKS und AKS-Supportabdeckung.

Was ist Actions Runner Controller (ARC)?

Actions Runner Controller (ARC) ist ein Kubernetes-Operator, der selbst gehostete Läufer für GitHub-Aktionen orchestriert und skaliert. ARC verwendet dauerhafte Volumes, um Auftragsinformationen zwischen dem Runnerpod und dem Containerauftragspod zu teilen. Weitere Informationen finden Sie unter "About Actions Runner Controller".

Warum selbst gehostete GitHub-Aktionen auf AKS verwenden?

Die selbst gehosteten GitHub Actions-Runner auf AKS bieten Organisationen eine größere Kontrolle, bessere Skalierbarkeit und verbesserte Sicherheit für ihre CI/CD-Infrastruktur. Anstatt sich auf von GitHub gehostete Runner zu verlassen, die gemeinsam genutzt und flüchtig sind, bieten selbstgehostete Runner:

  • Benutzerdefinierte Umgebungen: Passen Sie Läufer an bestimmte Build-, Test- oder Bereitstellungsanforderungen an.
  • Leistungsgewinne: Nutzen Sie beständigen Speicher und Zwischenspeichern, um Die Erstellungszeiten zu reduzieren und die Zuverlässigkeit zu verbessern.
  • Kosteneffizienz im großen Maßstab: Dynamische Skalierung von Runnern in Ihrer eigenen Infrastruktur, Optimierung für häufige oder lang andauernde Workflows.
  • Verbesserte Sicherheit und Isolation: Verwalten Sie die vollständige Kontrolle über Infrastruktur und Daten, die ideal für regulierte Branchen oder vertrauliche Workloads geeignet ist.

Gängige Anwendungsfälle

  • Enterprise CI/CD-Pipelines: Für Teams, die konsistente, sichere und skalierbare Buildumgebungen benötigen.
  • Große Monorepository- oder ML-Pipelines: Wenn Zwischenspeicherung oder Artefaktpersistenz wichtig ist.
  • Leistungsoptimierung: Verwenden von SMB-Freigaben von Azure Files Premium, um die Metadatenlatenz zu reduzieren und IOPS zu erhöhen.

Voraussetzungen

  • In diesem Leitfaden wird ein grundlegendes Verständnis der grundlegenden Kubernetes-Konzepte vorausgesetzt.
  • Sie benötigen die integrierten Azure-RollenBesitzende Person oder Administrierende Person für Benutzendenzugriff und Mitwirkende für ein Abonnement in Ihrem Azure-Konto.

Bereitstellungsprozess

In diesem Leitfaden werden Sie lernen, wie Sie Folgendes tun:

  • Verwenden Sie Azure CLI, um einen Multizone-AKS-Cluster zu erstellen.
  • Stellen Sie eine Azure-Dateifreigabe bereit, die in dauerhaften AKS-Volumes verwendet werden soll.
  • Installieren Sie den GitHub Actions Runner Controller (ARC) auf AKS.
  • Installieren Sie eine Skalierungsgruppe für ARC-Runner, und binden Sie die Dateifreigabe in AKS ein.
  • Führen Sie einen Beispielworkflow mit GitHub-Aktionen aus.

Bereitstellungsarchitektur

Diese Referenzarchitektur veranschaulicht, wie eine selbst gehostete GitHub Actions-Runner-Lösung mit AKS und Azure File Share (SMB) implementiert wird. Mit der Lösung können Organisationen GitHub-Workflowaufträge sicher in ihrer eigenen Azure-Infrastruktur ausführen und gleichzeitig effiziente Speicherverwaltung und Skalierbarkeit beibehalten.

Screenshot des Architekturdiagramms für GitHub-Aktionen mit Azure Files auf AKS.

Die Architektur besteht aus drei Hauptkomponenten:

  1. GitHub-Integrationsebene: Verbindet Workflows aus GitHub-Repositorys mit Ihrer Azure-Infrastruktur.
  2. AKS-Orchestrierungsebene: Verwaltet die containerisierten Runner-Instanzen und deren Lebenszyklus.
  3. Speicherebene: Bietet dauerhafte und kurzlebige Speicherfunktionen für Läufer.

GitHub-Integrationsebene

Die GitHub-Integrationsebene verbindet Workflows aus GitHub-Repositorys mit Ihrer Azure-Infrastruktur. Workflow-Aufträge werden von GitHub über api.github.com und githubusercontent.com an selbstgehostete Runner verteilt.

AKS-Cluster-Orchestrierungsebene

Die AKS-Cluster-Orchestrierungsebene verwaltet die containerisierten Runner-Instanzen und deren Lebenszyklus. Der Cluster ist in zwei Namespaces unterteilt: arc-controller und arc-runners.

arc-controller verwaltet die Runner-Infrastruktur und Auftragslistener. arc-runners verwaltet Geheimnisse, Zugriffssteuerung und Runner-Pods. Runner sind containerisiert, verwenden kurzlebigen Speicher und stellen eine Verbindung mit freigegebenen und dedizierten Volumes her.

Speicherebene

Die Speicherebene für Azure-Dateifreigaben bietet sowohl NuGet-Dateifreigaben mit ReadWriteMany-Zugriff auf freigegebene Abhängigkeiten als auch kurzlebigen Speicher für Runner, die alle durch dauerhafte Volumeansprüche gesichert werden.

Nächster Schritt

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

  • Jorge Arterio | Senior Cloud Advocate
  • Jeff Patterson | Principal Product Manager
  • Rena Shah | Senior Product Manager
  • Shekhar Singh Sorot | Product Manager 2
  • Erin Schaffer | Inhaltsentwickler 2