Implantar e testar ações do GitHub altamente disponíveis no Serviço Kubernetes do Azure (AKS)

Neste artigo, você aprenderá a implantar e testar ações do GitHub altamente disponíveis com arquivos do Azure no Serviço Kubernetes do Azure (AKS).

Fluxos de trabalho de exemplo do GitHub Actions

O repositório tem três cargas de trabalho de exemplo na pasta de workflow padrão do GitHub para testar os executores ARC auto-hospedados:

  • dotnet-using-container.yml: .NET Build usando contentores, instalando o SDK do .NET, restaurando/criando/publicando a aplicação no próprio executor.
  • dotnet-without-container.yml: .NET Build sem contêineres usam o recurso de contêiner de fluxo de trabalho para executar um contêiner do SDK do .NET e compilar dentro do aplicativo dentro do contêiner. O cache do NuGet é montado por padrão nesse contêiner.
  • container-service-test.yml: Fluxos de trabalho de teste de contentor e serviço também usando o recurso de contentores para criar um contentor Ubuntu e um serviço Redis. Ambos os contêineres são executados no mesmo AKS Pod. O cache do NuGet também é montado por padrão nesse contêiner.

Todos os três fluxos de trabalho têm um parâmetro de entrada para o nome do runner ARC a ser utilizado no campo runs-on: do seu fluxo de trabalho. Esta é a ARC_RUNNER_SCALESET_NAME="arc-runner-set" variável que definimos anteriormente. Para facilitar os testes, usamos a workflow_dispatch: opção nos três fluxos de trabalho para executar esses fluxos de trabalho apenas quando é solicitado manualmente. Na guia Ações do GitHub do repositório, selecione um dos fluxos de trabalho e execute a carga de trabalho.

Quando o fluxo de trabalho estiver em execução, solicitará um runner para o ARC em execução no cluster AKS. Assim que este runner, um pod no Kubernetes, é alocado para o trabalho, o fluxo de trabalho é executado até a sua conclusão. Usamos a abordagem de corredor efêmero, de modo que o pod que executa o fluxo de trabalho é destruído no final e um novo é criado para a próxima execução do fluxo de trabalho.

Excluir os recursos

Quando estiver pronto, você poderá excluir todos os recursos criados neste guia usando os seguintes comandos:

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

Próximos passos

Para saber mais sobre como implantar software de código aberto no Serviço Kubernetes do Azure (AKS), consulte o seguinte artigo:

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram-no originalmente:

  • Jorge Arterio | Advogado Sénior de Cloud
  • Jeff Patterson: Gerente de Produto Principal
  • Rena Shah | Gerente de Produto Senior
  • Shekhar Singh Sorot | Gerente de Produto 2
  • Erin Schaffer | Desenvolvedora de Conteúdo 2
  • Last updated on