Dela via

Kör din app i Azure App Service direkt från ett ZIP-paket

  • Artikel

Kommentar

Körning från paket stöds inte för Python-appar. När du distribuerar en ZIP-fil med Python-koden måste du ange en flagga för att aktivera Azure Build Automation. Byggautomatiseringen skapar den virtuella Python-miljön för din app och installerar alla nödvändiga krav och paket som behövs. Mer information finns i skapa automatisering .

I Azure App Service kan du köra dina appar direkt från en ZIP-paketfil för distribution. Den här artikeln visar hur du aktiverar den här funktionen i din app.

Alla andra distributionsmetoder i App Service har något gemensamt: dina filer distribueras till D:\home\site\wwwroot i din app (eller /home/site/wwwroot för Linux-appar). Eftersom samma katalog används av din app vid körning är det möjligt att distributionen misslyckas på grund av fillåskonflikter och att appen beter sig oförutsägbart eftersom vissa filer ännu inte har uppdaterats.

När du däremot kör direkt från ett paket kopieras inte filerna i paketet till katalogen wwwroot . I stället monteras själva ZIP-paketet direkt som den skrivskyddade wwwroot-katalogen . Det finns flera fördelar med att köra direkt från ett paket:

  • Eliminerar fillåskonflikter mellan distribution och körning.
  • Säkerställer att endast fulldistribuerade appar körs när som helst.
  • Kan distribueras till en produktionsapp (med omstart).
  • Förbättrar prestandan för Azure Resource Manager-distributioner.
  • Kan minska kalla starttider, särskilt för JavaScript-funktioner med stora npm-paketträd.

Kommentar

För närvarande stöds endast ZIP-paketfiler.

Skapa ett projekt-ZIP-paket

Viktigt!

När du skapar ZIP-paketet för distribution ska du inte ta med rotkatalogen, utan bara filerna och katalogerna i den. Om du laddar ned en GitHub-lagringsplats som en ZIP-fil kan du inte distribuera filen som den är till App Service. GitHub lägger till ytterligare kapslade kataloger på den översta nivån, som inte fungerar med App Service.

I ett lokalt terminalfönster navigerar du till rotkatalogen för ditt appprojekt.

Den här katalogen bör innehålla postfilen till webbappen, till exempel index.html, index.php och app.js. Den kan också innehålla pakethanteringsfiler som project.json, composer.json, package.json, bower.json och requirements.txt.

Om du inte vill att App Service ska köra distributionsautomation åt dig kör du alla bygguppgifter (till exempel npm, , bowergulp, composeroch ) och pipser till att du har alla filer som du behöver för att köra appen. Det här steget krävs om du vill köra paketet direkt.

Skapa ett ZIP-arkiv med allt i projektet. För dotnet projekt är detta allt i utdatakatalogen för dotnet publish kommandot (exklusive själva utdatakatalogen). Följande kommando i terminalen för att skapa ett ZIP-paket med innehållet i den aktuella katalogen:

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

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

Aktivera körning från paket

Appinställningen WEBSITE_RUN_FROM_PACKAGE aktiverar körning från ett paket. Om du vill ange det kör du följande kommando med Azure CLI.

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

WEBSITE_RUN_FROM_PACKAGE="1" låter dig köra din app från ett paket som är lokalt till din app. Du kan också köra från ett fjärrpaket.

Kör paketet

Det enklaste sättet att köra ett paket i Din App Service är med azure CLI az webapp deployment source config-zip command. Till exempel:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <filename>.zip

Eftersom appinställningen WEBSITE_RUN_FROM_PACKAGE har angetts extraherar inte det här kommandot paketinnehållet till katalogen D:\home\site\wwwroot i din app. I stället laddar den upp ZIP-filen som den är till D:\home\data\SitePackages och skapar en packagename.txt i samma katalog som innehåller namnet på ZIP-paketet som ska läsas in vid körning. Om du laddar upp ZIP-paketet på ett annat sätt (till exempel FTP) måste du skapa katalogen D:\home\data\SitePackages och packagename.txt filen manuellt.

Kommandot startar också om appen. Eftersom WEBSITE_RUN_FROM_PACKAGE har angetts monterar App Service det uppladdade paketet som den skrivskyddade wwwroot-katalogen och kör appen direkt från den monterade katalogen.

Kör från en extern URL i stället

Du kan också köra ett paket från en extern URL, till exempel Azure Blob Storage. Du kan använda Azure Storage Explorer för att ladda upp paketfiler till ditt Blob Storage-konto. Du bör använda en privat lagringscontainer med en signatur för delad åtkomst (SAS) eller använda en hanterad identitet för att göra det möjligt för App Service-körningen att komma åt paketet på ett säkert sätt.

Kommentar

För närvarande kan inte en befintlig App Service-resurs som kör ett lokalt paket migreras för att köras från ett fjärrpaket. Du måste skapa en ny App Service-resurs som är konfigurerad att köras från en extern URL.

När du har laddat upp filen till Blob Storage och har en SAS-URL för filen anger du appinställningen WEBSITE_RUN_FROM_PACKAGE till URL:en. Följande exempel gör det med hjälp av Azure CLI:

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"

Om du publicerar ett uppdaterat paket med samma namn till Blob Storage måste du starta om appen så att det uppdaterade paketet läses in i App Service.

Få åtkomst till ett paket i Azure Blob Storage med hjälp av en hanterad identitet

Du kan konfigurera Azure Blob Storage för att auktorisera begäranden med Microsoft Entra-ID. Den här konfigurationen innebär att du i stället för att generera en SAS-nyckel med förfallodatum kan förlita dig på programmets hanterade identitet. Som standard används appens systemtilldelade identitet. Om du vill ange en användartilldelad identitet kan du ange appinställningen WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID till resurs-ID för den identiteten. Inställningen kan också accepteras SystemAssigned som ett värde, vilket motsvarar att utelämna inställningen.

Så här aktiverar du att paketet hämtas med hjälp av identiteten:

  1. Kontrollera att bloben har konfigurerats för privat åtkomst.

  2. Ge identiteten rollen Storage Blob Data Reader med omfång över paketbloben. Mer information om hur du skapar rolltilldelningen finns i Tilldela en Azure-roll för åtkomst till blobdata .

  3. Ange programinställningen WEBSITE_RUN_FROM_PACKAGE till paketets blob-URL. Den här URL:en är vanligtvis av formuläret https://{storage-account-name}.blob.core.windows.net/{container-name}/{path-to-package} eller liknande.

Distribuera WebJob-filer när du kör från paketet

Det finns två sätt att distribuera webbjobbsfiler när du aktiverar körning av en app från paket:

  • Distribuera i samma ZIP-paket som din app: inkludera dem som du normalt skulle göra i <project-root>\app_data\jobs\... (som mappar till distributionssökvägen \site\wwwroot\app_data\jobs\... enligt vad som anges i snabbstarten webbjobb).
  • Distribuera separat från ZIP-paketet i din app: Eftersom den vanliga distributionssökvägen \site\wwwroot\app_data\jobs\... nu är skrivskyddad kan du inte distribuera WebJob-filer där. Distribuera i stället WebJob-filer till \site\jobs\..., som inte är skrivskyddade. WebJobs distribuerade till \site\wwwroot\app_data\jobs\... och \site\jobs\... båda körs.

Kommentar

När \site\wwwroot blir skrivskyddad misslyckas åtgärder som att skapa disable.job .

Felsökning

  • Om du kör direkt från ett paket blir wwwroot det skrivskyddat. Appen får ett felmeddelande om den försöker skriva filer till den här katalogen.
  • TAR- och GZIP-format stöds inte.
  • ZIP-filen kan vara högst 1 GB
  • Den här funktionen är inte kompatibel med lokal cache.
  • Använd det lokala Zip-alternativet (WEBSITE_RUN_FROM_PACKAGE=1) för att få bättre prestanda vid kallstart.

Fler resurser