Bereitstellen und Testen hoch verfügbarer GitHub-Aktionen auf Azure Kubernetes Service (AKS)

In diesem Artikel erfahren Sie, wie Sie hoch verfügbare GitHub-Aktionen mit Azure Files auf Azure Kubernetes Service (AKS) bereitstellen und testen.

Beispielworkflows für GitHub-Aktionen

Das Repository verfügt über drei Beispielworkloads im Standardmäßigen GitHub-Workflowordner , damit Sie die selbst gehosteten ARC-Läufer testen können:

  • dotnet-using-container.yml: .NET-Build mit Containern installiert das .NET SDK und stellt die Anwendung auf dem Runner selbst wieder her/baut/veröffentlicht sie.
  • dotnet-without-container.yml: .NET Build ohne Container verwendet das Workflowcontainerfeature, um einen .NET SDK-Container und einen Build innerhalb der Anwendung und innerhalb des Containers auszuführen. NuGet-Zwischenspeicherung wird in diesem Container standardmäßig bereitgestellt.
  • container-service-test.yml: Container- und Service-Test-Workflows nutzen auch Container-Features, um einen Ubuntu-Container und einen Redis-Dienst zu erstellen. Beide Container werden auf demselben AKS-Pod ausgeführt. NuGet-Zwischenspeicherung wird auch standardmäßig für diesen Container bereitgestellt.

Alle drei Workflows verfügen über einen Eingabeparameter für den ARC-Läufernamen, der für das runs-on: Feld Ihres Workflows verwendet werden soll. Dies ist die ARC_RUNNER_SCALESET_NAME="arc-runner-set" Variable, die wir zuvor definiert haben. Um Tests zu vereinfachen, verwenden wir die workflow_dispatch: Option für die drei Workflows, um diese Workflows nur dann auszuführen, wenn sie manuell angefordert werden. Wählen Sie auf der Registerkarte "GitHub-Aktionen" Ihres Repositorys einen der Workflows aus, und führen Sie die Workload aus.

Sobald der Workflow ausgeführt wird, fordert er von ARC einen Runner an, der auf dem AKS-Cluster ausgeführt wird. Sobald dieser Runner, ein Pod auf Kubernetes, für den Auftrag zugewiesen ist, wird der Workflow dort bis zum Abschluss ausgeführt. Wir verwenden den ephemeren Runner-Ansatz, sodass der Pod, auf dem der Workflow ausgeführt wird, am Ende zerstört wird und ein neuer für die nächste Workflowausführung erstellt wird.

Löschen der Ressourcen

Wenn Sie fertig sind, können Sie alle in diesem Handbuch erstellten Ressourcen mithilfe der folgenden Befehle löschen:

# Delete ARC runners scale sets 

helm delete "${ARC_RUNNER_SCALESET_NAME}" -n "${NAMESPACE_ARC_RUNNERS}" --wait 

# Delete ARC runners scale set controller 

helm delete "${ARC_CONTROLLER_NAME}" -n "${NAMESPACE_ARC_CONTROLLER}" --wait 

# Delete Azure File share configurations 

kubectl delete -f ./install/arc-runners-set-pv-pvc.yaml --wait 
kubectl delete -f ./install/arc-runners-storage-class-files.yaml --wait 

# Delete secrets 

kubectl delete secret azure-storage-secret -n arc-runners --wait 
kubectl delete secret ${ARC_RUNNER_GITHUB_SECRET_NAME} -n arc-runners --wait 

# Delete container runner configmap pod spec 

kubectl delete -f ./install/arc-runners-set-container-pod-spec.yaml --wait 

# Delete namespaces 

kubectl delete namespace ${NAMESPACE_ARC_RUNNERS} 
kubectl delete namespace ${NAMESPACE_ARC_CONTROLLER}

Nächste Schritte

Weitere Informationen zum Bereitstellen von Open Source-Software auf Azure Kubernetes Service (AKS) finden Sie im folgenden Artikel:

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
  • Last updated on