Bereitstellen von Dateien in App Service

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

Hinweis

Wenn Sie die Dateien in einem ZIP-Paket heruntergeladen haben, extrahieren Sie sie zunächst. Wenn Sie z. B. ein ZIP-Paket von GitHub heruntergeladen haben, können Sie diese Datei nicht unverändert bereitstellen. GitHub fügt zusätzliche geschachtelte Verzeichnisse hinzu, die in App Service nicht 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 ist dieser Ordner der Ausgabeordner des dotnet publish-Befehls. Mit dem folgenden Befehl wird das Standardtool in Ihrem Terminal verwendet:

# 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

Weitere Informationen finden Sie in der Kudu-Dokumentation.

Hinweis

Dateien im ZIP-Paket werden nur kopiert, wenn ihre Zeitstempel nicht mit dem übereinstimmen, was bereits bereitgestellt wurde. Das Erstellen einer ZIP-Datei mit einem Buildprozess, der Ausgaben zwischenspeichert, kann Bereitstellungen beschleunigen. Weitere Informationen finden Sie unter Deploying from a zip file or url (Bereitstellen über eine ZIP-Datei oder URL).

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.

Abhängig von der Netzwerkkonfiguration Ihrer Web-Apps kann der direkte Zugriff von Ihrer lokalen Umgebung aus auf die Website blockiert werden. Um Ihren Code in diesem Szenario bereitzustellen, können Sie Ihre ZIP-Datei in einem Speichersystem veröffentlichen, das über die Web-App zugänglich ist. Anschließend können Sie die App auslösen, um die ZIP-Datei per Pull aus dem Speicherort abzurufen, statt sie per Push in die Web-App zu übertragen. Weitere Informationen zur Bereitstellung für im Netzwerk geschützte Web-Apps finden Sie in diesem Artikel.

Im folgenden Beispiel wird der --src-url-Parameter verwendet, um die URL eines Azure Storage Kontos anzugeben, aus dem die Website das ZIP-Paket pullen soll.

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

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.

Was geschieht während der Bereitstellung mit meiner App?

Alle offiziell unterstützten Bereitstellungsmethoden nehmen Änderungen an den Dateien im Ordner /home/site/wwwroot Ihrer App vor. Diese Dateien werden zum Ausführen Ihrer App verwendet. Daher kann die Bereitstellung aufgrund gesperrter Dateien fehlschlagen. Die App kann sich während der Bereitstellung unvorhersehbar verhalten, da nicht alle Dateien gleichzeitig aktualisiert werden. Dieses Verhalten ist bei kundenorientierten Apps nicht erwünscht. Es gibt mehrere Möglichkeiten zum Umgehen dieser Probleme:

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.

Beim Bereitstellungsprozess wird das Paket ordnungsgemäß auf dem freigegebenen Dateilaufwerk platziert (siehe Referenz zur Kudu-Veröffentlichungs-API). Aus diesem Grund wird die Bereitstellung von WAR-/JAR-/EAR-Paketen über FTP oder WebDeploy nicht empfohlen.

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

Abhängig von der Netzwerkkonfiguration Ihrer Web-Apps kann der direkte Zugriff von Ihrer lokalen Umgebung aus auf die Website blockiert werden. Um Ihren Code in diesem Szenario bereitzustellen, können Sie Ihre ZIP-Datei in einem Speichersystem veröffentlichen, das über die Web-App zugänglich ist. Anschließend können Sie die App auslösen, um die ZIP-Datei per Pull aus dem Speicherort abzurufen, statt sie per Push in die Web-App zu übertragen. Weitere Informationen zur Bereitstellung für im Netzwerk geschützte Web-Apps finden Sie in diesem Artikel.

Im folgenden Beispiel wird der --src-url-Parameter verwendet, um die URL eines Azure Storage Kontos anzugeben, aus dem die Web-App das ZIP-Paket pullen soll.

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

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

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. Für die Authentifizierung mit der Kudu-API können Sie 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.

Key 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 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 path angegeben werden.
- type=jar: Bereitstellen eines JAR-Pakets in /home/site/wwwroot/app.jar Der path-Parameter wird ignoriert.
- type=ear: Bereitstellen eines EAR-Pakets in /home/site/wwwroot/app.ear Der path-Parameter wird ignoriert.
- type=lib: Bereitstellen einer JAR-Bibliotheksdatei Standardmäßig wird die Datei in /home/site/libs bereitgestellt. Der Zielpfad kann mit 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 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
path "<absolute-path>" 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.

Weitere Ressourcen