Procedure consigliate per la distribuzione

Ogni team di sviluppo ha requisiti univoci che possono rendere difficile l'implementazione di una pipeline di distribuzione efficiente in diversi servizi cloud. Questo articolo presenta i tre componenti principali della distribuzione nel servizio app: origini di distribuzione, pipeline di compilazione e meccanismi di distribuzione. Questo articolo illustra anche alcune procedure consigliate e suggerimenti per stack di linguaggi specifici.

Componenti della distribuzione

Origine distribuzione

Un'origine di distribuzione è il percorso del codice dell'applicazione. Per le app di produzione, l'origine della distribuzione è in genere un repository ospitato dal software di controllo della versione, ad esempio GitHub, BitBucket o Azure Repos. Per gli scenari di sviluppo e test, l'origine della distribuzione può essere un progetto nel computer locale.

Pipeline di compilazione

Dopo aver scelto un'origine di distribuzione, il passaggio successivo consiste nel scegliere una pipeline di compilazione. Una pipeline di compilazione legge il codice sorgente dall'origine della distribuzione ed esegue una serie di passaggi( ad esempio la compilazione di codice, la minimizzazione di HTML e JavaScript, l'esecuzione di test e i componenti di creazione di pacchetti) per ottenere l'applicazione in uno stato eseguibile. I comandi specifici eseguiti dalla pipeline di compilazione dipendono dallo stack di linguaggio. Queste operazioni possono essere eseguite in un server di compilazione, ad esempio Azure Pipelines, o eseguite in locale.

Meccanismo di distribuzione

Il meccanismo di distribuzione è l'azione usata per inserire l'applicazione incorporata nella directory /home/site/wwwroot dell'app Web. La directory /wwwroot è un percorso di archiviazione montato condiviso da tutte le istanze dell'app Web. Quando il meccanismo di distribuzione inserisce l'applicazione in questa directory, le istanze ricevono una notifica per sincronizzare i nuovi file. Il Servizio app di Azure supporta i meccanismi di distribuzione seguenti:

• Endpoint Kudu: Kudu è lo strumento di produttività per sviluppatori open source che viene eseguito come processo separato nel servizio app di Windows e come secondo contenitore nel servizio app Linux. Kudu gestisce le distribuzioni continue e fornisce endpoint HTTP per la distribuzione, ad esempio zipdeploy/.
• FTP e WebDeploy: usando le credenziali sito o utente, è possibile caricare file tramite FTP o WebDeploy. Questi meccanismi non passano attraverso Kudu.

Gli strumenti di distribuzione, ad esempio Azure Pipelines, Jenkins e i plug-in dell'editor, usano uno di questi meccanismi di distribuzione.

Uso di slot di distribuzione

Quando possibile, usare slot di distribuzione durante la distribuzione di una nuova compilazione di produzione. Quando si usa un livello del piano di Servizio app Standard o superiore, è possibile distribuire l'app in un ambiente di gestione temporanea, convalidare le modifiche ed eseguire smoke test. Quando è tutto pronto, è possibile scambiare gli slot di staging e di produzione. L'operazione di scambio prepara le istanze di lavoro necessarie in base alla scala di produzione, eliminando così i tempi di inattività.

Distribuire continuamente il codice

Se il progetto ha designato rami per test, controllo di qualità e gestione temporanea, ognuno di questi rami deve essere distribuito continuamente in uno slot di staging. (questo è noto come Progettazione di Gitflow). Ciò consente agli stakeholder di valutare e testare facilmente il ramo distribuito.

La distribuzione continua non deve mai essere abilitata per lo slot di produzione. Al contrario, il ramo di produzione (spesso principale) deve essere distribuito in uno slot non di produzione. Quando si è pronti a rilasciare il ramo di base, scambiarlo nello slot di produzione. Lo scambio in produzione, anziché la distribuzione nell'ambiente di produzione, impedisce tempi di inattività e consente di eseguire di nuovo il rollback delle modifiche scambiando di nuovo.

Distribuire continuamente contenitori

Per i contenitori personalizzati di Docker o di altri registri contenitori, distribuire l'immagine in uno slot di staging e scambiarla in produzione per evitare tempi di inattività. L'automazione è più complessa della distribuzione del codice perché è necessario eseguire il push dell'immagine in un registro contenitori e aggiornare il tag immagine nell'app Web.

Per ogni ramo che si desidera distribuire in uno slot, configurare l'automazione per eseguire le operazioni seguenti in ogni commit nel ramo.

1. Compilare e contrassegnare l'immagine. Come parte della pipeline di compilazione, contrassegnare l'immagine con l'ID commit git, il timestamp o altre informazioni identificabili. È consigliabile non usare il tag "latest" predefinito. In caso contrario, è difficile tracciare il codice attualmente distribuito, che rende il debug molto più difficile.
2. Eseguire il push dell'immagine con tag. Dopo aver compilato e contrassegnato l'immagine, la pipeline esegue il push dell'immagine nel registro contenitori. Nel passaggio successivo, lo slot di distribuzione eseguirà il pull dell'immagine contrassegnata dal registro contenitori.
3. Aggiornare lo slot di distribuzione con il nuovo tag immagine. Quando questa proprietà viene aggiornata, il sito verrà riavviato automaticamente ed eseguirà il pull della nuova immagine del contenitore.

Di seguito sono riportati esempi per framework di automazione comuni.

Usare Azure DevOps

Il Servizio app di Azure include il recapito continuo predefinito per i contenitori tramite il Centro distribuzione. Andare all'app nel portale di Azure e selezionare Centro distribuzione in Distribuzione. Seguire le istruzioni per selezionare il repository e il ramo. Verrà configurata una pipeline di compilazione e versione DevOps per compilare, contrassegnare e distribuire automaticamente il contenitore quando vengono inseriti nuovi commit nel ramo selezionato.

Usare GitHub Actions

È anche possibile automatizzare la distribuzione dei contenitori con GitHub Actions. Il file del flusso di lavoro seguente creerà e contrassegnerà il contenitore con l'ID commit, lo eseguirà il push in un registro contenitori e aggiornerà l'app Web specificata con il nuovo tag immagine.

on:
  push:
    branches:
    - <your-branch-name>

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

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

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

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Usare altri provider di automazione

I passaggi elencati in precedenza si applicano ad altre utilità di automazione, ad esempio CircleCI o Travis CI. Tuttavia, è necessario usare l'interfaccia della riga di comando di Azure per aggiornare gli slot di distribuzione con i nuovi tag di immagine nel passaggio finale. Per usare l'interfaccia della riga di comando di Azure nello script di automazione, generare un'entità servizio usando il comando seguente.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

Nello script accedere usando az login --service-principal, specificando le informazioni dell'entità. È quindi possibile usare az webapp config container set per impostare il nome del contenitore, il tag, l'URL del Registro di sistema e la password del Registro di sistema. Di seguito sono riportati alcuni collegamenti utili per costruire il processo di integrazione continua del contenitore.

• Come accedere all'interfaccia della riga di comando di Azure in Circle CI

Considerazioni specifiche del linguaggio

Java

Usare l'API Kudu zipdeploy/ per la distribuzione di applicazioni JAR e wardeploy/ per le app WAR. Se si usa Jenkins, è possibile usare queste API direttamente nella fase di distribuzione. Per altre informazioni, vedi questo articolo.

Nodo

Per impostazione predefinita, Kudu esegue i passaggi di compilazione per l'applicazione Node (npm install). Se si usa un servizio di compilazione come Azure DevOps, la compilazione Kudu non è necessaria. Per disabilitare la compilazione Kudu, creare un'impostazione dell'app, SCM_DO_BUILD_DURING_DEPLOYMENT, con il valore false.

.NET

Per impostazione predefinita, Kudu esegue i passaggi di compilazione per l'applicazione .NET (dotnet build). Se si usa un servizio di compilazione come Azure DevOps, la compilazione Kudu non è necessaria. Per disabilitare la compilazione Kudu, creare un'impostazione dell'app, SCM_DO_BUILD_DURING_DEPLOYMENT, con il valore false.

Altre considerazioni sulla distribuzione

cache locale

Il contenuto del Servizio app di Azure viene memorizzato in Archiviazione di Azure e presentato in modo permanente come condivisione del contenuto. Tuttavia, alcune app necessitano solo di un archivio di contenuti di sola lettura a prestazioni elevate che possono essere eseguite con disponibilità elevata. Queste app possono trarre vantaggio dall'uso della cache locale. La cache locale non è consigliata per i siti di gestione dei contenuti, ad esempio WordPress.

Usare sempre la cache locale insieme agli slot di distribuzionesoftware per evitare tempi di inattività. Vedere questa sezione per informazioni sull'uso di queste funzionalità insieme.

Utilizzo elevato di CPU o di memoria

Se il piano di Servizio app di Azure usa oltre il 90% della CPU o della memoria disponibile, la macchina virtuale sottostante potrebbe avere problemi durante l'elaborazione della distribuzione. In questo caso, aumentare temporaneamente il numero di istanze per eseguire la distribuzione. Al termine della distribuzione, è possibile restituire il numero di istanze al valore precedente.

Per altre informazioni sulle procedure consigliate, vedere Diagnostica del Servizio app di Azure per scoprire le procedure consigliate praticabili specifiche della risorsa.

• Passare all'App Web per le funzioni nel portale di Azure.
• Selezionare Diagnosticare e risolvere i problemi nel riquadro di spostamento sinistro, che apre Diagnostica del Servizio app di Azure.
• Scegliere il riquadro della home page Procedure consigliate.
• Selezionare Procedure consigliate per la disponibilità e le prestazioni o Procedure consigliate per la configurazione ottimale per visualizzare lo stato corrente dell'app in relazione a queste procedure consigliate.

È anche possibile usare questo collegamento per aprire direttamente diagnostica del Servizio app di Azure per la risorsa: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Altre risorse

Informazioni di riferimento sulle variabili di ambiente e impostazioni dell'app