Share via


Bestanden implementeren in App Service

Notitie

Vanaf 1 juni 2024 hebben alle nieuw gemaakte App Service-apps de mogelijkheid om een unieke standaardhostnaam te genereren met behulp van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Raadpleeg de unieke standaardhostnaam voor App Service-resource voor meer informatie.

In dit artikel leest u hoe u uw code implementeert als een ZIP-, WAR-, JAR- of EAR-pakket in Azure-app Service. Ook ziet u hoe u afzonderlijke bestanden implementeert in App Service, gescheiden van uw toepassingspakket.

Vereisten

Als u de stappen in dit artikel wilt uitvoeren, maakt u een App Service-app of gebruikt u een app die u hebt gemaakt voor een andere zelfstudie.

Als u geen Azure-abonnement hebt, kunt u een gratis Azure-account maken voordat u begint.

Een ZIP-projectpakket maken

Belangrijk

Neem bij het maken van het ZIP-pakket voor implementatie niet de hoofdmap op, maar alleen de bestanden en mappen erin. Als u een GitHub-opslagplaats als een ZIP-bestand downloadt, kunt u dat bestand niet implementeren in App Service. GitHub voegt extra geneste mappen toe op het hoogste niveau, die niet werken met App Service.

Navigeer in een lokaal terminalvenster naar de hoofdmap van uw app-project.

Deze map moet het invoerbestand bevatten voor uw web-app, zoals index.html, index.php en app.js. Het kan ook pakketbeheerbestanden bevatten, zoals project.json, composer.json, package.json, bower.json en requirements.txt.

Tenzij u wilt dat App Service implementatieautomatisering voor u uitvoert, voert u alle buildtaken (bijvoorbeeld npm, bower, gulp, composeren ) pipuit en controleert u of u alle bestanden hebt die u nodig hebt om de app uit te voeren. Deze stap is vereist als u uw pakket rechtstreeks wilt uitvoeren.

Maak een ZIP-archief van alle bestanden in uw project. Voor dotnet projecten is dit alles in de uitvoermap van de dotnet publish opdracht (met uitzondering van de uitvoermap zelf). Bijvoorbeeld de volgende opdracht in uw terminal om een ZIP-pakket te maken van de inhoud van de huidige map:

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

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

Een ZIP-pakket implementeren

Wanneer u een ZIP-pakket implementeert, pakt App Service de inhoud ervan uit in het standaardpad voor uw app (D:\home\site\wwwroot voor Windows, /home/site/wwwroot voor Linux).

Deze ZIP-pakketimplementatie maakt gebruik van dezelfde Kudu-service die continue implementaties op basis van integratie mogelijk maakt. Kudu biedt ondersteuning voor de volgende functionaliteit voor de implementatie van ZIP-pakketten:

  • Verwijdering van bestanden die zijn overgelaten uit een eerdere implementatie.
  • Optie voor het inschakelen van het standaard buildproces, waaronder pakketherstel.
  • Implementatieaanpassing, inclusief het uitvoeren van implementatiescripts.
  • Implementatielogboeken.
  • Een pakketgroottelimiet van 2048 MB.

Notitie

Bestanden in het ZIP-pakket worden alleen gekopieerd als hun tijdstempels niet overeenkomen met wat er al is geïmplementeerd.

Met de gebruikersinterface voor zip-implementatie in Kudu

Navigeer in de browser naar https://<app_name>.scm.azurewebsites.net/ZipDeployUI (zie opmerking bovenaan).

Upload het ZIP-pakket dat u hebt gemaakt in Een ZIP-projectpakket maken door het naar het gebied verkenner op de webpagina te slepen.

Wanneer de implementatie wordt uitgevoerd, toont een pictogram rechtsboven in de hoek de voortgang in procenten. De pagina toont ook uitgebreide berichten voor de bewerking onder het gedeelte van de verkenner. Wanneer de implementatie is voltooid, moet het laatste bericht zeggen Deployment successful.

Het bovenstaande eindpunt werkt momenteel niet voor Linux App Services. Overweeg in plaats daarvan FTP of de ZIP-implementatie-API te gebruiken.

Zonder zip-implementatieinterface in Kudu

Implementeer een ZIP-pakket in uw web-app met behulp van de opdracht az webapp deploy . De CLI-opdracht maakt gebruik van de Kudu-publicatie-API om de bestanden te implementeren en kan volledig worden aangepast.

In het volgende voorbeeld wordt een ZIP-pakket naar uw site gepusht. Geef het pad op naar uw lokale ZIP-pakket voor --src-path.

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

Met deze opdracht wordt de app opnieuw opgestart nadat het ZIP-pakket is geïmplementeerd.

Buildautomatisering inschakelen voor zip-implementatie

Standaard gaat de implementatie-engine ervan uit dat een ZIP-pakket gereed is om als zodanig te worden uitgevoerd en dat er geen buildautomatisering wordt uitgevoerd. Als u dezelfde buildautomatisering wilt inschakelen als in een Git-implementatie, stelt u de app-instelling SCM_DO_BUILD_DURING_DEPLOYMENT in door de volgende opdracht uit te voeren in Cloud Shell:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings SCM_DO_BUILD_DURING_DEPLOYMENT=true

Zie onze Kudu-documentatie voor meer informatie.

WAR/JAR/EAR-pakketten implementeren

U kunt uw WAR-, JAR- of EAR-pakket implementeren in App Service om uw Java-web-app uit te voeren met behulp van de Azure CLI, PowerShell of de Kudu-publicatie-API.

Het implementatieproces dat hier wordt weergegeven, plaatst het pakket in de inhoudsshare van de app met de juiste naamconventie en mapstructuur (zie Kudu-publicatie-API-verwijzing) en is de aanbevolen benadering. Als u IN plaats daarvan WAR/JAR/EAR-pakketten implementeert met FTP of WebDeploy, ziet u mogelijk onbekende fouten vanwege fouten in de naamgeving of structuur.

Implementeer een WAR-pakket naar Tomcat of JBoss EAP met behulp van de opdracht az webapp deploy . Geef het pad op naar uw lokale Java-pakket voor --src-path.

az webapp deploy --resource-group <group-name> --name <app-name> --src-path ./<package-name>.war

De CLI-opdracht maakt gebruik van de Kudu-publicatie-API om het pakket te implementeren en kan volledig worden aangepast.

Afzonderlijke bestanden implementeren

Implementeer een opstartscript, bibliotheek en statisch bestand in uw web-app met behulp van de opdracht az webapp deploy met de --type parameter.

Als u op deze manier een opstartscript implementeert, gebruikt App Service automatisch uw script om uw app te starten.

De CLI-opdracht maakt gebruik van de Kudu-publicatie-API om de bestanden te implementeren en kan volledig worden aangepast.

Een opstartscript implementeren

az webapp deploy --resource-group <group-name> --name <app-name> --src-path scripts/startup.sh --type=startup

Een bibliotheekbestand implementeren

az webapp deploy --resource-group <group-name> --name <app-name> --src-path driver.jar --type=lib

Een statisch bestand implementeren

az webapp deploy --resource-group <group-name> --name <app-name> --src-path config.json --type=static

Implementeren in met het netwerk beveiligde apps

Afhankelijk van de netwerkconfiguratie van uw web-app kan directe toegang tot de app vanuit uw ontwikkelomgeving worden geblokkeerd (zie Implementeren op sites met netwerkbeveiliging en implementeren op sites met netwerkbeveiliging, deel 2). In plaats van het pakket of bestand rechtstreeks naar de web-app te pushen, kunt u het publiceren naar een opslagsysteem dat toegankelijk is vanuit de web-app en de app activeren om de ZIP uit de opslaglocatie op te halen.

De externe URL kan elke openbaar toegankelijke locatie zijn, maar u kunt het beste een blobopslagcontainer met een SAS-sleutel gebruiken om deze te beveiligen.

Gebruik de az webapp deploy opdracht zoals u in de andere secties zou doen, maar gebruik --src-url in plaats van --src-path. In het volgende voorbeeld wordt de --src-url parameter gebruikt om de URL op te geven van een ZIP-bestand dat wordt gehost in een Azure Storage-account.

az webapp deploy --resource-group <group-name> --name <app-name> --src-url "https://storagesample.blob.core.windows.net/sample-container/myapp.zip?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3 --type zip

Naslaginformatie over de Kudu-publicatie-API

Met publish de Kudu-API kunt u dezelfde parameters van de CLI-opdracht opgeven als URL-queryparameters. Als u wilt verifiëren met de Kudu REST API, kunt u het beste tokenverificatie gebruiken, maar u kunt ook basisverificatie gebruiken met de implementatiereferenties van uw app.

In de volgende tabel ziet u de beschikbare queryparameters, de toegestane waarden en beschrijvingen.

Sleutel Toegestane waarden Beschrijving Vereist Type
type war|jar|ear|lib|startup|static|zip Het type artefact dat wordt geïmplementeerd, stelt het standaarddoelpad in en informeert de web-app hoe de implementatie moet worden verwerkt.
- type=zip: Implementeer een ZIP-pakket door de inhoud op te heffen in /home/site/wwwroot. target-path parameter is optioneel.
- type=war: Implementeer een WAR-pakket. Standaard wordt het WAR-pakket geïmplementeerd in /home/site/wwwroot/app.war. Het doelpad kan worden opgegeven met target-path.
- type=jar: Implementeer een JAR-pakket in /home/site/wwwroot/app.jar. De target-path parameter wordt genegeerd
- type=ear: Implementeer een EAR-pakket in /home/site/wwwroot/app.ear. De target-path parameter wordt genegeerd
- type=lib: Implementeer een JAR-bibliotheekbestand. Standaard wordt het bestand geïmplementeerd in /home/site/libs. Het doelpad kan worden opgegeven met target-path.
- type=static: Implementeer een statisch bestand (zoals een script). Standaard wordt het bestand geïmplementeerd in /home/site/wwwroot.
- type=startup: Implementeer een script dat App Service automatisch gebruikt als het opstartscript voor uw app. Standaard wordt het script geïmplementeerd D:\home\site\scripts\<name-of-source> voor Windows en home/site/wwwroot/startup.sh voor Linux. Het doelpad kan worden opgegeven met target-path.
Ja String
restart true|false De API start de app standaard opnieuw op na de implementatiebewerking (restart=true). Als u meerdere artefacten wilt implementeren, voorkomt u dat alle artefacten opnieuw worden opgestart, maar de uiteindelijke implementatie door de instelling in te stellen restart=false. Nee Booleaanse waarde
clean true|false Hiermee geeft u op of de doelimplementatie moet worden opgeschoond (verwijderd) voordat het artefact daar wordt geïmplementeerd. Nee Booleaanse waarde
ignorestack true|false De publicatie-API maakt gebruik van de WEBSITE_STACK omgevingsvariabele om veilige standaardinstellingen te kiezen, afhankelijk van de taalstack van uw site. Als u deze parameter instelt om taalspecifieke standaardinstellingen uit te false schakelen. Nee Booleaanse waarde
target-path Een absoluut pad Het absolute pad naar de implementatie van het artefact. Bijvoorbeeld, "/home/site/deployments/tools/driver.jar". "/home/site/scripts/helper.sh" Nee String

Volgende stappen

Voor meer geavanceerde implementatiescenario's probeert u te implementeren in Azure met Git. Implementatie op basis van Git in Azure maakt versiebeheer, pakketherstel, MSBuild en meer mogelijk.

Meer resources