Eseguire la distribuzione di un contenitore personalizzato nel servizio app usando GitHub Actions

Articolo
06/01/2023

GitHub Actions offre la flessibilità di creare un flusso di lavoro di sviluppo software automatizzato. Con l'azione Distribuzione Web di Azure, è possibile automatizzare il flusso di lavoro per distribuire contenitori personalizzati in servizio app usando GitHub Actions.

Un flusso di lavoro viene definito da un file YAML (con estensione yml) nel percorso /.github/workflows/ del repository. Questa definizione contiene i vari passaggi e parametri presenti nel flusso di lavoro.

Per un flusso di lavoro del contenitore Servizio app di Azure, il file include tre sezioni:

Sezione	Attività
autenticazione	1. Recuperare un'entità servizio o un profilo di pubblicazione. 2. Creare un segreto GitHub.
Build	1. Creare l'ambiente. 2. Compilare l'immagine del contenitore.
Distribuzione	1. Distribuire l'immagine del contenitore.

Prerequisiti

Un account Azure con una sottoscrizione attiva. Creare un account gratuitamente
Un account GitHub. Se non è disponibile, iscriversi per riceverne uno gratuito. È necessario disporre del codice in un repository GitHub per la distribuzione in Servizio app di Azure.
Registro contenitori di lavoro e app Servizio app di Azure per i contenitori. Questo esempio usa Registro Azure Container. Assicurarsi di completare la distribuzione completa in Servizio app di Azure per i contenitori. A differenza delle app Web regolari, le app Web per i contenitori non hanno una pagina di destinazione predefinita. Pubblicare il contenitore per avere un esempio funzionante.
- Informazioni su come creare un'applicazione Node.js in contenitori usando Docker, eseguire il push dell'immagine del contenitore in un registro e quindi distribuire l'immagine in Servizio app di Azure

Generare le credenziali per la distribuzione

Il modo consigliato per eseguire l'autenticazione con servizi app Azure per GitHub Actions è con un profilo di pubblicazione. È anche possibile eseguire l'autenticazione con un'entità servizio o Open ID Connect, ma il processo richiede altri passaggi.

Salvare le credenziali del profilo di pubblicazione o l'entità servizio come segreto GitHub per l'autenticazione con Azure. Si accederà al segreto all'interno del flusso di lavoro.

Un profilo di pubblicazione è una credenziale a livello di app. Configurare il profilo di pubblicazione come segreto GitHub.

Passare al servizio app nel portale di Azure.
Nella pagina Panoramica selezionare Recupera profilo di pubblicazione.

Nota

A partire da ottobre 2020, le app Web Linux dovranno impostare l'impostazione WEBSITE_WEBDEPLOY_USE_SCM dell'app su trueprima di scaricare il file. Questo requisito verrà rimosso in futuro. Per informazioni su come configurare le impostazioni comuni dell'app Web, vedere Configurare un'app servizio app nella portale di Azure.
Salvare il file scaricato. Si userà il contenuto del file per creare un segreto GitHub.

È possibile creare un'entità servizio con il comando az ad sp create-for-rbac dell'interfaccia della riga di comando di Azure. Eseguire questo comando con Azure Cloud Shell nel portale di Azure oppure selezionando il pulsante Prova.

az ad sp create-for-rbac --name "myApp" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> \
                            --json-auth

Nell'esempio sostituire i segnaposto con l'ID sottoscrizione, il nome del gruppo di risorse e il nome dell'app. L'output è un oggetto JSON con le credenziali di assegnazione del ruolo che forniscono l'accesso all'app servizio app. Copiare l'oggetto JSON per un uso successivo.

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    (...)
  }

Importante

È sempre consigliabile concedere l'accesso minimo. L'ambito nell'esempio precedente è limitato all'app specifica servizio app e non all'intero gruppo di risorse.

OpenID Connect è un metodo di autenticazione che usa token di breve durata. La configurazione di OpenID Connect con GitHub Actions è un processo più complesso che offre sicurezza avanzata.

Se non si dispone di un'applicazione esistente, registrare una nuova applicazione Active Directory e un'entità servizio che può accedere alle risorse. Creare l'applicazione Active Directory.
```
az ad app create --display-name myApp
```
Questo comando restituisce JSON con un appId oggetto che corrisponde client-ida . Salvare il valore da usare come AZURE_CLIENT_ID segreto GitHub in un secondo momento.

Si userà il valore durante la objectId creazione di credenziali federate con API Graph e fare riferimento a esso come APPLICATION-OBJECT-ID.
Creare un'entità servizio. Sostituire con l'appId $appID dall'output JSON.

Questo comando genera un output JSON diverso objectId e verrà usato nel passaggio successivo. Il nuovo objectId è .assignee-object-id

Copiare l'oggetto appOwnerTenantId da usare come segreto GitHub per AZURE_TENANT_ID un secondo momento.
```
 az ad sp create --id $appId
```
Creare una nuova assegnazione di ruolo in base alla sottoscrizione e all'oggetto. Per impostazione predefinita, l'assegnazione di ruolo verrà associata alla sottoscrizione predefinita. Sostituire $subscriptionId con l'ID sottoscrizione, $resourceGroupName con il nome del gruppo di risorse e $assigneeObjectId con l'oggetto generato assignee-object-id. Informazioni su come 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 --assignee-principal-type ServicePrincipal --scopes /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/
```
Eseguire il comando seguente per creare una nuova credenziale di identità federata per l'applicazione active directory.
- Sostituire APPLICATION-OBJECT-ID con objectId (generato durante la creazione dell'app) per l'applicazione Active Directory.
- Impostare un valore per CREDENTIAL-NAME per fare riferimento in un secondo momento.
- Impostare subject. Il valore di questo valore è definito da GitHub a seconda del flusso di lavoro:
  - Processi nell'ambiente di 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 rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<APPLICATION-OBJECT-ID>/federatedIdentityCredentials' --body '{"name":"<CREDENTIAL-NAME>","issuer":"https://token.actions.githubusercontent.com","subject":"repo:organization/repository:ref:refs/heads/main","description":"Testing","audiences":["api://AzureADTokenExchange"]}' 
```
Per informazioni su come creare un'applicazione active directory, un'entità servizio e le credenziali federate in portale di Azure, vedere Connettere GitHub e Azure.

Configurare il segreto GitHub per l'autenticazione

In GitHub esplorare il repository. Selezionare Impostazioni Segreti di sicurezza > e variabili > Azioni >> Nuovo segreto del repository.

Per usare le credenziali a livello di app, incollare il contenuto del file di profilo di pubblicazione scaricato nel campo valore del segreto. Assegnare al segreto il nome AZURE_WEBAPP_PUBLISH_PROFILE.

Quando si configura il flusso di lavoro gitHub, usare nell'azione AZURE_WEBAPP_PUBLISH_PROFILE Distribuisci app Web di Azure. Ad esempio:

- uses: azure/webapps-deploy@v2
  with:
    publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

In GitHub esplorare il repository. Selezionare Impostazioni Segreti di sicurezza > e variabili > Azioni >> Nuovo segreto del repository.

Per usare le credenziali a livello di utente, incollare l'intero output JSON dal comando dell'interfaccia della riga di comando di Azure nel campo valore del segreto. Assegnare un nome al segreto, ad esempio AZURE_CREDENTIALS.

Quando in seguito si configura il file del flusso di lavoro, si usa il segreto come creds di input dell'azione di accesso di Azure. Ad esempio:

- uses: azure/login@v1
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}

È necessario specificare l'ID client dell'applicazione, l'ID tenant e l'ID sottoscrizione all'azione di accesso. Questi valori possono essere forniti direttamente nel flusso di lavoro o possono essere archiviati nei segreti di GitHub e a cui si fa riferimento nel flusso di lavoro. Salvare i valori come segreti GitHub è l'opzione più sicura.

Aprire il repository GitHub e passare a Impostazioni > segreti di sicurezza > e variabili > Azioni > Nuovo segreto del repository.
Creare segreti per AZURE_CLIENT_ID, AZURE_TENANT_IDe AZURE_SUBSCRIPTION_ID. Usare questi valori dall'applicazione Active Directory per i segreti di GitHub. È possibile trovare questi valori nella portale di Azure cercando l'applicazione active directory.

Segreto gitHub Applicazione Active Directory

AZURE_CLIENT_ID ID applicazione (client)

AZURE_TENANT_ID ID directory (tenant)

AZURE_SUBSCRIPTION_ID ID sottoscrizione
Salvare ogni segreto selezionando Aggiungi segreto.

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

Configurare i segreti di GitHub per il Registro di sistema

Definire i segreti da usare con l'azione Docker Login. L'esempio in questo documento usa Registro Azure Container per il Registro contenitori.

Passare al contenitore nel portale di Azure o Docker e copiare il nome utente e la password. È possibile trovare il nome utente e la password Registro Azure Container nella portale di Azure in Impostazioni>chiavi di accesso per il Registro di sistema.
Definire un nuovo segreto per il nome utente del Registro di sistema denominato REGISTRY_USERNAME.
Definire un nuovo segreto per la password del Registro di sistema denominata REGISTRY_PASSWORD.

Compilare l'immagine contenitore

L'esempio seguente mostra parte del flusso di lavoro che compila un'immagine Docker Node.JS. Usare Docker Login per accedere a un registro contenitori privato. Questo esempio usa Registro Azure Container ma la stessa azione funziona per altri registri.

name: Linux Container Node Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}

È anche possibile usare l'accesso Docker per accedere a più registri contenitori contemporaneamente. Questo esempio include due nuovi segreti GitHub per l'autenticazione con docker.io. L'esempio presuppone che sia presente un Dockerfile a livello radice del Registro di sistema.

name: Linux Container Node Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - uses: azure/docker-login@v1
      with:
        login-server: index.docker.io
        username: ${{ secrets.DOCKERIO_USERNAME }}
        password: ${{ secrets.DOCKERIO_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}

Distribuire in un contenitore di servizio app

Per distribuire l'immagine in un contenitore personalizzato in servizio app, usare l'azioneazure/webapps-deploy@v2. Questa azione include sette parametri:

Parametro	Spiegazione
app-name	(Obbligatorio) Nome dell'app del servizio app
publish-profile	(Facoltativo) Si applica ai contenitori di App Web(Windows e Linux) e app Web(linux). Lo scenario multi contenitore non è supportato. Pubblicare il contenuto del file (*.publishsettings) con i segreti di distribuzione Web
slot-name	(Facoltativo) Immettere uno slot esistente diverso dallo slot di produzione
package	(Facoltativo) Si applica solo all'app Web: percorso del pacchetto o della cartella. .zip, .war, *.jar o una cartella per la distribuzione
images	(Obbligatorio) Si applica solo ai contenitori di app Web: specificare il nome completo dei contenitori. Ad esempio, "myregistry.azurecr.io/nginx:latest" o "python:3.7.2-alpine/". Per un'app multi-contenitore, è possibile specificare più nomi di immagine del contenitore (separati da più righe)
file di configurazione	(Facoltativo) Si applica solo ai contenitori di app Web: percorso del file Docker-Compose. Deve essere un percorso completo o relativo alla directory di lavoro predefinita. Obbligatorio per le app multi-contenitore.
comando di avvio	(Facoltativo) Immettere il comando start-up. Ad esempio, dotnet run o dotnet filename.dll

name: Linux Container Node Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}     

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'myapp'
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        images: 'mycontainer.azurecr.io/myapp:${{ github.sha }}'

on: [push]

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action' 
      uses: actions/checkout@main
    
    - name: 'Sign in via Azure CLI'
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}     
      
    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'myapp'
        images: 'mycontainer.azurecr.io/myapp:${{ github.sha }}'
    
    - name: Azure logout
      run: |
        az logout

on: [push]
name: Linux_Container_Node_Workflow

permissions:
      id-token: write
      contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action' 
      uses: actions/checkout@main
    
    - name: 'Sign in via Azure CLI'
      uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}     
      
    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'myapp'
        images: 'mycontainer.azurecr.io/myapp:${{ github.sha }}'
    
    - name: Azure logout
      run: |
        az logout

Passaggi successivi

Il set di azioni raggruppate in repository diversi è disponibile in GitHub. Ogni repository contiene documentazione ed esempi che consentono di usare GitHub per CI/CD e distribuire le app in Azure.