Bereitstellen von Dateien in App Service
Hinweis
Ab dem 1. Juni 2024 haben alle neu erstellten App Service-Apps die Möglichkeit, einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net
zu erstellen. Vorhandene App-Namen bleiben unverändert.
Beispiel: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Ausführlichere Informationen finden Sie unter Eindeutiger Standardhostname für App Service-Ressourcen.
In diesem Artikel erfahren Sie, wie Sie Ihren Code als ZIP-, WAR-, JAR- oder EAR-Paket für Azure App Service bereitstellen. Außerdem wird gezeigt, wie einzelne Dateien getrennt von Ihrem Anwendungspaket in App Service bereitgestellt werden.
Voraussetzungen
Um die Schritte in diesem Artikel durchzuführen, erstellen Sie eine App Service-App, oder verwenden Sie eine App, die Sie für ein anderes Tutorial erstellt haben.
Sollten Sie über kein Azure-Abonnement verfügen, können Sie zunächst ein kostenloses Azure-Konto erstellen.
Erstellen eines ZIP-Pakets für das Projekt
Wichtig
Schließen Sie beim Erstellen des ZIP-Pakets für die Bereitstellung nicht das Stammverzeichnis, sondern nur die darin enthaltenen Dateien und Verzeichnisse ein. Wenn Sie ein GitHub-Repository als ZIP-Datei herunterladen, können Sie diese Datei nicht unverändert in App Service bereitstellen. GitHub fügt auf der obersten Ebene zusätzliche geschachtelte Verzeichnisse hinzu, die nicht mit App Service funktionieren.
Navigieren Sie in einem lokalen Terminalfenster zum Stammverzeichnis Ihres App-Projekts.
Dieses Verzeichnis sollte die Eingabedatei für Ihre Web-App enthalten, z.B. index.html, index.php oder app.js. Sie kann auch Dateien zur Paketverwaltung enthalten, z.B. project.json, composer.json, package.json, bower.json oder requirements.txt.
Wenn Sie nicht möchten, dass App Service die Bereitstellungsautomatisierung für Sie ausführt, führen Sie alle Buildaufgaben (z. B. npm
, bower
, gulp
, composer
und pip
) aus, und stellen Sie sicher, dass Sie über alle Dateien verfügen, die Sie zum Ausführen der App benötigen. Dieser Schritt ist erforderlich, wenn Sie Ihr Paket direkt ausführen möchten.
Erstellen Sie ein ZIP-Archiv mit allen Elementen Ihres Projekts. Bei dotnet
-Projekten handelt es sich dabei um den gesamten Inhalt im Ausgabeverzeichnis des dotnet publish
-Befehls (mit Ausnahme des Ausgabeverzeichnisses selbst). Führen Sie beispielsweise den folgenden Befehl in Ihrem Terminal aus, um ein ZIP-Paket mit dem Inhalt des aktuellen Verzeichnisses zu erstellen:
# Bash
zip -r <file-name>.zip .
# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip
Bereitstellen eines ZIP-Pakets
Wenn Sie ein ZIP-Paket bereitstellen, entpackt App Service seinen Inhalt im Standardpfad für Ihre App (D:\home\site\wwwroot
für Windows, /home/site/wwwroot
für Linux).
Bei dieser Bereitstellung per ZIP-Paket wird der gleiche Kudu-Dienst verwendet, der auch bei der Continuous Integration-basierten Bereitstellungen zum Einsatz kommt. Kudu unterstützt die folgenden Funktionen für die Bereitstellung per ZIP-Paket:
- Löschen von Dateien aus einer vorherigen Bereitstellung
- Aktivieren des Standarderstellungsprozesses, der die Paketwiederherstellung umfasst
- Anpassen der Bereitstellung, einschließlich der Ausführung von Bereitstellungsskripts
- Bereitstellungsprotokolle
- Eine maximale Paketgröße von 2048 MB
Hinweis
Dateien im ZIP-Paket werden nur kopiert, wenn ihre Zeitstempel nicht mit dem übereinstimmen, was bereits bereitgestellt wurde.
Mit Benutzeroberfläche für ZIP-Bereitstellung in Kudu
Navigieren Sie im Browser zu https://<app_name>.scm.azurewebsites.net/ZipDeployUI
(siehe Hinweis oben).
Laden Sie das unter Erstellen eines ZIP-Pakets für das Projekt erstellte ZIP-Paket hoch, indem Sie sie auf der Webseite in den Bereich für den Datei-Explorer ziehen.
Wenn die Bereitstellung gerade ausgeführt wird, zeigt ein Symbol in der oberen rechten Ecke den Status in Prozent an. Auf der Seite werden darüber hinaus unterhalb des Explorer-Bereichs ausführliche Meldungen für den Vorgang angezeigt. Wenn die Bereitstellung abgeschlossen ist, sollte die letzte Meldung Deployment successful
lauten.
Der oben erwähnte Endpunkt funktioniert zurzeit nicht für App Services unter Linux. Verwenden Sie stattdessen FTP oder die ZIP Deploy-API.
Ohne Benutzeroberfläche für ZIP-Bereitstellung in Kudu
Stellen Sie mithilfe des Befehls az webapp deploy ein ZIP-Paket für Ihre Web-App bereit. Der CLI-Befehl verwendet die Kudu-Veröffentlichungs-API zum Bereitstellen der Dateien und kann vollständig angepasst werden.
Im folgenden Beispiel wird ein ZIP-Paket an Ihre Website gepusht. Geben Sie den Pfad zu Ihrem lokalen ZIP-Paket für --src-path
an.
az webapp deploy --resource-group <group-name> --name <app-name> --src-path <zip-package-path>
Mit diesem Befehl wird die App nach der Bereitstellung des ZIP-Pakets neu gestartet.
Aktivieren der Buildautomatisierung für die ZIP-Bereitstellung
Standardmäßig geht die Bereitstellungs-Engine davon aus, dass ein ZIP-Paket ohne weitere Maßnahmen ausführungsfähig ist, und führt deshalb auch keine Buildautomatisierung aus. Um dieselbe Buildautomatisierung wie bei einer Git-Bereitstellung zu aktivieren, legen Sie die App-Einstellung SCM_DO_BUILD_DURING_DEPLOYMENT
fest, indem Sie in den folgenden Befehl in Cloud Shell ausführen:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings SCM_DO_BUILD_DURING_DEPLOYMENT=true
Weitere Informationen finden Sie in der Kudu-Dokumentation.
Bereitstellen von WAR-/JAR-/EAR-Paketen
Sie können Ihr WAR-, JAR- oder EAR-Paket auf App Service bereitstellen, um Ihre Java-Web-App mithilfe der Azure CLI, PowerShell oder der Kudu-Veröffentlichungs-API auszuführen.
Der hier gezeigte Bereitstellungsprozess platziert das Paket unter Verwendung der richtigen Namenskonvention und Verzeichnisstruktur in der Inhaltsfreigabe der App (siehe Referenz zur Kudu-Veröffentlichungs-API) und stellt den empfohlenen Ansatz dar. Wenn Sie WAR/JAR/EAR-Pakete stattdessen über FTP oder WebDeploy bereitstellen, kann es aufgrund von Fehlern in der Namensgebung oder Struktur zu unbekannten Fehlern kommen.
Stellen Sie mithilfe des Befehls az webapp deploy ein WAR-Paket für Tomcat oder JBoss EAP bereit. Geben Sie den Pfad zu Ihrem lokalen Java-Paket für --src-path
an.
az webapp deploy --resource-group <group-name> --name <app-name> --src-path ./<package-name>.war
Der CLI-Befehl verwendet die Kudu-Veröffentlichungs-API zum Bereitstellen des Pakets und kann vollständig angepasst werden.
Bereitstellen einzelner Dateien
Stellen Sie ein Startskript, eine Bibliothek und eine statische Datei in Ihrer Web-App bereit, indem Sie den Befehl az webapp deploy mit dem --type
-Parameter verwenden.
Wenn Sie ein Startskript auf diese Weise bereitstellen, verwendet App Service automatisch Ihr Skript, um Ihre App zu starten.
Der CLI-Befehl verwendet die Kudu-Veröffentlichungs-API zum Bereitstellen der Dateien und kann vollständig angepasst werden.
Bereitstellen eines Startskripts
az webapp deploy --resource-group <group-name> --name <app-name> --src-path scripts/startup.sh --type=startup
Bereitstellen einer Bibliotheksdatei
az webapp deploy --resource-group <group-name> --name <app-name> --src-path driver.jar --type=lib
Bereitstellen einer statischen Datei
az webapp deploy --resource-group <group-name> --name <app-name> --src-path config.json --type=static
Bereitstellen in netzwerkgeschützten Apps
Je nach Netzwerkkonfiguration Ihrer Web-App kann der direkte Zugriff auf die App über Ihre Entwicklungsumgebung blockiert werden (siehe Bereitstellen an netzwerkgeschützten Standorten und Bereitstellen an netzwerkgeschützten Standorten, Teil 2). Anstatt das Paket oder die Datei direkt an die Web-App zu pushen, können Sie es bzw. sie in einem über die Web-App zugänglichen Speichersystem veröffentlichen und die App auslösen, um die ZIP-Datei aus dem Speicherort zu pullen.
Die Remote-URL kann ein beliebiger öffentlich zugänglicher Speicherort sein, aber es ist am besten, einen Blobspeichercontainer mit einem SAS-Schlüssel zu verwenden, um ihn zu schützen.
Verwenden Sie den Befehl az webapp deploy
wie in den anderen Abschnitten, verwenden Sie jedoch --src-url
anstelle von --src-path
. Im folgenden Beispiel wird der --src-url
-Parameter verwendet, um die URL einer ZIP-Datei anzugeben, die in einem Azure Storage-Konto gehostet wird.
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
Referenz zur Kudu-Veröffentlichungs-API
Mit der publish
Kudu-API können Sie die gleichen Parameter aus dem CLI-Befehl wie URL-Abfrageparameter angeben. Zur Authentifizierung bei der Kudu-REST-API wird am besten die Tokenauthentifizierung verwendet. Sie können aber auch die Standardauthentifizierung mit den Anmeldeinformationen für die Bereitstellung Ihrer App verwenden.
Die folgende Tabelle zeigt die verfügbaren Abfrageparameter, ihre zulässigen Werte und Beschreibungen.
Schlüssel | Zulässige Werte | BESCHREIBUNG | Erforderlich | type |
---|---|---|---|---|
type |
war |jar |ear |lib |startup |static |zip |
Der Typ des bereitgestellten Artefakts. Dadurch wird der Standardzielpfad festgelegt, und die Web-App wird darüber informiert, wie die Bereitstellung behandelt werden soll. - type=zip : Bereitstellen eines ZIP-Pakets durch Entzippen des Inhalts in /home/site/wwwroot Der Parameter target-path ist optional. - type=war : Bereitstellen eines WAR-Pakets Standardmäßig wird das WAR-Paket in /home/site/wwwroot/app.war bereitgestellt. Der Zielpfad kann mit target-path angegeben werden. - type=jar : Bereitstellen eines JAR-Pakets in /home/site/wwwroot/app.jar Der target-path -Parameter wird ignoriert. - type=ear : Bereitstellen eines EAR-Pakets in /home/site/wwwroot/app.ear Der target-path -Parameter wird ignoriert. - type=lib : Bereitstellen einer JAR-Bibliotheksdatei Standardmäßig wird die Datei in /home/site/libs bereitgestellt. Der Zielpfad kann mit target-path angegeben werden. - type=static : Bereitstellen einer statischen Datei (z. B. eines Skripts). Standardmäßig wird die Datei in /home/site/wwwroot bereitgestellt. - type=startup : Stellen Sie ein Skript bereit, das App Service automatisch als Startskript für Ihre App verwendet. Standardmäßig wird das Skript in D:\home\site\scripts\<name-of-source> für Windows und home/site/wwwroot/startup.sh für Linux bereitgestellt. Der Zielpfad kann mit target-path angegeben werden. |
Ja | String |
restart |
true |false |
Standardmäßig startet die API die App nach dem Bereitstellungsvorgang (restart=true ) neu. Um mehrere Artefakte bereitzustellen, verhindern Sie Neustarts für alle bis auf die endgültige Bereitstellung, indem Sie restart=false festlegen. |
Nein | Boolean |
clean |
true |false |
Gibt an, ob die Zielbereitstellung bereinigt (gelöscht) werden soll, bevor das Artefakt dort bereitgestellt wird | Nein | Boolean |
ignorestack |
true |false |
Die Veröffentlichungs-API verwendet die Umgebungsvariable WEBSITE_STACK , um je nach Sprachstapel Ihrer Website sichere Standardwerte zu wählen. Wenn Sie diesen Parameter auf false festlegen, werden alle sprachspezifischen Standardwerte deaktiviert. |
Nein | Boolean |
target-path |
Ein absoluter Pfad | Der absolute Pfad, in dem das Artefakt bereitgestellt werden soll Platzhalter in einer derartigen Schreibweise sind z.B. "/home/site/deployments/tools/driver.jar" und "/home/site/scripts/helper.sh" . |
Nein | String |
Nächste Schritte
Für komplexere Bereitstellungsszenarien versuchen Sie die Bereitstellung in Azure mit Git. Die Git-basierte Bereitstellung in Azure ermöglicht Versionskontrolle, Paketwiederherstellung, MSBuild und mehr.