Teilen über

Konfigurieren einer PHP-App für Azure App Service

  • Artikel

Anzeigen der PHP-Version

Warnung

PHP auf Windows hat im November 2022 das Ende seiner Lebensdauer erreicht und wird nur noch von App Service auf Linux unterstützt. Dieser Artikel dient nur zu Informationszwecken.erforderlich.

In diesem Leitfaden erfahren Sie, wie Sie Ihre PHP-Web-Apps, mobilen Back-Ends und API-Apps in Azure App Service konfigurieren.

Dieser Leitfaden enthält die wichtigsten Konzepte und Anweisungen für PHP-Entwickler, die Apps in App Service bereitstellen. Wenn Sie Azure App Service noch nie verwendet haben, befolgen Sie zunächst den PHP-Schnellstart und das Tutorial zu PHP mit MySQL.

Führen Sie in Cloud Shell den folgenden Befehl aus, um die aktuelle PHP-Version anzuzeigen:

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

Hinweis

Um einen Entwicklungsslot zu adressieren, fügen Sie den Parameter --slot und anschließend den Namen des Slots hinzu.

Führen Sie in Cloud Shell den folgenden Befehl aus, um alle unterstützten PHP-Versionen anzuzeigen:

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.

Dieser Leitfaden enthält die wichtigsten Konzepte und Anweisungen für PHP-Entwickler, die Apps in App Service bereitstellen. Wenn Sie Azure App Service noch nie verwendet haben, befolgen Sie zunächst den PHP-Schnellstart und das Tutorial zu PHP mit MySQL.

Führen Sie in Cloud Shell den folgenden Befehl aus, um die aktuelle PHP-Version anzuzeigen:

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

Hinweis

Um einen Entwicklungsslot zu adressieren, fügen Sie den Parameter --slot und anschließend den Namen des Slots hinzu.

Führen Sie in Cloud Shell den folgenden Befehl aus, um alle unterstützten PHP-Versionen anzuzeigen:

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

Festlegen der PHP-Version

Führen Sie in Cloud Shell den folgenden Befehl aus, um die PHP-Version auf 8.1 festzulegen:

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

Führen Sie in Cloud Shell den folgenden Befehl aus, um die PHP-Version auf 8.1 festzulegen:

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

Ausführen von Composer

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

Wechseln Sie in einem lokalen Terminalfenster zum Stammverzeichnis Ihres Repositorys, und folgen Sie den Anweisungen unter Composer herunterladen, um composer.phar in das Stammverzeichnis herunterzuladen.

Führen Sie die folgenden Befehle aus (wofür npm installiert sein muss):

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

Das Stammverzeichnis Ihres Repositorys enthält jetzt zwei zusätzliche Dateien: .deployment und deploy.sh.

Öffnen Sie deploy.sh und suchen Sie den Abschnitt Deployment, der wie folgt aussieht:

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

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

# 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

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

Run Grunt/Bower/Gulp

Wenn App Service zum Bereitstellungszeitpunkt eines der beliebten Automationstools wie Grunt, Bower oder Gulp ausführen soll, müssen Sie ein benutzerdefiniertes Bereitstellungsskript angeben. App Service führt dieses Skript bei der Git- oder ZIP-Bereitstellung mit aktivierter Buildautomatisierung aus.

Damit Ihr Repository diese Tools ausführen kann, müssen Sie sie zu den Abhängigkeiten in package.json hinzufügen.

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

Wechseln Sie in einem lokalen Terminalfenster zum Stammverzeichnis Ihres Repositorys, und führen Sie die folgenden Befehle aus (wofür npm installiert sein muss):

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

Das Stammverzeichnis Ihres Repositorys enthält jetzt zwei zusätzliche Dateien: .deployment und deploy.sh.

Öffnen Sie deploy.sh und suchen Sie den Abschnitt Deployment, der wie folgt aussieht:

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

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

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

Bower

Dieser Codeausschnitt führt bower install aus.

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

Gulp

Dieser Codeausschnitt führt gulp imagemin aus.

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

Grunt

Dieser Codeausschnitt führt grunt aus.

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 mit ZIP-Paketen mit aktivierter Buildautomatisierung bereitstellen, durchläuft die App Service-Buildautomatisierung die Schritte der folgenden Sequenz:

  1. Ausführen eines benutzerdefinierten Skripts, falls durch PRE_BUILD_SCRIPT_PATH angegeben
  2. Führen Sie php composer.phar install aus.
  3. Ausführen eines benutzerdefinierten Skripts, falls mittels POST_BUILD_SCRIPT_PATH angegeben.

PRE_BUILD_COMMAND und POST_BUILD_COMMAND sind Umgebungsvariablen, die standardmäßig leer sind. Um Präbuildbefehle 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.

Weitere Informationen, wie App Service PHP-Apps in Linux ausführt und erstellt, finden Sie unter Oryx-Dokumentation: Erkennen und Erstellen von PHP-Apps.

Anpassen des Startvorgangs

Wenn Sie möchten, können Sie beim Start des Containers einen benutzerdefinierten Befehl ausführen, indem Sie den folgenden Befehl in der Cloud Shell ausführen:

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. Anschließend können Sie darauf unter Verwendung des Standardmusters getenv() zugreifen. Verwenden Sie beispielsweise den folgenden Code, um auf eine App-Einstellung namens DB_HOST zuzugreifen:

getenv("DB_HOST")

Ändern des Sitestammverzeichnisses

Das Webframework Ihrer Wahl verwendet möglicherweise ein Unterverzeichnis als Stammverzeichnis der Site. Beispielsweise verwendet Laravel das Unterverzeichnis public/ als Stammverzeichnis der Website.

Um das Stammverzeichnis der Website anzupassen, legen Sie den virtuellen Anwendungspfad für die App mit dem Befehl az resource update 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 im Stammverzeichnis des virtuellen Anwendungspfads ( / ) auf das Stammverzeichnis der bereitgestellten Anwendungsdateien (/).

Das Webframework Ihrer Wahl verwendet möglicherweise ein Unterverzeichnis als Stammverzeichnis der Site. Laravel verwendet beispielsweise das Unterverzeichnis public/ als Stammverzeichnis der Site.

Das PHP-Standardimage für App Service verwendet Nginx, und Sie ändern den Standortstamm, indem Sie den Nginx-Server mit der root-Anweisung konfigurieren. Diese Beispielkonfigurationsdatei enthält die folgenden Codeausschnitte, die die root-Anweisung ändern:

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. Beachten Sie, dass alle Änderungen, die Sie an dieser Datei vornehmen, beim Neustart der App gelöscht werden. Um eine Änderung vorzunehmen, die beim Neustart der App wirksam ist, fügen Sie einen benutzerdefinierten Startbefehl wie in diesem Beispiel hinzu:

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

Dieser Befehl ersetzt die Nginx-Standardkonfigurationsdatei durch eine Datei namens default (Standard) in Ihrem Repositorystamm und startet Nginx neu.

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 Benutzeranforderungen verschlüsselt sind, können Sie dazu den Header X-Forwarded-Proto untersuchen.

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 is_https() standardmäßig den Wert von X_FORWARDED_PROTO.

Anpassen der „php.ini“-Einstellungen

Wenn Sie Änderungen an Ihrer PHP-Installation vornehmen müssen, können Sie jede der php.ini-Anweisungen mit folgenden Schritten ändern.

Hinweis

Die beste Möglichkeit zum Anzeigen der PHP-Version und der aktuellen php.ini-Konfiguration besteht darin, phpinfo() in Ihrer App aufzurufen.

Anpassen von Nicht-PHP_INI_SYSTEM-Anweisungen

Zum Anpassen der Anweisungen PHP_INI_USER PHP_INI_PERDIR und PHP_INI_ALL (siehe php.ini-Anweisungen), fügen Sie dem Stammverzeichnis Ihrer App eine .user.ini-Datei hinzu.

Fügen Sie der Datei .user.ini die Konfigurationseinstellungen hinzu, und verwenden Sie dieselbe Syntax wie für eine php.ini-Datei. Wenn Sie zum Beispiel die Einstellung display_errors aktivieren und die Einstellung upload_max_filesize auf 10 M festlegen möchten, enthält die Datei .user.ini 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-Anweisungen anzupassen.

Verwenden Sie eine benutzerdefinierte „ini“-Datei, um PHP_INI_USER-, PHP_INI_PERDIR- und PHP_INI_ALL-Anweisungen für Linux-Web-Apps wie „upload_max_filesize“ und „expose_php“ anzupassen. Sie können sie in einer SSH-Sitzung erstellen.

  1. Wechseln Sie zu Ihrer KUDU-Website „https://<Sitename>.scm.azurewebsites.net“.
  2. Wählen Sie im oberen Menü „Bash“ oder „SSH“ aus.
  3. Navigieren Sie in Bash/SSH zu Ihrem Verzeichnis „/home/site/wwwroot“.
  4. Erstellen Sie ein Verzeichnis namens „ini“ (z. B. „mkdir ini“).
  5. Machen Sie den gerade erstellten Ordner „ini“ zum aktuellen Arbeitsverzeichnis.

Sie müssen eine „ini“-Datei erstellen, um dieser Ihre Einstellungen hinzuzufügen. In diesem Beispiel verwenden wir „extensions.ini“. Es gibt keine Datei-Editoren wie Vi, Vim oder Nano, sodass Sie „echo“ verwenden, um die Einstellungen zur Datei hinzuzufügen. Ändern Sie die „upload_max_filesize“ von 2 M in 50 M. 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>

Wechseln Sie dann zum Azure-Portal, und fügen Sie eine Anwendungseinstellung hinzu, um das soeben erstellte Verzeichnis „ini“ zu überprüfen, um die Änderung von „upload_max_filesize“ anzuwenden.

  1. Wechseln Sie zum Azure-Portal, und wählen Sie Ihre App Service Linux PHP-Anwendung aus.
  2. Wählen Sie „Anwendungseinstellungen“ für die App aus.
  3. Wählen Sie im Abschnitt „Anwendungseinstellungen“ die Option + Neue Einstellung hinzufügen aus.
  4. Geben Sie als Namen der App-Einstellung „PHP_INI_SCAN_DIR“ und als Wert „/home/site/wwwroot/ini“ ein.
  5. Wählen Sie die Schaltfläche „Speichern“ aus.

Hinweis

Wenn Sie eine PHP-Erweiterung wie GD neu kompiliert haben, führen Sie die Schritte unter Erneutes Kompilieren von PHP-Erweiterungen im Azure App Service – Hinzufügen von PHP-Erweiterungen aus.

Anpassen von PHP_INI_SYSTEM-Anweisungen

Zum Anpassen von PHP_INI_SYSTEM-Anweisungen (siehe php.ini-Anweisungen) können Sie die App-Einstellung „PHP_INI_SCAN_DIR“ verwenden.

Führen Sie als Erstes den folgenden Befehl in der Cloud Shell aus, um eine App-Einstellung namens PHP_INI_SCAN_DIR hinzuzufügen:

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

Navigieren Sie zur Kudu-Konsole (https://<app-name>.scm.azurewebsites.net/DebugConsole) und zu d:\home\site.

Erstellen Sie ein Verzeichnis in d:\home\site namens ini, erstellen Sie dann eine .ini-Datei im Verzeichnis d:\home\site\ini (z. B. settings.ini) mit den Anweisungen, die Sie anpassen möchten. Verwenden Sie dieselbe Syntax, die Sie in einer php.ini-Datei verwenden würden.

Führen Sie beispielsweise zum Ändern des Werts von expose_php die folgenden Befehle aus:

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

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

Zum Anpassen von PHP_INI_SYSTEM-Anweisungen (siehe php.ini-Anweisungen) können Sie nicht den Ansatz mit .htaccess verwenden. App Service bietet einen separaten Mechanismus, der die App-Einstellung PHP_INI_SCAN_DIR verwendet.

Führen Sie als Erstes den folgenden Befehl in der Cloud Shell aus, um eine App-Einstellung namens PHP_INI_SCAN_DIR hinzuzufü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"

/usr/local/etc/php/conf.d ist das Standardverzeichnis, in dem php.ini vorhanden ist. /home/site/ini ist das benutzerdefinierte Verzeichnis, in dem Sie eine benutzerdefinierte ini-Datei hinzufügen werden. Sie trennen die Werte durch :.

Navigieren Sie zu der Web-SSH-Sitzung mit Ihrem Linux-Container (https://<app-name>.scm.azurewebsites.net/webssh/host).

Erstellen Sie ein Verzeichnis in /home/site namens ini, erstellen Sie dann eine .ini-Datei im Verzeichnis /home/site/ini (z. B. settings.ini) mit den Anweisungen, die Sie anpassen möchten. Verwenden Sie dieselbe Syntax, die Sie 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 zum Ändern des Werts von expose_php die folgenden Befehle aus:

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

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

Aktivieren von PHP-Erweiterungen

Die integrierten PHP-Installationen enthalten die am häufigsten verwendeten Erweiterungen. Sie können zusätzliche Erweiterungen auf dieselbe Weise aktivieren, wie Sie php.ini-Anweisungen anpassen.

Hinweis

Die beste Möglichkeit zum Anzeigen der PHP-Version und der aktuellen php.ini-Konfiguration besteht darin, phpinfo() in Ihrer App aufzurufen.

Um zusätzliche Erweiterungen zu aktivieren, führen Sie diese Schritte aus:

Fügen Sie im Stammverzeichnis Ihrer App ein Verzeichnis vom Typ bin hinzu, und legen Sie die .dll-Erweiterungsdateien darin ab (z. B. mongodb.dll). Stellen Sie sicher, dass die Erweiterungen mit der PHP-Version in Azure sowie mit VC9 und nts-kompatibel (non-thread-safe, nicht threadsicher) sind.

Stellen Sie Ihre Änderungen bereit.

Befolgen Sie die Schritte in Anpassen von PHP_INI_SYSTEM-Anweisungen, 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 integrierten PHP-Installationen enthalten die am häufigsten verwendeten Erweiterungen. Sie können zusätzliche Erweiterungen auf dieselbe Weise aktivieren, wie Sie php.ini-Anweisungen anpassen.

Hinweis

Die beste Möglichkeit zum Anzeigen der PHP-Version und der aktuellen php.ini-Konfiguration besteht darin, phpinfo() in Ihrer App aufzurufen.

Um zusätzliche Erweiterungen zu aktivieren, führen Sie diese Schritte aus:

Fügen Sie im Stammverzeichnis Ihrer App ein Verzeichnis bin hinzu, und legen Sie die .so-Erweiterungsdateien darin ab (z. B. mongodb.so). Stellen Sie sicher, dass die Erweiterungen mit der PHP-Version in Azure sowie mit VC9 und nts-kompatibel (non-thread-safe, nicht threadsicher) sind.

Stellen Sie Ihre Änderungen bereit.

Befolgen Sie die Schritte in Anpassen von PHP_INI_SYSTEM-Anweisungen, 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 Standardhilfsprogramm error_log(), um Ihre Diagnoseprotokolle in Azure App Service anzuzeigen.

Aktivieren Sie die Diagnoseprotokollierung, indem Sie den folgenden Befehl in Cloud Shellausführen, um auf die Konsolenprotokolle zuzugreifen, die innerhalb des Anwendungscodes in App Service generiert wurden:

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, WarningInfo oder Verbose. Jede nachfolgende Ebene enthält die vorherige Ebene. Beispiel: Error enthält nur Fehlermeldungen, und Verbose enthält alle Meldungen.

Führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen, nachdem die Diagnoseprotokollierung aktiviert wurde:

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

Falls Sie nicht sofort Konsolenprotokolle sehen, können Sie es nach 30 Sekunden noch einmal versuchen.

Hinweis

Sie können die Protokolldateien auch im Browser unter https://<app-name>.scm.azurewebsites.net/api/logs/docker untersuchen.

Um das Protokollstreaming jederzeit zu beenden, geben Sie Ctrl+C ein.

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

Aktivieren Sie zuerst Containerprotokollierung, indem Sie den folgenden Befehl ausführen:

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 die entsprechenden Namen für Ihre Web-App.

Führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen, nachdem die Containerprotokollierung aktiviert wurde:

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

Falls Sie nicht sofort Konsolenprotokolle sehen, können Sie es nach 30 Sekunden noch einmal versuchen.

Zum Beenden des Protokollstreamings können Sie jederzeit STRG+C drücken.

Sie können die Protokolldateien auch in einem Browser unter https://<app-name>.scm.azurewebsites.net/api/logs/docker untersuchen.

Problembehandlung

Wenn sich eine funktionierende PHP-App in App Service anders verhält oder Fehler aufweist, versuchen Sie Folgendes:

  • Greifen Sie auf den Protokolldatenstrom zu.
  • Testen Sie die App lokal im Produktionsmodus. App Service führt Ihre Apps im Produktionsmodus aus. Daher müssen Sie sicherstellen, dass Ihr Projekt lokal wie erwartet im Produktionsmodus funktioniert. Beispiel:
    • Abhängig von Ihrer composer.json können verschiedene Pakete für den Produktionsmodus installiert sein (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. Z. B. können Sie in Laravel Ihre App so konfigurieren, dass sie in der Produktion Debugmeldungen ausgibt, indem Sie die App-Einstellung APP_DEBUG auf true festlegen.

„robots933456“ 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 zeigt lediglich an, dass der Pfad nicht vorhanden ist, informiert App Service aber darüber, dass der Container fehlerfrei und bereit ist, um auf Anforderungen zu antworten.

Nächste Schritte

Tutorial: PHP-App mit MySQL

Häufig gestellte Fragen (FAQ) zu Azure App Service unter Linux

Oder siehe in zusätzlichen Ressourcen:

Referenz zu Umgebungsvariablen und App-Einstellungen