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 nella creazione guidata di app predefinita. È sufficiente 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 creazione guidata di servizio app.

Quando si abilita la distribuzione continua, la creazione guidata dell'app seleziona automaticamente il metodo di autenticazione in base alla selezione dell'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

Nota

Se viene visualizzato un errore durante la creazione dell'app che informa che l'account Azure non dispone di determinate autorizzazioni, potrebbe non avere 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 automaticamente 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 l'opzione di identità assegnata dall'utente.

Se l'account Azure dispone delle autorizzazioni necessarie, è possibile selezionare per creare un'identità assegnata dall'utente. In caso contrario, è possibile selezionare un'identità gestita assegnata dall'utente esistente nell'elenco 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

È anche possibile distribuire un flusso di lavoro senza usare il Centro distribuzione. In tal caso è necessario eseguire 3 passaggi:

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

1. Generare le credenziali di distribuzione

Il modo consigliato per eseguire l'autenticazione con i servizi di app Azure per GitHub Actions è con OpenID Connect. Si tratta di 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.

Di seguito vengono illustrati 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 in grado di 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 segreto GitHub AZURE_CLIENT_ID in un secondo momento.

    Si userà il valore objectId quando si creano credenziali federate con l'API Graph e si farà riferimento come APPLICATION-OBJECT-ID.

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

    Questo comando genera un output JSON con un objectId diverso e verrà usato 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 di 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. Il valore è definito da GitHub a seconda del flusso di lavoro:
      • 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"
    ]
}

2. Configurare il segreto 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.

3. Aggiungere il file del flusso di lavoro al repository GitHub

Un flusso di lavoro viene definito da un file YAML (.yml) nel /.github/workflows/ percorso nel repository GitHub. 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 la definizione di 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 e 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, si useranno le credenziali di accesso di Azure.

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

Altre informazioni sul plug-in Maven e su come usarlo e configurarlo sono disponibili nel 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

Altre informazioni su GitHub Action per l'interfaccia della riga di comando e su come usarla e configurarla sono disponibili nell'azione GitHub dell'interfaccia della riga di comando di Azure. Altre informazioni sul comando az webapp deploy, su come usare e i dettagli dei parametri sono disponibili nella 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. Informazioni dettagliate sui passaggi per la distribuzione con GitHub Actions sono disponibili in Deploy to a Container (Distribuisci 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

Altre informazioni su questa azione e su come usarla e configurarla sono disponibili nel repository delle impostazioni di servizio app.

Passaggi successivi

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