Konfigurieren einer PHP-App für Azure App Service

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

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

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

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:

• Bower
• Gulp
• Grunt

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>"

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.

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.

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.

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.

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.

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.

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.

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.

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.

„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.