Condividi tramite

Procedure consigliate per la distribuzione

  • Articolo

Nota

A partire dal 1° giugno 2024, le app appena create servizio app possono generare un nome host predefinito univoco che usa la convenzione <app-name>-<random-hash>.<region>.azurewebsites.netdi denominazione . I nomi delle app esistenti rimangono invariati. Ad esempio:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Per altre informazioni, vedere Nome host predefinito univoco per servizio app risorsa.

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 in app Azure Service: 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

Questa sezione descrive i tre componenti principali per la distribuzione in servizio app.

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 scenari di sviluppo e test, l'origine della distribuzione potrebbe 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 per ottenere l'applicazione in uno stato eseguibile.

I passaggi possono includere la compilazione di codice, la minimizzazione di HTML e JavaScript, l'esecuzione di test e i componenti di creazione di pacchetti. I comandi specifici eseguiti dalla pipeline di compilazione dipendono dallo stack di linguaggio. È possibile eseguire queste operazioni in un server di compilazione, ad esempio Azure Pipelines o 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 in Windows servizio app. Viene eseguito come secondo contenitore in Linux servizio app. 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, quando si distribuisce una nuova compilazione di produzione, usare gli slot di distribuzione. Con un livello di piano di servizio app Standard o superiore, è possibile distribuire l'app in un ambiente di gestione temporanea, convalidare le modifiche ed eseguire test di fumo. Quando si è pronti, scambiare gli slot di staging e di produzione. L'operazione di scambio prepara le istanze di lavoro necessarie in base alla scala di produzione, che elimina i tempi di inattività.

Distribuire continuamente il codice

Se il progetto dispone di rami designati per test, controllo di qualità e gestione temporanea, ognuno di questi rami deve essere distribuito continuamente in uno slot di staging. Questo approccio è noto come progettazione di Gitflow. Questa progettazione 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.

Diagramma che mostra il flusso tra i rami Dev, Staging e Main e gli slot in cui vengono distribuiti.

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 rispetto alla distribuzione del codice. È necessario eseguire il push dell'immagine in un registro contenitori e aggiornare il tag immagine nell'app Web.

Per ogni ramo che si vuole distribuire in uno slot, configurare l'automazione per eseguire queste attività 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 più recente predefinito. In caso contrario, è difficile tracciare il codice attualmente distribuito, che rende più difficile il debug.
  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 esegue 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 viene riavviato automaticamente ed esegue il pull della nuova immagine del contenitore.

Diagramma che mostra l'oggetto visivo utilizzo dello slot che rappresenta app Web, registro contenitori e rami del repository.

Questo articolo contiene 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. Passare all'app nel portale di Azure. In Distribuzione selezionare Centro distribuzione. Seguire le istruzioni per selezionare il repository e il ramo. Questo approccio configura una pipeline di compilazione e versione DevOps per compilare, contrassegnare e distribuire automaticamente il contenitore quando viene eseguito il push di nuovi commit nel ramo selezionato.

Usare GitHub Actions

È anche possibile automatizzare la distribuzione dei contenitori con GitHub Actions. Il file del flusso di lavoro compila e contrassegna il contenitore con l'ID commit, lo inserisce in un registro contenitori e aggiorna 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, fornendo le informazioni principali. È 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. Per altre informazioni, vedere Come accedere all'interfaccia della riga di comando di Azure in Circle CI.

Considerazioni specifiche del linguaggio

Tenere presenti le considerazioni seguenti per le implementazioni di Java, Node e .NET.

Java

Usare l'API zipdeploy Kudu per la distribuzione di applicazioni JAR. Usa wardeploy per le app WAR. Se si usa Jenkins, è possibile usare queste API direttamente nella fase di distribuzione. Per altre informazioni, vedere Distribuire nel servizio app Azure con Jenkins.

Node

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

Altre considerazioni includono cache locale e CPU o memoria elevata.

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. Per altre informazioni, vedere panoramica della cache locale del servizio app Azure.

Nota

La cache locale non è consigliata per i siti di gestione dei contenuti, ad esempio WordPress.

Per evitare tempi di inattività, usare sempre la cache locale con gli slot di distribuzione. Per informazioni sull'uso di queste funzionalità insieme, vedere Procedure consigliate.

CPU o memoria elevata

Se il piano di servizio app usa oltre il 90% della CPU o della memoria disponibile, la macchina virtuale sottostante potrebbe avere problemi durante l'elaborazione della distribuzione. Quando si verifica questa situazione, 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, visitare servizio app Diagnostica per scoprire le procedure consigliate praticabili specifiche per la risorsa.

  1. Passare all'App Web per le funzioni nel portale di Azure.

  2. Selezionare Diagnostica e risoluzione dei problemi nel riquadro di spostamento a sinistra, che si apre servizio app Diagnostica.

  3. Scegliere Disponibilità e prestazioni o esplorare altre opzioni, ad esempio Analisi cpu elevata.

    Visualizzare lo stato corrente dell'app per quanto riguarda 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.

Contenuto correlato