Freigeben über

Konfigurieren einer PHP-App in Azure App Service

Warnung

PHP unter Windows hat im November 2022 das Ende des Supports erreicht. PHP wird nur für App Service unter Linux unterstützt. Dieser Artikel dient nur zu Informationszwecken.

In diesem Leitfaden erfahren Sie, wie Sie Ihre PHP-Web-Apps, mobilen Back-Ends und API-Apps in Azure App Service konfigurieren. Die gängigsten Konfigurationsaufgaben werden behandelt.

Wenn Sie noch nicht mit App Service vertraut sind, sollten Sie zunächst die Schnellstartanleitung zum Erstellen einer PHP-Web-App in Azure App Service und das Tutorial Bereitstellen einer PHP-, MySQL- und Redis-App in Azure App Service befolgen.

PHP-Version anzeigen

Um die aktuelle PHP-Version anzuzeigen, führen Sie den folgenden Befehl aus. Sie können Azure Cloud Shell verwenden:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query phpVersion

Ersetzen Sie <resource-group-name> und <app-name> durch Namen, die für Ihre Web-App geeignet sind.

Hinweis

Um einen Entwicklungsslot zu adressieren, fügen Sie den Parameter --slot gefolgt vom Namen des Slots ein.

Um alle unterstützten PHP-Versionen anzuzeigen, führen Sie den folgenden Befehl aus:

az webapp list-runtimes --os windows | grep PHP

In diesem Leitfaden erfahren Sie, wie Sie Ihre PHP-Web-Apps, mobilen Back-Ends und API-Apps in Azure App Service konfigurieren. Die gängigsten Konfigurationsaufgaben werden behandelt.

Wenn Sie noch nicht mit App Service vertraut sind, sollten Sie zunächst die Schnellstartanleitung zum Erstellen einer PHP-Web-App in Azure App Service und das Tutorial Bereitstellen einer PHP-, MySQL- und Redis-App in Azure App Service befolgen.

PHP-Version anzeigen

Um die aktuelle PHP-Version anzuzeigen, führen Sie den folgenden Befehl aus. Sie können Azure Cloud Shell verwenden.

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Ersetzen Sie <resource-group-name> und <app-name> durch Namen, die für Ihre Web-App geeignet sind.

Hinweis

Um einen Entwicklungsslot zu adressieren, fügen Sie den Parameter --slot gefolgt vom Namen des Slots ein.

Um alle unterstützten PHP-Versionen anzuzeigen, führen Sie den folgenden Befehl aus:

az webapp list-runtimes --os linux | grep PHP

PHP-Version festlegen

Um die PHP-Version auf 8.1 festzulegen, führen Sie den folgenden Befehl aus:

az webapp config set --resource-group <resource-group-name> --name <app-name> --php-version 8.1

Um die PHP-Version auf 8.1 festzulegen, führen Sie den folgenden Befehl aus:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PHP|8.1"

Was geschieht mit veralteten Laufzeiten in App Service?

Veraltete Laufzeiten werden von der Aufrechterhaltungsorganisation nicht mehr unterstützt oder festgestellt, dass erhebliche Sicherheitsrisiken auftreten. Dementsprechend werden sie aus dem Erstellen und Konfigurieren von Seiten im Portal entfernt. Wenn eine veraltete Laufzeit im Portal ausgeblendet ist, wird jede App, die diese Laufzeit verwendet, weiterhin ausgeführt.

Wenn Sie eine App mit einer veralteten Laufzeitversion erstellen möchten, die nicht mehr im Portal angezeigt wird, verwenden Sie die Azure CLI-, ARM-Vorlage oder Bicep. Mit diesen Bereitstellungsalternativen können Sie veraltete Laufzeiten erstellen, die im Portal entfernt wurden, aber weiterhin unterstützt werden.

Wenn eine Laufzeit vollständig von der App Service-Plattform entfernt wird, erhält Ihr Azure-Abonnementbesitzer vor dem Entfernen eine E-Mail-Benachrichtigung.

Composer ausführen

Wenn Sie möchten, dass App Service Composer zum Zeitpunkt der Bereitstellung ausführt, ist es am einfachsten, Composer in Ihr Repository einzuschließen.

Öffnen Sie ein lokales Terminalfenster und wechseln Sie in das Stammverzeichnis Ihres Repositorys. Folgen Sie dann den Anweisungen unter Herunterladen von Composer, um composer.phar in den Verzeichnisstamm herunterzuladen.

Führen Sie die folgenden Befehle aus. Um sie ausführen zu können, muss npm installiert sein.

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

Ihr Repository-Stammverzeichnis verfügt nun über zwei neue Dateien: .deployment und deploy.sh.

Öffnen Sie deploy.sh und finden Sie den Abschnitt Deployment, der wie dieses Beispiel aussieht.

##################################################################################################################################
# Deployment
# ----------

Fügen Sie am Ende des Deployment Abschnitts den Codeabschnitt hinzu, den Sie zum Ausführen des erforderlichen Tools benötigen:

# 4. Use composer
echo "$DEPLOYMENT_TARGET"
if [ -e "$DEPLOYMENT_TARGET/composer.json" ]; then
  echo "Found composer.json"
  pushd "$DEPLOYMENT_TARGET"
  php composer.phar install $COMPOSER_ARGS
  exitWithMessageOnError "Composer install failed"
  popd
fi

Schreiben Sie alle Ihre Änderungen fest, und stellen Sie Ihren Code mithilfe von Git oder ZIP-Deploy mit aktivierter Buildautomatisierung bereit. Composer sollte jetzt als Teil der Bereitstellungsautomatisierung ausgeführt werden.

Ausführen von Bower, Gulp oder Grunt

Wenn Sie möchten, dass App Service beliebte Automatisierungstools zum Zeitpunkt der Bereitstellung ausführt, z. B. Bower, Gulp oder Grunt, müssen Sie ein benutzerdefiniertes Bereitstellungsskript bereitstellen. App Service führt dieses Skript aus, wenn Sie die Bereitstellung mithilfe von Git oder ZIP Deploy mit aktivierter Buildautomatisierung durchführen.

Damit Ihr Repository diese Tools ausführen kann, müssen Sie sie den Abhängigkeiten in package.jsonhinzufügen. Beispiel:

"dependencies": {
  "bower": "^1.7.9",
  "grunt": "^1.0.1",
  "gulp": "^3.9.1",
  ...
}

Ändern Sie in einem lokalen Terminalfenster das Verzeichnis in Ihr Repository-Stammverzeichnis und führen Sie die folgenden Befehle aus. Um sie ausführen zu können, muss npm installiert sein.

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

Ihr Repository-Stammverzeichnis verfügt nun über zwei neue Dateien: .deployment und deploy.sh.

Öffnen Sie deploy.sh und finden Sie den Abschnitt Deployment, der wie dieses Beispiel aussieht.

##################################################################################################################################
# Deployment
# ----------

Dieser Abschnitt endet mit dem Ausführen von npm install --production. Fügen Sie am Ende des Deployment Abschnitts den Codeabschnitt hinzu, den Sie zum Ausführen des erforderlichen Tools benötigen:

Weitere Informationen finden Sie in einem Beispiel im der MEAN.js-Beispiel, in dem das Bereitstellungsskript auch einen benutzerdefinierten npm install-Befehl ausführt.

Laube

Dieses Snippet lautet :bower install

if [ -e "$DEPLOYMENT_TARGET/bower.json" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/bower install
  exitWithMessageOnError "bower failed"
  cd - > /dev/null
fi

Schluck

Dieses Snippet lautet :gulp imagemin

if [ -e "$DEPLOYMENT_TARGET/gulpfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/gulp imagemin
  exitWithMessageOnError "gulp failed"
  cd - > /dev/null
fi

Grunzen

Dieses Snippet lautet :grunt

if [ -e "$DEPLOYMENT_TARGET/Gruntfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/grunt
  exitWithMessageOnError "Grunt failed"
  cd - > /dev/null
fi

Anpassen der Buildautomatisierung

Wenn Sie Ihre App mithilfe von Git oder ZIP-Paketen mit aktivierter Buildautomatisierung bereitstellen, durchläuft die Buildautomatisierung in App Service die folgende Reihenfolge:

  1. Führen Sie ein benutzerdefiniertes Skript aus, wenn PRE_BUILD_SCRIPT_PATH es angibt.
  2. Führen Sie php composer.phar install aus.
  3. Führen Sie ein benutzerdefiniertes Skript aus, wenn POST_BUILD_SCRIPT_PATH es angibt.

PRE_BUILD_COMMAND und POST_BUILD_COMMAND sind Umgebungsvariablen, die standardmäßig leer sind. Um vordefinierte Befehle auszuführen, definieren Sie PRE_BUILD_COMMAND. Um Postbuildbefehle auszuführen, definieren Sie POST_BUILD_COMMAND.

Im folgenden Beispiel werden die beiden Variablen für eine Reihe von Befehlen angegeben, die durch Kommas getrennt sind:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Weitere Umgebungsvariablen zum Anpassen der Buildautomatisierung finden Sie unter Oryx-Konfiguration.

Informationen zum Ausführen und Erstellen von PHP-Apps unter Linux finden Sie in der Oryx-Dokumentation zum Erkennen und Erstellen von PHP-Apps.

Anpassen des Startvorgangs

Sie können einen benutzerdefinierten Befehl beim Start des Containers ausführen. Führen Sie den folgenden Befehl aus:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

Zugreifen auf Umgebungsvariablen

In App Service können Sie App-Einstellungen außerhalb Ihres App-Codes festlegen. Sie können dann auf diese Einstellungen zugreifen, indem Sie das Standardmuster getenv() verwenden. Verwenden Sie beispielsweise den folgenden Code, um auf eine App-Einstellung namens DB_HOST zuzugreifen:

getenv("DB_HOST")

Stammverzeichnis der Site

Das Webframework Ihrer Wahl kann ein Unterverzeichnis als Site-Stammverzeichnis verwenden. Laravel verwendet beispielsweise das public/ Unterverzeichnis als Site-Stammverzeichnis.

Um den Websitestamm anzupassen, legen Sie den virtuellen Anwendungspfad für die App mithilfe des az resource update Befehls fest. Im folgenden Beispiel wird das Stammverzeichnis der Website auf das Unterverzeichnis public/ in Ihrem Repository festgelegt:

az resource update --name web --resource-group <group-name> --namespace Microsoft.Web --resource-type config --parent sites/<app-name> --set properties.virtualApplications[0].physicalPath="site\wwwroot\public" --api-version 2015-06-01

Standardmäßig verweist Azure App Service den Pfad der virtuellen Stammanwendung (/) auf das Stammverzeichnis der bereitgestellten Anwendungsdateien (sites\wwwroot).

Das Webframework Ihrer Wahl kann ein Unterverzeichnis als Site-Stammverzeichnis verwenden. Laravel verwendet beispielsweise das public/ Unterverzeichnis als Site-Stammverzeichnis.

Das PHP-Standardimage für App Service verwendet NGINX, und Sie ändern den Stamm der Website, indem Sie den NGINX-Server mit der root Anweisung konfigurieren. Diese Beispielkonfigurationsdatei enthält den folgenden Codeausschnitt, der die root Direktive ändert:

server {
    #proxy_cache cache;
    #proxy_cache_valid 200 1s;
    listen 8080;
    listen [::]:8080;
    root /home/site/wwwroot/public; # Changed for Laravel

    location / {            
        index  index.php index.html index.htm hostingstart.html;
        try_files $uri $uri/ /index.php?$args; # Changed for Laravel
    }
    ...

Der Standardcontainer verwendet die Konfigurationsdatei unter /etc/nginx/sites-available/default. Alle Änderungen, die Sie an dieser Datei vornehmen, werden gelöscht, wenn die App neu gestartet wird. Um eine Änderung vorzunehmen, die bei allen App-Neustarts wirksam ist, fügen Sie einen benutzerdefinierten Startbefehl wie im folgenden Beispiel hinzu:

cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload

Mit diesem Befehl wird die standardmäßige NGINX-Konfigurationsdatei durch eine Datei ersetzt, die in Ihrem Repository-Stammverzeichnis benannt default ist, und NGINX wird neu gestartet.

Erkennen einer HTTPS-Sitzung

In App Service erfolgt die TLS/SSL-Terminierung in den Modulen für den Netzwerklastenausgleich, sodass alle HTTPS-Anforderungen Ihre App als unverschlüsselte HTTP-Anforderungen erreichen. Wenn Ihre App-Logik überprüfen muss, ob die Benutzeranforderungen verschlüsselt sind, überprüfen Sie den X-Forwarded-Proto Header:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
// Do something when HTTPS is used
}

Gängige Webframeworks ermöglichen den Zugriff auf die Information X-Forwarded-* in Ihrem App-Standardmuster. In CodeIgniter überprüft die Funktion is_https() standardmäßig den Wert von X_FORWARDED_PROTO .

Einstellungen von php.ini anpassen

Wenn Sie Änderungen an Ihrer PHP-Installation vornehmen müssen, können Sie eine der php.ini Direktiven ändern, indem Sie die folgenden Schritte ausführen.

Hinweis

Der beste Weg, um die PHP-Version und die aktuelle php.ini Konfiguration zu sehen, besteht darin, phpinfo() in Ihrer App aufzurufen.

Anpassen von Nicht-PHP_INI_SYSTEM-Anweisungen

Fügen Sie zum Anpassen der PHP_INI_USER, PHP_INI_PERDIR und PHP_INI_ALL-Direktiven dem Stammverzeichnis Ihrer App eine .user.ini-Datei hinzu.

Fügen Sie der .user.ini Datei Konfigurationseinstellungen hinzu, indem Sie die gleiche Syntax verwenden, die Sie auch in einer php.ini Datei verwenden würden. Wenn Sie z. B. die display_errors Einstellung aktivieren und die upload_max_filesize Einstellung auf 10M festlegen möchten, enthält die .user.ini-Datei diesen Text:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

 ; Write errors to d:\home\LogFiles\php_errors.log
 ; log_errors=On

Stellen Sie Ihre App mit den Änderungen erneut bereit, und starten Sie sie neu.

Als Alternative zur Verwendung einer .user.ini-Datei können Sie ini_set() in Ihrer App verwenden, um diese nicht-PHP_INI_SYSTEM-Befehle anzupassen.

Verwenden Sie zum Anpassen von PHP_INI_USER, PHP_INI_PERDIR und PHP_INI_ALL-Direktiven für Linux-Web-Apps, wie upload_max_filesize und expose_php, eine benutzerdefinierte .ini-Datei. Sie können es in einer SSH-Sitzung erstellen. Richten Sie zunächst das Verzeichnis ein:

  1. Rufen Sie Ihre Kudu-Website auf. Um die zufälligen Hash- und Regionswerte abzurufen, kopieren Sie in der App-Übersichtdie Standarddomäne.
  2. Wählen Sie im oberen Menü Debugkonsole und dann Bash oder SSH aus.
  3. Wechseln Sie in Bash oder SSH zu Ihrem /home/site/wwwroot Verzeichnis.
  4. Erstellen Sie ein Verzeichnis mit dem Namen ini (z. B mkdir ini. ).
  5. Ändern Sie das aktuelle Arbeitsverzeichnis in den von Ihnen erstellten Ordner ini.

Erstellen Sie als Nächstes eine .ini Datei, in der Sie Ihre Einstellungen hinzufügen. In diesem Beispiel wird extensions.iniverwendet. Es gibt keine Datei-Editoren wie Vi, Vim oder Nano. Verwenden Sie also Echo, um die Einstellungen zur Datei hinzuzufügen. Ändern Sie den Wert von upload_max_filesize von 2M in 50M. Verwenden Sie den folgenden Befehl, um die Einstellung hinzuzufügen und eine extensions.ini Datei zu erstellen, falls noch keine vorhanden ist:

/home/site/wwwroot/ini>echo "upload_max_filesize=50M" >> extensions.ini
/home/site/wwwroot/ini>cat extensions.ini

upload_max_filesize=50M

/home/site/wwwroot/ini>

Fügen Sie im Azure-Portal eine Anwendungseinstellung hinzu, um das ini soeben erstellte Verzeichnis zu überprüfen, um die Änderung für upload_max_filesizezu übernehmen:

  1. Wechseln Sie zum Azure-Portal , und wählen Sie Ihre App Service Linux-PHP-Anwendung aus.
  2. Gehen Sie zu Einstellungen>Umgebungsvariablen.
  3. Klicken Sie auf + Hinzufügen.
  4. Geben Sie als NamePHP_INI_SCAN_DIR und als Wert den Wert ein :/home/site/wwwroot/ini.
  5. Wählen Sie Anwenden und dann erneut Anwenden aus . Bestätigen Sie Ihre Änderungen.

Hinweis

Wenn Sie eine PHP-Erweiterung, wie z. B. GD, neu kompiliert haben, führen Sie die Schritte unter Neukompilieren von PHP-Erweiterungen aus.

PHP_INI_SYSTEM-Anweisungen anpassen

Um PHP_INI_SYSTEM Direktiven anzupassen, verwenden Sie die PHP_INI_SCAN_DIR App-Einstellung.

Führen Sie zunächst den folgenden Befehl aus, um eine App-Einstellung mit dem Namen PHP_INI_SCAN_DIRhinzuzufügen:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="d:\home\site\ini"

Wählen Sie im Azure-Portal Ihre App aus. Wählen Sie im Menü der Seitenleiste unter EntwicklungstoolsErweiterte Tools aus und wechseln Sie dann zu d:\home\site mit SSH.

Erstellen Sie ein Verzeichnis in d:\home\site namens ini. Erstellen Sie dann eine .ini Datei in dem d:\home\site\ini Verzeichnis, settings.iniz. B. mit den Anweisungen, die Sie anpassen möchten. Verwenden Sie die gleiche Syntax, die Sie auch in einer php.ini Datei verwenden würden.

Führen Sie beispielsweise die folgenden Befehle aus, um den Wert von expose_phpzu ändern:

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

Damit die Änderungen wirksam werden, starten Sie die App neu.

Um Direktiven anzupassen PHP_INI_SYSTEM , können Sie den .htaccess-Ansatz nicht verwenden. App Service stellt einen separaten Mechanismus bereit, der die PHP_INI_SCAN_DIR App-Einstellung verwendet.

Führen Sie zunächst den folgenden Befehl aus, um eine App-Einstellung mit dem Namen PHP_INI_SCAN_DIRhinzuzufügen:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="/usr/local/etc/php/conf.d:/home/site/ini"

Der Wert /usr/local/etc/php/conf.d ist das Standardverzeichnis, in dem php.ini existiert. Der Wert /home/site/ini ist das benutzerdefinierte Verzeichnis, in dem Sie eine benutzerdefinierte .ini Datei hinzufügen. Sie trennen die Werte durch einen Doppelpunkt (:).

Wechseln Sie zur Web-SSH-Sitzung mit Ihrem Linux-Container.

Erstellen Sie ein Verzeichnis in /home/site namens ini. Erstellen Sie dann eine .ini Datei in dem /home/site/ini Verzeichnis, settings.iniz. B. mit den Anweisungen, die Sie anpassen möchten. Verwenden Sie die gleiche Syntax, die Sie auch in einer php.ini Datei verwenden würden.

Tipp

In den integrierten Linux-Containern in App Service wird /home als persistenter freigegebener Speicher verwendet.

Führen Sie beispielsweise die folgenden Befehle aus, um den Wert von expose_phpzu ändern:

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

Damit die Änderungen wirksam werden, starten Sie die App neu.

PHP-Erweiterungen aktivieren

Die eingebauten PHP-Installationen enthalten die am häufigsten verwendeten Erweiterungen. Sie können weitere Erweiterungen auf die gleiche Weise aktivieren, wie Sie php.ini Direktiven anpassen.

Hinweis

Der beste Weg, um die PHP-Version und die aktuelle php.ini Konfiguration zu sehen, besteht darin, phpinfo() in Ihrer App aufzurufen.

Führen Sie die folgenden Schritte aus, um andere Erweiterungen zu aktivieren:

  1. Fügen Sie dem Stammverzeichnis Ihrer App ein bin Verzeichnis hinzu, und fügen Sie die .dll Erweiterungsdateien darin ab, mongodb.dllz. B. . . Stellen Sie sicher, dass die Erweiterungen mit der PHP-Version in Azure kompatibel sind und dass sie VC9- und Non-Thread-Safe (NTS)-kompatibel sind.

  2. Implementieren Sie Ihre Änderungen.

  3. Befolgen Sie die Schritte in Anpassen von PHP_INI_SYSTEM-Anweisungen, und fügen Sie die Erweiterungen in der benutzerdefinierten INI-Datei mit den Anweisungen extension oder zend_extension hinzu:

    extension=d:\home\site\wwwroot\bin\mongodb.dll
zend_extension=d:\home\site\wwwroot\bin\xdebug.dll

Damit die Änderungen wirksam werden, starten Sie die App neu.

Die eingebauten PHP-Installationen enthalten die am häufigsten verwendeten Erweiterungen. Sie können weitere Erweiterungen auf die gleiche Weise aktivieren, wie Sie php.ini Direktiven anpassen.

Hinweis

Der beste Weg, um die PHP-Version und die aktuelle php.ini Konfiguration zu sehen, besteht darin, phpinfo() in Ihrer App aufzurufen.

Führen Sie die folgenden Schritte aus, um andere Erweiterungen zu aktivieren:

  1. Fügen Sie dem Stammverzeichnis Ihrer App ein bin Verzeichnis hinzu, und fügen Sie die Dateien mit der Erweiterung .so darin ab (z. B mongodb.so. ). Stellen Sie sicher, dass die Erweiterungen mit der PHP-Version in Azure kompatibel sind und dass sie VC9- und Non-Thread-Safe (NTS)-kompatibel sind.

  2. Implementieren Sie Ihre Änderungen.

  3. Befolgen Sie die Schritte in Anpassen von PHP_INI_SYSTEM-Anweisungen, und fügen Sie die Erweiterungen in der benutzerdefinierten INI-Datei mit den Anweisungen extension oder zend_extension hinzu:

    extension=/home/site/wwwroot/bin/mongodb.so
zend_extension=/home/site/wwwroot/bin/xdebug.so

Damit die Änderungen wirksam werden, starten Sie die App neu.

Zugreifen auf Diagnoseprotokolle

Verwenden Sie das Standardtool error_log() , damit Ihre Diagnoseprotokolle in Azure App Service angezeigt werden.

Um auf die Konsolenprotokolle zuzugreifen, die aus Ihrem Anwendungscode in App Service generiert wurden, aktivieren Sie die Diagnoseprotokollierung, indem Sie den folgenden Befehl in Cloud Shell ausführen:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Mögliche Werte für --level sind Error, Warning, Info und Verbose. Jede nachfolgende Ebene enthält die vorherige Ebene. Enthält z. B. Error nur Fehlermeldungen. Verbose enthält alle Nachrichten.

Führen Sie nach dem Aktivieren der Diagnoseprotokollierung den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Wenn Konsolenprotokolle nicht sofort angezeigt werden, überprüfen Sie es in 30 Sekunden erneut.

Wenn Sie das Protokollstreaming jederzeit beenden möchten, wählen Sie STRG+C aus.

Sie können auf die Konsolenprotokolle zugreifen, die aus dem Container generiert werden.

Führen Sie den folgenden Befehl aus, um die Containerprotokollierung zu aktivieren:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Ersetzen Sie <app-name> und <resource-group-name> durch Namen, die für Ihre Web-App geeignet sind.

Nachdem Sie die Containerprotokollierung aktiviert haben, führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Wenn Konsolenprotokolle nicht sofort angezeigt werden, überprüfen Sie es in 30 Sekunden erneut.

Wenn Sie das Protokollstreaming jederzeit beenden möchten, wählen Sie STRG+C aus.

Fehlersuche

Wenn sich eine funktionierende PHP-App in App Service anders verhält oder Fehler aufweist, versuchen Sie die folgenden Lösungen:

  • Greifen Sie auf den Diagnoseprotokollstream zu.
  • Testen Sie die App lokal im Produktionsmodus. App Service führt die App im Produktionsmodus aus, daher müssen Sie sicherstellen, dass das Projekt im lokalen Produktionsmodus wie erwartet funktioniert. Beispiel:
    • Abhängig von Ihrer Datei composer.json können verschiedene Pakete für den Produktionsmodus installiert werden (require oder require-dev).
    • Bestimmte Webframeworks können statische Dateien im Produktionsmodus unterschiedlich bereitstellen.
    • Bestimmte Webframeworks können benutzerdefinierte Startskripts verwenden, wenn sie im Produktionsmodus ausgeführt werden.
  • Führen Sie Ihre App in App Service im Debugmodus aus. In Laravel können Sie Ihre App z. B. so konfigurieren, dass Debugmeldungen in der Produktion ausgegeben werden, indem Sie die APP_DEBUG App-Einstellung auf truefestlegen.

Ignorieren Sie die Bots933456-Nachricht in Protokollen

Möglicherweise wird die folgende Meldung in den Containerprotokollen angezeigt:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Diese Meldung können Sie problemlos ignorieren. /robots933456.txt ist ein Dummy-URL-Pfad, den App Service verwendet, um zu überprüfen, ob der Container in der Lage ist, Anforderungen zu verarbeiten. Eine 404-Antwort gibt an, dass der Pfad nicht vorhanden ist, und signalisiert dem App-Dienst, dass der Container fehlerfrei ist und bereit ist, auf Anforderungen zu reagieren.

Verwandte Inhalte