Eseguire l'app nel servizio app Azure direttamente da un pacchetto ZIP

In app Azure Servizio è possibile eseguire le app direttamente da un file di pacchetto ZIP di distribuzione. Questo articolo illustra come abilitare questa funzionalità nell'app.

Tutti gli altri metodi di distribuzione in servizio app hanno qualcosa in comune: i file vengono distribuiti in D:\home\site\wwwroot nell'app (o /home/site/wwwroot per le app Linux). Poiché la stessa directory viene usata dall'app in fase di esecuzione, è possibile che la distribuzione non riesca a causa di conflitti di blocco dei file e che l'app si comporti in modo imprevedibile perché alcuni file non sono ancora aggiornati.

Al contrario, quando si esegue direttamente da un pacchetto, i file nel pacchetto non vengono copiati nella directory wwwroot . Il pacchetto ZIP viene invece montato direttamente come directory wwwroot di sola lettura . L'esecuzione diretta da un pacchetto offre diversi vantaggi:

  • Elimina i conflitti di blocco dei file tra la distribuzione e il runtime.
  • Assicura che solo le app distribuite completamente siano in esecuzione in qualsiasi momento.
  • Possono essere distribuiti in un'app di produzione (con il riavvio).
  • Migliora le prestazioni delle distribuzioni Azure Resource Manager.
  • Si possono ridurre i tempi di avvio a freddo, in particolare per le funzioni di JavaScript con grandi alberi del pacchetto npm.

Nota

Attualmente sono supportati solo i file di pacchetto ZIP.

Creare un pacchetto ZIP del progetto

Importante

Quando si crea il pacchetto ZIP per la distribuzione, non includere la directory radice, ma solo i file e le directory in esso contenuti. Se si scarica un repository GitHub come file ZIP, non è possibile distribuire il file così com'è per servizio app. GitHub aggiunge altre directory annidate al livello superiore, che non funzionano con servizio app.

In una finestra terminale locale, passare alla directory radice del progetto dell'app.

Questa directory deve contenere il file di ingresso dell'app Web, ad esempio index.html, index.php e app.js. Può inoltre contenere file di gestione del pacchetto come project.json, composer.json, package.json, bower.json e requirements.txt.

A meno che non si voglia servizio app eseguire automaticamente l'automazione della distribuzione, eseguire tutte le attività di compilazione ( ad esempio , npm, composerbowergulp, , e pip) e assicurarsi di disporre di tutti i file necessari per eseguire l'app. Questo passaggio è obbligatorio se si vuole eseguire direttamente il pacchetto.

Creare un archivio ZIP per tutti gli elementi del progetto. Per dotnet i progetti, questo è tutto nella directory di output del dotnet publish comando (escluso la directory di output stessa). Ad esempio, il comando seguente nel terminale per creare un pacchetto ZIP del contenuto della directory corrente:

# Bash
zip -r <file-name>.zip .

# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip

Abilitare l'esecuzione dal pacchetto

L'impostazione dell'app WEBSITE_RUN_FROM_PACKAGE abilita l'esecuzione da un pacchetto. Per impostarlo, eseguire il comando seguente con l'interfaccia della riga di comando di Azure.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_RUN_FROM_PACKAGE="1"

WEBSITE_RUN_FROM_PACKAGE="1" consente di eseguire l'app da un pacchetto locale all'app. È anche possibile eseguire da un pacchetto remoto.

Eseguire il pacchetto

Il modo più semplice per eseguire un pacchetto nel servizio app consiste nell'usare il comando az webapp deployment source config-zip dell'interfaccia della riga di comando di Azure. Ad esempio:

az webapp deployment source config-zip --resource-group <group-name> --name <app-name> --src <filename>.zip

Poiché l'impostazione dell'app WEBSITE_RUN_FROM_PACKAGE è impostata, questo comando non estrae il contenuto del pacchetto nella directory D:\home\site\wwwroot dell'app. Carica invece il file ZIP così com'è in D:\home\data\SitePackages e crea un packagename.txt nella stessa directory, che contiene il nome del pacchetto ZIP da caricare in fase di esecuzione. Se si carica il pacchetto ZIP in modo diverso,ad esempio FTP, è necessario creare manualmente la directory D:\home\data\SitePackages e il file packagename.txt manualmente.

Il comando riavvia anche l'app. Poiché WEBSITE_RUN_FROM_PACKAGE è impostato, servizio app monta il pacchetto caricato come directory wwwroot di sola lettura ed esegue l'app direttamente da quella directory montata.

Eseguire invece da URL esterno

È anche possibile eseguire un pacchetto da un URL esterno, ad esempio Archiviazione BLOB di Azure. È possibile usare Azure Storage Explorer per caricare i file di pacchetto nell'account di archiviazione BLOB. È consigliabile usare un contenitore di archiviazione privato con una firma di accesso condiviso (SAS) o usare un'identità gestita per consentire al runtime di servizio app di accedere al pacchetto in modo sicuro.

Dopo aver caricato il file nell'archivio BLOB e avere un URL di firma di accesso condiviso per il file, impostare l'impostazione dell'app WEBSITE_RUN_FROM_PACKAGE sull'URL. L'esempio seguente esegue questa operazione usando l'interfaccia della riga di comando di Azure:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_RUN_FROM_PACKAGE="https://myblobstorage.blob.core.windows.net/content/SampleCoreMVCApp.zip?st=2018-02-13T09%3A48%3A00Z&se=2044-06-14T09%3A48%3A00Z&sp=rl&sv=2017-04-17&sr=b&sig=bNrVrEFzRHQB17GFJ7boEanetyJ9DGwBSV8OM3Mdh%2FM%3D"

Se si pubblica un pacchetto aggiornato con lo stesso nome nell'archivio BLOB, è necessario riavviare l'app in modo che il pacchetto aggiornato venga caricato in servizio app.

Accedere a un pacchetto in Archiviazione BLOB di Azure usando un'identità gestita

Archiviazione BLOB di Azure può essere configurato per autorizzare le richieste con Microsoft Entra ID. Ciò significa che invece di generare una chiave di firma di accesso condiviso con una scadenza, è invece possibile basarsi sull'identità gestita dell'applicazione. Per impostazione predefinita, verrà usata l'identità assegnata dal sistema dell'app. Se vuoi specificare un'identità assegnata dall'utente, puoi impostare l'impostazione dell'app WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID sull'ID risorsa di tale identità. L'impostazione può anche accettare "SystemAssigned" come valore, anche se equivale a omettere completamente l'impostazione.

Per abilitare il recupero del pacchetto tramite l'identità:

  1. Assicurarsi che il BLOB sia configurato per l'accesso privato.

  2. Concedere all'identità il ruolo lettore di dati BLOB Archiviazione con ambito sul BLOB del pacchetto. Per informazioni dettagliate sulla creazione dell'assegnazione di ruolo, vedere Assegnare un ruolo di Azure per l'accesso ai dati BLOB.

  3. Impostare l'impostazione dell'applicazione WEBSITE_RUN_FROM_PACKAGE sull'URL BLOB del pacchetto. Probabilmente si tratta del formato "https://{nome-account-archiviazione}.blob.core.windows.net/{nome-contenitore}/{path-to-package}" o simile.

Distribuire file di processo Web durante l'esecuzione dal pacchetto

Quando si abilita l'esecuzione di un'app dal pacchetto, è possibile distribuire file di processi Web in due modi:

  • Distribuire nello stesso pacchetto ZIP dell'app: includerli come si farebbe normalmente in <project-root>\app_data\jobs\... (che esegue il mapping al percorso \site\wwwroot\app_data\jobs\... di distribuzione come specificato nella guida introduttiva di Processi Web).
  • Distribuire separatamente dal pacchetto ZIP dell'app: poiché il percorso \site\wwwroot\app_data\jobs\... di distribuzione consueto è ora di sola lettura, non è possibile distribuire i file del processo Web in questa posizione. Distribuire invece i file del processo Web in \site\jobs\..., che non è di sola lettura. Processi Web distribuiti in \site\wwwroot\app_data\jobs\... ed \site\jobs\... entrambi vengono eseguiti.

Nota

Quando \site\wwwroot diventa di sola lettura, le operazioni come la creazione di disable.job avranno esito negativo.

Risoluzione dei problemi

  • L'esecuzione diretta da un pacchetto rende wwwroot di sola lettura. L'app riceverà un errore se tenta di scrivere file in questa directory.
  • I formati TAR e GZIP non sono supportati.
  • Il file ZIP può essere al massimo 1 GB
  • Questa funzionalità non è compatibile con la cache locale.
  • Per migliorare le prestazioni di avvio a freddo, usare l'opzione zip locale (WEBSITE_RUN_FROM_PACKAGE=1).

Altre risorse