Distribuire e testare GitHub Actions ad alta disponibilità su Azure Kubernetes Service (AKS)

Questo articolo illustra come distribuire e testare GitHub Actions ad alta disponibilità con Azure Files su Azure Kubernetes Service (AKS).

Flussi di lavoro di esempio di GitHub Actions

Il repository include tre carichi di lavoro di esempio nella cartella del flusso di lavoro GitHub predefinita per testare i runner ARC self-hosted:

  • dotnet-using-container.yml: .NET Build mediante contenitori installa .NET SDK e ripristina/compila/pubblica l'applicazione sul runner stesso.
  • dotnet-without-container.yml: .NET Build senza contenitori usa la funzionalità contenitore del flusso di lavoro per eseguire un contenitore .NET SDK e compilare all'interno dell'applicazione all'interno del contenitore. La memorizzazione nella cache NuGet viene montata per impostazione predefinita in questo contenitore.
  • container-service-test.yml: flussi di lavoro di test del contenitore e del servizio che usano anche la funzionalità contenitori per creare un contenitore Ubuntu e un servizio Redis. Entrambi i contenitori vengono eseguiti nello stesso pod del servizio Azure Kubernetes. La cache NuGet è montata anche per impostazione predefinita in questo contenitore.

Tutti e tre i flussi di lavoro hanno un parametro di input per il nome ARC runner da usare nel campo runs-on: del flusso di lavoro. Si tratta della ARC_RUNNER_SCALESET_NAME="arc-runner-set" variabile definita in precedenza. Per facilitare i test, viene usata l'opzione workflow_dispatch: nei tre flussi di lavoro per eseguire tali flussi di lavoro solo quando viene richiesta manualmente. Nella scheda GitHub Actions del repository selezionare uno dei flussi di lavoro ed eseguire il carico di lavoro.

Quando il flusso di lavoro è in esecuzione, richiede uno strumento di esecuzione per ARC in esecuzione nel cluster del servizio Azure Kubernetes. Dopo che questo strumento di esecuzione, un pod in Kubernetes, viene allocato per il processo, il flusso di lavoro viene eseguito in tale posizione fino al completamento. Viene usato l'approccio temporaneo dello strumento di esecuzione, quindi il pod che esegue il flusso di lavoro viene eliminato definitivamente alla fine e ne viene creato uno nuovo per l'esecuzione successiva del flusso di lavoro.

Eliminare le risorse

Quando si è pronti, è possibile eliminare tutte le risorse create in questa guida usando i comandi seguenti:

# 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}

Passaggi successivi

Per altre informazioni sulla distribuzione di software open source nel servizio Azure Kubernetes, vedere l'articolo seguente:

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti l'hanno originariamente scritto:

  • Jorge Arterio | Esperto Senior di Cloud
  • Jeff Patterson | Product Manager principale
  • Rena Shah | Senior Product Manager
  • Shekhar Singh Sorot | Product Manager 2
  • Erin Schaffer | Sviluppatore di contenuti 2
  • Last updated on