Condividi tramite

Eseguire la distribuzione nel servizio app usando GitHub Actions

  • Articolo

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

Prerequisiti

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

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

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

Quando si abilita la distribuzione continua, la creazione di app 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 Authentication method
Disabilitazione Identità assegnata dall'utente (OpenID Connect) (scelta consigliata)
Abilitare Autenticazione di base

Nota

È possibile che venga visualizzato un errore quando si crea l'app 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 Configurare la distribuzione di GitHub Actions dal Centro distribuzione.

Configurare la distribuzione di GitHub Actions dal Centro distribuzione

Per un'app esistente, è possibile iniziare rapidamente a usare GitHub Actions usando servizio app Deployment Center. Questo metodo turn-key genera un file del flusso di lavoro di GitHub Actions basato sullo stack di applicazioni ed esegue il commit nel repository GitHub.

Il Centro distribuzione consente anche di configurare facilmente l'autenticazione OpenID Connect più sicura con un'identità assegnata dall'utente. Per altre informazioni, vedere l'opzione di identità assegnata dall'utente.

Se l'account Azure dispone delle 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. In tal caso è necessario eseguire tre passaggi:

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

Generare le credenziali per la distribuzione

Il modo consigliato per eseguire l'autenticazione con i servizi di app Azure per GitHub Actions è con OpenID Connect. Questo approccio è un metodo di autenticazione che usa token di breve durata. La configurazione di OpenID Connect con GitHub Actions è più complessa, ma offre sicurezza avanzata.

In alternativa, è possibile eseguire l'autenticazione con un'identità gestita assegnata dall'utente, un'entità servizio o un profilo di pubblicazione.

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

  1. Se non si dispone di un'applicazione esistente, registrare una nuova applicazione Active Directory e un'entità servizio che possa accedere alle risorse. Creare l'applicazione Active Directory

    az ad app create --display-name myApp

    Questo comando restituisce un codice JSON con un oggetto appId che corrisponde a client-id. Salvare il valore da usare come AZURE_CLIENT_ID segreto GitHub in un secondo momento.

    Quando si creano le credenziali federate con l'API Graph, si usa il valore objectId e vi si fa riferimento come APPLICATION-OBJECT-ID.

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

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

    Copiare appOwnerTenantId da usare come segreto GitHub per AZURE_TENANT_ID in un secondo momento.

    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'oggetto generato id. Imparare a gestire le sottoscrizioni di Azure con l'interfaccia della riga di comando di Azure.

    az role assignment create --role 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'applicazione Active Directory.

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

    • Impostare un valore per CREDENTIAL-NAME a cui fare riferimento in seguito.

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

      • Per i processi nell'ambiente GitHub Actions: 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: 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. Salvare i valori come segreti GitHub è l'opzione più sicura.

  1. Aprire il repository GitHub e passare a Impostazioni Segreti>di sicurezza>e variabili>Azioni>Nuovo segreto del repository.

  2. Creare segreti per AZURE_CLIENT_ID, AZURE_TENANT_ID e 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. Salvare ogni segreto selezionando Aggiungi segreto.

Aggiungere il file del flusso di lavoro al repository GitHub

Un file YAML (.yml) nel /.github/workflows/ percorso 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 avrà i passaggi distinti seguenti:

  1. Eseguire l'autenticazione con servizio app usando il segreto GitHub creato.
  2. Compilare l'app Web.
  3. Distribuire l'app Web.

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

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

Per eseguire la distribuzione con OpenID Connect usando l'identità gestita configurata, usare l'azione azure/login@v1 con le client-idchiavi , tenant-ide subscription-id . Fare riferimento ai segreti 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:
      # Checkout the repo
      - uses: actions/checkout@main
      - uses: azure/login@v1
        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

Ricerca per categorie distribuire un file WAR tramite il plug-in Maven?

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

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

Per altre informazioni sul plug-in Maven e su come usarlo e configurarlo, vedere wiki del plug-in Maven per app Azure Servizio.

Ricerca per categorie distribuire un file WAR tramite l'interfaccia della riga di comando di Az?

Se si preferisce che l'interfaccia della riga di comando di Azure venga distribuita in 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 GitHub Action per l'interfaccia della riga di comando e su come usarla e configurarla, vedere l'azione GitHub dell'interfaccia della riga di comando di Azure.

Per altre informazioni sul comando az webapp deploy, su come usarlo e sui dettagli dei parametri, vedere la documentazione az webapp deploy.

Ricerca per categorie distribuire un file di avvio?

Usare GitHub Action per l'interfaccia della riga di comando. 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

Ricerca per categorie distribuire in un contenitore?

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

Ricerca per categorie 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 servizio app Impostazioni.

    - 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 altre informazioni su questa azione e su come usarla e configurarla, vedere il repository delle impostazioni di servizio app.

Contenuto correlato

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