Condividi tramite

Eseguire la distribuzione nel servizio app di Azure usando GitHub Actions

Usare GitHub Actions per automatizzare il flusso di lavoro e distribuirlo nel servizio app di Azure da GitHub.

Prerequisiti

Configurare la distribuzione di GitHub Actions durante la creazione di un'app

GitHub Actions distribuzione è integrata nel processo di creazione di app Web predefinito. Impostare Distribuzione continua su Abilita nella scheda Distribuzione e configurare l'organizzazione, il repository e il ramo scelti.

Screenshot che mostra come abilitare la distribuzione di GitHub Actions nella scheda Distribuzione del servizio app.

Quando si abilita la distribuzione continua, il processo Crea app Web seleziona automaticamente il metodo di autenticazione in base alla selezione di autenticazione di base e configura l'app e il repository GitHub di conseguenza:

Selezione dell'autenticazione di base Metodo di autenticazione
Disabilitazione Identità assegnata dall'utente (OpenID Connect) (scelta consigliata)
Abilitare Autenticazione di base

Note

Quando si crea un'app, è possibile che venga visualizzato un errore che indica che l'account Azure non dispone di determinate autorizzazioni. L'account potrebbe richiedere le autorizzazioni necessarie per creare e configurare l'identità assegnata dall'utente. Per un'alternativa, vedere la sezione seguente.

Configurare la distribuzione di GitHub Actions dal Centro distribuzione

Per un'app esistente, è possibile iniziare rapidamente a usare GitHub Actions usando il Centro distribuzione nel servizio app. Questo metodo chiavi in mano genera un file del flusso di lavoro di GitHub Actions basato sullo stack di applicazioni ed esegue il commit nel repository GitHub.

Usando il Centro distribuzione, è anche possibile configurare facilmente l'autenticazione OpenID Connect più sicura con un'identità assegnata dall'utente. Per altre informazioni, vedere l'opzione relativa all'identità assegnata dall'utente.

Se l'account Azure ha le autorizzazioni necessarie, è possibile creare un'identità assegnata dall'utente. In caso contrario, è possibile selezionare un'identità gestita assegnata dall'utente esistente nel menu a discesa Identità. È possibile collaborare con l'amministratore di Azure per creare un'identità gestita assegnata dall'utente con il ruolo Collaboratore sito Web.

Per altre informazioni, vedere Distribuzione continua in servizio app di Azure.

Configurare manualmente un flusso di lavoro di GitHub Actions

È possibile distribuire un flusso di lavoro senza usare il Centro distribuzione. Eseguire questi tre passaggi:

  1. Generare le credenziali di distribuzione.
  2. Configurare il secret GitHub.
  3. Aggiungere il file del flusso di lavoro al repository GitHub.

Generare le credenziali per la distribuzione

È consigliabile usare OpenID Connect per eseguire l'autenticazione con il servizio app di Azure per GitHub Actions. Questo metodo di autenticazione usa token di breve durata. La configurazione di OpenID Connect con GitHub Actions è più complessa, ma offre sicurezza avanzata.

È anche possibile eseguire l'autenticazione con un'identità gestita assegnata dall'utente, un principal di servizio o un profilo di pubblicazione.

La procedura seguente descrive i passaggi per creare un'applicazione Microsoft Entra, un'entità servizio e credenziali federate usando le istruzioni dell'interfaccia della riga di comando di Azure. Per informazioni su come creare un'applicazione, un'entità servizio e le credenziali federate di Microsoft Entra nel portale di Azure, vedere Connettere GitHub e Azure.

  1. Se non si dispone di un'applicazione esistente, registrare una nuova applicazione Microsoft Entra e un'entità servizio in grado di accedere alle risorse. Creare l'applicazione Microsoft Entra.

    az ad app create --display-name myApp

    Questo comando restituisce un output JSON con un oggetto appId, che è il tuo client-id. Salvare il valore da usare come AZURE_CLIENT_ID segreto GitHub in un secondo momento.

    Il valore objectId viene utilizzato quando si creano credenziali federate con l'API Graph e viene fatto riferimento come APPLICATION-OBJECT-ID.

  2. Creare un'entità servizio. Sostituire il $appID con il appId dall'output JSON.

    Questo comando genera un output JSON con un'altra objectId da usare nel passaggio successivo. Il nuovo objectId è assignee-object-id.

    Copia appOwnerTenantId per utilizzarlo successivamente come segreto GitHub per AZURE_TENANT_ID.

    az ad sp create --id $appId

  3. Creare una nuova assegnazione di ruolo per sottoscrizione e oggetto. Per impostazione predefinita, l'assegnazione del ruolo viene associata alla sottoscrizione predefinita. Sostituire $subscriptionId con l'ID sottoscrizione, $resourceGroupName con il nome del gruppo di risorse, $webappName con il nome dell'app Web e $assigneeObjectId con l'elemento generato id. Imparare a gestire le sottoscrizioni di Azure con l'interfaccia della riga di comando di Azure.

    az role assignment create --role "Website Contributor" --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webappName --assignee-principal-type ServicePrincipal

  4. Eseguire il comando seguente per creare una nuova credenziale di identità federata per l'app Microsoft Entra.

    • Sostituire APPLICATION-OBJECT-ID con l'oggetto appId generato durante la creazione dell'app per l'applicazione Active Directory.

    • Impostare un valore per CREDENTIAL-NAME per farvi riferimento in un secondo momento.

    • Impostare subject. GitHub ne definisce il valore a seconda del flusso di lavoro:

      • Per i processi nell'ambiente GitHub Actions, utilizzare: repo:< Organization/Repository >:environment:< Name >
      • Per i processi non associati a un ambiente, includere il percorso di riferimento per branch/tag in base al percorso di riferimento usato per attivare il flusso di lavoro: repo:< Organization/Repository >:ref:< ref path>. Ad esempio, repo:n-username/ node_express:ref:refs/heads/my-branch o repo:n-username/ node_express:ref:refs/tags/my-tag.
      • Per i flussi di lavoro attivati da un evento di richiesta pull, usare : repo:< Organization/Repository >:pull_request.
    az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
    "name": "<CREDENTIAL-NAME>",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:organization/repository:ref:refs/heads/main",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}

Configurare il segreto di GitHub

È necessario specificare l'ID client, l'ID tenant e l'ID sottoscrizione dell'applicazione all'azione Azure/login . Questi valori possono essere forniti direttamente nel flusso di lavoro oppure possono essere archiviati nei segreti gitHub e riportati nel flusso di lavoro. Il salvataggio dei valori come segreti GitHub è l'opzione più sicura.

  1. Aprire il repository GitHub e passare a Impostazioni>Sicurezza>Segreti e variabili>Azioni>Nuovo segreto della repository.

  2. Creare segreti per AZURE_CLIENT_ID, AZURE_TENANT_IDe AZURE_SUBSCRIPTION_ID. Usare questi valori dell'applicazione Active Directory per i segreti di GitHub:

    Segreto GitHub Applicazione Active Directory
    AZURE_CLIENT_ID ID applicazione (client)
    AZURE_TENANT_ID ID della directory (tenant)
    AZURE_SUBSCRIPTION_ID ID sottoscrizione

  3. Selezionare Aggiungi segreto per salvare ogni segreto.

Aggiungere il file del flusso di lavoro al repository GitHub

Un file YAML (.yml) nel percorso /.github/workflows/ nel repository GitHub definisce un flusso di lavoro. Questa definizione contiene i vari passaggi e i parametri che costituiscono il flusso di lavoro.

Come minimo, il file del flusso di lavoro prevede i passaggi distinti seguenti:

  1. Autenticarsi con App Service utilizzando il segreto GitHub che hai creato.
  2. Compilare l'app Web.
  3. Distribuire l'app Web.

Per distribuire il codice in un'app di App Service, usa l'azione azure/webapps-deploy@v3. L'azione richiede il nome dell'app Web in app-name e, a seconda dello stack linguistico, il percorso di una *.zip, *.war, *.jar o di una cartella da distribuire in package. Per un elenco completo dei possibili input per l'azione azure/webapps-deploy@v3, vedere action.yml.

Gli esempi seguenti illustrano la parte del flusso di lavoro che compila l'app Web, in diverse lingue supportate.

Per eseguire la distribuzione con OpenID Connect usando l'identità gestita configurata, usare l'azione azure/login@v2 con le chiavi client-id, tenant-id e subscription-id. Fare riferimento ai segreti di GitHub creati in precedenza.

name: .NET Core

on: [push]

permissions:
      id-token: write
      contents: read

env:
  AZURE_WEBAPP_NAME: my-app    # Set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # Set this to the path to your web app project, defaults to the repository root
  DOTNET_VERSION: '6.0.x'           # Set this to the dot net version to use

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Check out the repo
      - uses: actions/checkout@main
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      
      # Setup .NET Core SDK
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }} 
      
      # Run dotnet build and publish
      - name: dotnet build and publish
        run: |
          dotnet restore
          dotnet build --configuration Release
          dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' 
          
      # Deploy to Azure Web apps
      - name: 'Run Azure webapp deploy action using publish profile credentials'
        uses: azure/webapps-deploy@v3
        with: 
          app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name
          package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
      
      - name: logout
        run: |
          az logout

Domande frequenti

Come si distribuisce un file WAR tramite il plug-in Maven?

Se il progetto Java Tomcat è stato configurato con il plug-in Maven, è anche possibile eseguire la distribuzione nel servizio app di Azure tramite questo plug-in. Se si usa l'azione GitHub dell'interfaccia della riga di comando di Azure, vengono usate le credenziali di Azure.

    - name: Azure CLI script file
      uses: azure/cli@v2
      with:
        inlineScript: |
          mvn package azure-webapp:deploy

Per altre informazioni su come usare e configurare il plug-in Maven, vedere Wiki del plug-in Maven per Servizio app di Azure.

Come si distribuisce un file WAR tramite l'interfaccia della riga di comando di Azure?

Se si preferisce usare l'interfaccia della riga di comando di Azure per la distribuzione nel servizio app, è possibile usare GitHub Action per l'interfaccia della riga di comando di Azure.

- name: Azure CLI script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path '${{ github.workspace }}/target/yourpackage.war' --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }}  --async true --type war

Per altre informazioni su come usare e configurare l'azione GitHub per l'interfaccia della riga di comando di Azure, vedere l'azione GitHub dell'interfaccia della riga di comando di Azure.

Per altre informazioni sul az webapp deploy comando, tra cui come usarlo e i dettagli del parametro, vedere laaz webapp deploy documentazione.

Come distribuire un file di avvio?

Usare GitHub Action per l'interfaccia della riga di comando di Azure. Ad esempio:

- name: Deploy startup script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path ${{ github.workspace }}/src/main/azure/createPasswordlessDataSource.sh --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }} --type startup --track-status false

Come distribuire in un contenitore?

Con l'azione Distribuzione Web di Azure , è possibile automatizzare il flusso di lavoro per distribuire contenitori personalizzati nel servizio app usando GitHub Actions. Per altre informazioni, vedere Distribuire in un contenitore.

Come si esegue la distribuzione in uno slot di distribuzione?

È possibile eseguire la distribuzione in uno slot di distribuzione anziché nello slot di produzione usando il slot-name parametro nell'azione azure/webapps-deploy@v3 . Per eseguire la distribuzione in uno slot, aggiungere il slot-name parametro al passaggio di distribuzione nel flusso di lavoro:

- name: Deploy to Azure Web App
  uses: azure/webapps-deploy@v3
  with:
    app-name: 'my-app-name'
    slot-name: 'staging'  # Deploy to the 'staging' slot instead of production
    package: './output'

Note

Quando si usa OpenID Connect o l'autenticazione dell'entità servizio, assicurarsi che l'identità disponga del ruolo Collaboratore sito Web sia per l'app sia per lo slot di distribuzione. Per l'autenticazione del profilo di pubblicazione, scaricare il profilo di pubblicazione per lo slot di distribuzione specifico dal portale di Azure (slot di distribuzione> selezionare slot >Scarica profilo di pubblicazione).

Come aggiornare la configurazione di Tomcat dopo la distribuzione?

Se si vuole aggiornare una delle impostazioni delle app Web dopo la distribuzione, è possibile usare l'azione impostazioni del servizio app.

    - uses: azure/appservice-settings@v1
      with:
        app-name: 'my-app'
        slot-name: 'staging'  # Optional and needed only if the settings have to be configured on the specific deployment slot
        app-settings-json: '[{ "name": "CATALINA_OPTS", "value": "-Dfoo=bar" }]' 
        connection-strings-json: '${{ secrets.CONNECTION_STRINGS }}'
        general-settings-json: '{"alwaysOn": "false", "webSocketsEnabled": "true"}' #'General configuration settings as Key Value pairs'
      id: settings

Per ulteriori informazioni su come usare e configurare questa azione, vedere il repository delle impostazioni di App Service.

Contenuti correlati

Vedere i riferimenti seguenti in Azure GitHub Actions e nei flussi di lavoro:

  • Last updated on