Distribuire l'applicazione in Azure usando i flussi di lavoro di GitHub Actions creati da Visual Studio

A partire da Visual Studio 2019 versione 16.11, è possibile creare nuovi flussi di lavoro di GitHub Actions per i progetti .NET ospitati in GitHub.com.

Prerequisiti

• È necessario accedere all'account GitHub in Visual Studio.
• Un account Azure. Se non si ha un account Azure, attivare i vantaggi di Azure per i sottoscrittori di Visual Studio o iscriversi per ottenere una versione di valutazione gratuita.

Distribuire un singolo progetto in Azure usando GitHub Actions

In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto ospitato GitHub.com e scegliere Pubblica.

Nella schermata successiva selezionare Azure e quindi scegliere Avanti.

A seconda del tipo di progetto, si ottiene un elenco diverso di servizi di Azure da scegliere. Scegliere uno dei servizi di Azure supportati più adatti alle proprie esigenze.

Nel passaggio finale della procedura guidata selezionare CI/CD usando i flussi di lavoro di GitHub Actions (genera file yml) e quindi scegliere Fine.

Visual Studio genera un nuovo flusso di lavoro di GitHub Actions e chiede di eseguirne il commit e di eseguirne il push in GitHub.com.

Se si completa questo passaggio usando gli strumenti Git predefiniti, Visual Studio rileverà l'esecuzione del flusso di lavoro.

Impostazione dei segreti di GitHub

Affinché il flusso di lavoro generato venga distribuito correttamente in Azure, potrebbe richiedere l'accesso a un profilo di pubblicazione.

Una distribuzione riuscita potrebbe richiedere anche l'accesso a un'entità servizio.

In tutti i casi, Visual Studio tenta di impostare automaticamente il segreto GitHub con il valore corretto. Se ha esito negativo, ti farà sapere e ti darà la possibilità di riprovare.

Se non riesce a impostare nuovamente il segreto, Visual Studio offre la possibilità di ottenere l'accesso al segreto manualmente, in modo da poter completare il processo tramite la pagina del repository in GitHub.com.

Distribuire più progetti nelle app di Azure Container usando GitHub Actions

Questi passaggi sono appropriati se si dispone di più progetti che usano contenitori Docker e si vuole distribuirli come app multiprogetto. È possibile distribuire app multiprogetto, ad esempio quelle che implementano microservizi in App Azure Container o servizio Azure Kubernetes (servizio Azure Kubernetes). Questo articolo illustra le app di Azure Container.

1. Fare clic con il pulsante destro del mouse sul nodo GitHub Actions in Esplora soluzioni e scegliere Nuovo flusso di lavoro. Viene visualizzata la procedura guidata del flusso di lavoro gitHub Actions.

   

2. Nella schermata di destinazione del flusso di lavoro GitHub Actions scegliere Azure.

3. Per la destinazione specifica, scegliere App Contenitore di Azure. La procedura guidata passa alla schermata App contenitore.

   

4. Scegliere un'app Azure Container esistente oppure scegliere Crea nuovo.

   

   Quando si crea un nuovo oggetto, viene visualizzata questa schermata. Quando si esegue il test o l'apprendimento, in genere è consigliabile creare un nuovo gruppo di risorse per semplificare l'eliminazione di tutti gli elementi in un secondo momento. Un ambiente app contenitore è un limite sicuro per i gruppi di app contenitore che condividono la stessa rete virtuale e scrivono i log nella stessa destinazione di registrazione. Vedere Ambienti di App Contenitore di Azure. Se non si sa che cos'è o non ne è stato creato uno in precedenza, crearne uno nuovo per questa istanza.

   

   Dopo la creazione, viene visualizzata la nuova istanza di App Contenitore di Azure.

   

5. Scegliere Avanti per passare alla schermata Registro di sistema . Scegliere un Registro Azure Container esistente o crearne uno nuovo.

   

   Se si sceglie di crearne uno nuovo, viene visualizzata questa schermata. Specificare il gruppo di risorse, lo SKU e scegliere la stessa area, se possibile, come in precedenza. Per informazioni sugli SKU per Registro Azure Container, vedere Registro Azure Container livelli di servizio.

   

   Una volta creato, il nuovo Registro di sistema viene visualizzato sullo schermo.

   

6. Vengono visualizzati i progetti distribuibili nella soluzione; scegliere i progetti da distribuire insieme nella stessa istanza di App Contenitore di Azure.

   

7. Scegliere Fine. È possibile visualizzare i comandi inviati per creare gli asset in Azure e configurare l'autenticazione. In caso di errore, prendere nota della riga di comando usata, perché è possibile riprovare dall'interfaccia della riga di comando. Non preoccuparti troppo se si verifica un errore di autorizzazione in questa fase. È anche possibile configurare l'autenticazione in un secondo momento in Visual Studio.

8. Al termine, viene visualizzata la schermata di riepilogo. La schermata di riepilogo mostra le credenziali, che corrispondono alle voci create da Visual Studio nel repository GitHub nei segreti di GitHub Actions. Verificare la presenza di eventuali segni di avviso gialli. Se uno dei passaggi di autenticazione non è riuscito durante il processo di creazione, è possibile correggerlo facendo clic sul collegamento tramite il segno di avviso e seguendo alcuni passaggi.

9. Aprire il file del flusso di lavoro per verificare l'elemento generato da Visual Studio. Anche se Visual Studio fa del suo meglio per generare un flusso di lavoro per la situazione, ogni app e repository è univoco, quindi spesso è necessario modificare manualmente il file YML del flusso di lavoro generato da Visual Studio prima che venga eseguito correttamente. Per aprirlo, espandere il nodo GitHub Actions in Esplora soluzioni, fare clic con il pulsante destro del mouse sul flusso di lavoro appena creato e scegliere Modifica.

Di seguito viene illustrato un esempio di file del flusso di lavoro creato da Visual Studio per una soluzione con due progetti distribuibili, WebAPI e WebFrontEnd.

on:
push:
  branches:
  - main
env:
CONTAINER_REGISTRY_LOGIN_SERVER: registry20230810121555.azurecr.io
CONTAINER_APP_NAME: containerapp20230810121017
CONTAINER_APP_RESOURCE_GROUP_NAME: webfrontend-container-app-1234
CONTAINER_APP_CONTAINER_NAME: containerapp
jobs:
WebApi_buildImageAndDeploy:
  runs-on: ubuntu-latest
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_6891 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_6891 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
      file: WebApi\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
  - name: Azure logout
    run: az logout
WebFrontEnd_buildImageAndDeploy:
  runs-on: ubuntu-latest
  needs: WebApi_buildImageAndDeploy
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_2047 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_2047 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
      file: WebFrontEnd\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
  - name: Azure logout
    run: az logout

La funzione principale del flusso di lavoro consiste nell'accedere ai servizi di Azure con l'autenticazione corretta ed eseguire i comandi per compilare e distribuire l'app.

Modifica e test del flusso di lavoro

La procedura precedente genera un file YML del flusso di lavoro, ma in genere è necessario esaminarlo e personalizzarlo prima di poterlo usare per una distribuzione. Potrebbe essere necessario fare riferimento alle indicazioni di GitHub sulla scrittura di azioni del flusso di lavoro; vedere Informazioni sulle azioni personalizzate. Il file del flusso di lavoro contiene molti elementi configurabili, ad esempio le impostazioni per le variabili di ambiente e i nomi dei segreti. È possibile visualizzare i riferimenti ai percorsi dei Dockerfile, al nome dell'app contenitore di Azure, al ramo nel repository che verrà usato per attivare le esecuzioni del flusso di lavoro e ai riferimenti ai segreti in GitHub. Viene fatto riferimento ai segreti usando la sintassi ${{ secrets.SECRET_NAME }}. Vedere Segreti di GitHub Actions.

Se i progetti non si trovano nella radice del repository, è necessario modificare il flusso di lavoro per specificare il percorso per trovare i Dockerfile. Aggiungere variabili di ambiente per i percorsi relativi al Dockerfile in entrambi i progetti.

DOCKER_FILEPATH_WEBAPI: docker/ComposeSample/WebApi/Dockerfile
DOCKER_FILEPATH_WEBFRONTEND: docker/ComposeSample/WebFrontend/Dockerfile

Usare i valori di queste variabili di ambiente per il file parametro come indicato di seguito:

- name: Build and push Docker image to Azure container registry
  uses: docker/build-push-action@v4
  with:
    push: true
    tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
    file: ${{ env.DOCKER_FILEPATH_WEBFRONTEND }}

Se è necessario apportare modifiche al Dockerfile, apportare e salvare le modifiche, il commit e il push nel repository remoto. Il flusso di lavoro generato da Visual Studio contiene un trigger che lo fa eseguire se aggiornato in un ramo specificato. Se si esegue il push nel working ramo, dovrebbe essere simile al codice seguente:

on:
  push:
  branches:
  - working

Per testare le modifiche, eseguirne il commit ed eseguirne il push nel ramo del repository specificato nel codice del trigger. Non è necessario creare una richiesta pull. Il flusso di lavoro viene eseguito fino a quando il push trigger è impostato sul ramo destro.

Nella scheda Azioni del repository in GitHub.com cercare l'esecuzione del flusso di lavoro. È possibile accedervi direttamente usando un collegamento nella scheda riepilogo di GitHub Actions in Visual Studio. In GitHub è possibile aprire l'esecuzione del flusso di lavoro per visualizzare i log.

Risoluzione dei problemi

I suggerimenti per la risoluzione dei problemi seguenti potrebbero essere utili se il flusso di lavoro non viene eseguito correttamente.

Problema: la fase di compilazione non viene compilata

Un problema che si potrebbe riscontrare nel Dockerfile è che la fase di compilazione non funzionerà come avviene in Visual Studio. Il Dockerfile predefinito generato da Visual Studio per un progetto illustra questo problema. Si considerino le modifiche seguenti alla fase di compilazione se si dispone di un Dockerfile di questo tipo. Ecco un esempio in cui un progetto si trova docker/ComposeSample/WebApi in un repository. Il percorso completo viene specificato perché il contesto Dockerfile nel contenitore di compilazione del flusso di lavoro è impostato sulla radice del repository, ma in Visual Studio viene impostato sulla cartella sopra la cartella del progetto. Il suffisso _build viene aggiunto qui per creare la cartella di compilazione e invece di copiare semplicemente il file di progetto, l'intera cartella viene copiata. Rispetto al Dockerfile predefinito generato da Visual Studio, la parte del file del percorso nel primo argomento del comando COPY è stata rimossa in modo da copiare l'intera cartella anziché solo il file di progetto. Senza queste modifiche, questa fase genera un errore di MSBuild.

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["docker/ComposeSample/WebApi/", "WebApi_build/"]
RUN dotnet restore "WebApi_build/WebApi.csproj"
COPY . .
WORKDIR "/src/WebApi_build"
RUN dotnet build "WebApi.csproj" -c Release -o /app/build

Problema: credenziali di autenticazione

Il flusso di lavoro richiede la configurazione dei segreti corretti per nome utente e password per l'accesso ad Azure. Visual Studio tenta di eseguire questa operazione automaticamente quando si creano gli asset di Azure o dalla schermata GitHub Actions nell'IDE di Microsoft Visual Studio. È possibile controllare i segreti in GitHub e assicurarsi che siano presenti o rigenerarli e aggiungerli nuovamente a GitHub, se necessario, usando la sezione Impostazioni nel repository. Controllare l'ID dei segreti in base a ciò a cui viene fatto riferimento in ogni sezione del flusso di lavoro. Se necessario, è possibile passare al registro contenitori nel portale di Azure e ottenere il nome utente e la password per il registro contenitori e usare questi valori per aggiornare i segreti in GitHub.

Se è stato eseguito il comando per configurare un'entità az ad sp create-for-rbac servizio e ottenere un ID client, un segreto client e un ID tenant, aggiungere l'ID client e il segreto client come segreti nella sezione Segreti di GitHub Actions per il repository GitHub. È possibile specificare le credenziali di accesso di Azure sotto forma di nome utente (ID client per l'app) e password (segreto client) per l'autenticazione dell'app Azure Container. A tale scopo, sostituire il passaggio Azure login con il codice seguente. Usare i nomi dei segreti GitHub creati per l'ID client e il segreto client e usare l'ID tenant dall'output dello stesso comando.

- name: Azure login
  uses: azure/CLI@v1
  with:
    inlineScript: |
      az login --service-principal -u ${{ secrets.GITHUB_SECRETID_FOR_USERNAME }} -p ${{ secrets.GITHUB_SECRETID_FOR_PASSWORD }} --tenant {your tenant ID}
      az account list

Se il Dockerfile funziona correttamente e l'autenticazione è corretta e si verificano ancora problemi con il flusso di lavoro, prendere in considerazione le risorse seguenti:

• App contenitore di Azure in GitHub
• App contenitore di Azure in StackOverflow

Quali tipi di progetto sono supportati?

• ASP.NET Core
• ASP.NET 5 e versioni successive
• Funzioni di Azure

Quali servizi di Azure sono supportati?

• App Web di Azure
• Funzioni di Azure
• Gestione API di Azure