Konfigurera en PHP-app för Azure App Service

Artikel
11/11/2023

Visa PHP-version

Varning

PHP i Windows nådde End-of-Life i november 2022 och stöds endast på App Service på Linux. Den här artikeln är endast till för referens..

Den här guiden visar hur du konfigurerar dina PHP-webbappar, mobila serverdelar och API-appar i Azure App Service.

Den här guiden innehåller viktiga begrepp och instruktioner för PHP-utvecklare som distribuerar appar till App Service. Om du aldrig har använt Azure App Service följer du först PHP-snabbstarten och PHP med MySQL.

Om du vill visa den aktuella PHP-versionen kör du följande kommando i Cloud Shell:

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

Kommentar

Ta med parametern --slot följt av namnet på platsen för att hantera ett utvecklingsfack.

Om du vill visa alla PHP-versioner som stöds kör du följande kommando i Cloud Shell:

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

Den här guiden visar hur du konfigurerar dina PHP-webbappar, mobila serverdelar och API-appar i Azure App Service.

Om du vill visa den aktuella PHP-versionen kör du följande kommando i Cloud Shell:

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

Kommentar

Ta med parametern --slot följt av namnet på platsen för att hantera ett utvecklingsfack.

Om du vill visa alla PHP-versioner som stöds kör du följande kommando i Cloud Shell:

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

Ange PHP-version

Kör följande kommando i Cloud Shell för att ange PHP-versionen till 8.1:

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

Kör följande kommando i Cloud Shell för att ange PHP-versionen till 8.1:

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

Kör Composer

Om du vill att App Service ska köra Composer vid distributionstillfället är det enklaste sättet att inkludera Composer på lagringsplatsen.

Från ett lokalt terminalfönster ändrar du katalogen till lagringsplatsens rot och följer anvisningarna i ladda ned Composer för att ladda ned composer.phar till katalogroten.

Kör följande kommandon (du behöver npm installerat):

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

Lagringsplatsens rot har nu ytterligare två filer: .deployment och deploy.sh.

Öppna deploy.sh och leta reda på avsnittet Deployment som ser ut så här:

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

Lägg till kodavsnittet som du behöver för att köra det nödvändiga verktyget i slutet av Deployment avsnittet:

# 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

Genomför alla dina ändringar och distribuera koden med git eller zip-distribution med versionsautomatisering aktiverat. Composer bör nu köras som en del av distributionsautomationen.

Kör Grunt/Bower/Gulp

Om du vill att App Service ska köra populära automatiseringsverktyg vid distributionen, till exempel Grunt, Bower eller Gulp, måste du ange ett anpassat distributionsskript. App Service kör det här skriptet när du distribuerar med Git eller med Zip-distribution med build automation aktiverat.

Om du vill att lagringsplatsen ska kunna köra dessa verktyg måste du lägga till dem i beroendena i package.json. Till exempel:

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

Från ett lokalt terminalfönster ändrar du katalogen till lagringsplatsens rot och kör följande kommandon (du behöver npm installerat):

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

Lagringsplatsens rot har nu ytterligare två filer: .deployment och deploy.sh.

Öppna deploy.sh och leta reda på avsnittet Deployment som ser ut så här:

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

Det här avsnittet slutar med att köra npm install --production. Lägg till kodavsnittet som du behöver för att köra det nödvändiga verktyget i slutet av Deployment avsnittet:

Bower
Klunk
Grunt

Se ett exempel i MEAN.js-exemplet, där distributionsskriptet även kör ett anpassat npm install kommando.

Bower

Det här kodfragmentet kör 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

Klunk

Det här kodfragmentet kör 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

Grunt

Det här kodfragmentet kör grunt.

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

Anpassa versionsautomatisering

Om du distribuerar din app med Git eller använder zip-paket med versionsautomation aktiverat går App Service Build Automation igenom följande sekvens:

Kör anpassat skript om det anges av PRE_BUILD_SCRIPT_PATH.
Kör php composer.phar install.
Kör anpassat skript om det anges av POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND och POST_BUILD_COMMAND är miljövariabler som är tomma som standard. Om du vill köra förhandsversionskommandon definierar du PRE_BUILD_COMMAND. Om du vill köra kommandon efter bygget definierar du POST_BUILD_COMMAND.

I följande exempel anges de två variablerna till en serie kommandon, avgränsade med kommatecken.

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"

Ytterligare miljövariabler för att anpassa versionsautomatisering finns i Oryx-konfiguration.

Mer information om hur App Service kör och skapar PHP-appar i Linux finns i Oryx-dokumentationen: Hur PHP-appar identifieras och skapas.

Anpassa start

Om du vill kan du köra ett anpassat kommando vid starttiden för containern genom att köra följande kommando i Cloud Shell:

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

Få åtkomst till miljövariabler

I App Service kan du ange appinställningar utanför din appkod. Sedan kan du komma åt dem med hjälp av standardmönstret getenv(). Om du till exempel vill få åtkomst till en appinställning med namnet DB_HOST använder du följande kod:

getenv("DB_HOST")

Ändra platsrot

Det webbramverk du väljer kan använda en underkatalog som platsrot. Laravel använder till exempel den offentliga/underkatalogen som platsrot.

Om du vill anpassa platsroten anger du den virtuella programsökvägen för appen med hjälp az resource update av kommandot . I följande exempel anges platsroten till den offentliga/ underkatalogen i lagringsplatsen.

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

Som standard pekar Azure App Service den virtuella rotsökvägen för appen (/) till rotkatalogen för de distribuerade programfilerna (sites\wwwroot).

Det webbramverk du väljer kan använda en underkatalog som platsrot. Laravel använder till exempel underkatalogen public/ som platsrot.

Standard-PHP-avbildningen för App Service använder Nginx, och du ändrar platsroten genom att konfigurera Nginx-servern med root direktivet. Den här exempelkonfigurationsfilen innehåller följande kodfragment som ändrar root direktivet:

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

Standardcontainern använder konfigurationsfilen som finns på /etc/nginx/sites-available/default. Tänk på att alla ändringar som du gör i den här filen raderas när appen startas om. Om du vill göra en ändring som gäller för appomstarter lägger du till ett anpassat startkommando som det här exemplet:

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

Det här kommandot ersätter standardkonfigurationsfilen för Nginx med en fil med namnet default i lagringsplatsens rot och startar om Nginx.

Identifiera HTTPS-sessionen

I App Service sker TLS/SSL-avslutning hos nätverkslastbalanserarna, så alla HTTPS-begäranden når din app som okrypterade HTTP-begäranden. Om din applogik behöver kontrollera om användarbegäranden är krypterade eller inte kan du kontrollera X-Forwarded-Proto-rubriken.

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

Med populära ramverk får du åtkomst till X-Forwarded-* information i standardappens mönster. I CodeIgniter kontrollerar is_https() värdet för X_FORWARDED_PROTO som standard.

Anpassa php.ini-inställningar

Om du behöver göra ändringar i PHP-installationen kan du ändra något av php.ini-direktiven genom att följa dessa steg.

Kommentar

Det bästa sättet att se PHP-versionen och den aktuella php.ini-konfigurationen är att anropa phpinfo() i din app.

Anpassa direktiv som inte är PHP_INI_SYSTEM

Om du vill anpassa direktiven PHP_INI_USER, PHP_INI_PERDIR och PHP_INI_ALL (se php.ini-direktiv) lägger du till en .user.ini fil i appens rotkatalog.

Lägg till konfigurationsinställningar i .user.ini filen med samma syntax som du skulle använda i en php.ini fil. Om du till exempel vill aktivera display_errors inställningen och ange upload_max_filesize inställningen till 10 M innehåller .user.ini filen följande text:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

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

Distribuera om din app med ändringarna och starta om den.

Som ett alternativ till att använda en .user.ini fil kan du använda ini_set() i din app för att anpassa dessa icke-PHP_INI_SYSTEM direktiv.

Om du vill anpassa PHP_INI_USER, PHP_INI_PERDIR och PHP_INI_ALL-direktiv för Linux-webbappar, till exempel upload_max_filesize och expose_php, använder du en anpassad "ini"-fil. Du kan skapa den i en SSH-session.

Gå till KUDU-webbplatsen https://< sitename.scm.azurewebsites.net>.
Välj Bash eller SSH på den översta menyn.
I Bash/SSH går du till katalogen "/home/site/wwwroot".
Skapa en katalog med namnet "ini" (till exempel mkdir ini).
Ändra den aktuella arbetskatalogen till mappen "ini" som du nyss skapade.

Du måste skapa en "ini"-fil som du vill lägga till inställningarna i. I det här exemplet använder vi "extensions.ini". Det finns inga filredigerare som Vi, Vim eller Nano, så du använder echo för att lägga till inställningarna i filen. Ändra "upload_max_filesize" från 2M till 50M. Använd följande kommando för att lägga till inställningen och skapa en "extensions.ini"-fil om den inte redan finns.

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

Gå sedan till Azure-portalen och lägg till en programinställning för att genomsöka katalogen "ini" som du nyss skapade för att tillämpa ändringen för upload_max_filesize.

Gå till Azure-portalen och välj ditt App Service Linux PHP-program.
Välj Program Inställningar för appen.
Under avsnittet Programinställningar väljer du + Lägg till ny inställning.
För Appinställningsnamn anger du "PHP_INI_SCAN_DIR" och för värde anger du "/home/site/wwwroot/ini".
Välj knappen Spara.

Kommentar

Om du kompilerade om ett PHP-tillägg, till exempel GD, följer du stegen i Kompilera om PHP-tillägg i Azure App Service – Lägga till PHP-tillägg

Anpassa PHP_INI_SYSTEM direktiv

Om du vill anpassa PHP_INI_SYSTEM direktiv (se php.ini-direktiv) använder du appinställningen PHP_INI_SCAN_DIR .

Kör först följande kommando i Cloud Shell för att lägga till en appinställning med namnet PHP_INI_SCAN_DIR:

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

Gå till Kudu-konsolen (https://<app-name>.scm.azurewebsites.net/DebugConsole) och gå till d:\home\site.

Skapa en katalog i d:\home\site med namnet inioch skapa sedan en .ini-fil i d:\home\site\ini katalogen (till exempel settings.ini) med de direktiv som du vill anpassa. Använd samma syntax som du skulle använda i en php.ini-fil .

Om du till exempel vill ändra värdet för expose_php kör du följande kommandon:

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

Starta om appen för att ändringarna ska börja gälla.

Om du vill anpassa PHP_INI_SYSTEM direktiv (se php.ini-direktiv) kan du inte använda .htaccess-metoden . App Service tillhandahåller en separat mekanism med appinställningen PHP_INI_SCAN_DIR .

Kör först följande kommando i Cloud Shell för att lägga till en appinställning med namnet PHP_INI_SCAN_DIR:

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 är standardkatalogen där php.ini finns. /home/site/ini är den anpassade katalogen där du lägger till en anpassad .ini-fil . Du separerar värdena med en :.

Gå till webb-SSH-sessionen med din Linux-container (https://<app-name>.scm.azurewebsites.net/webssh/host).

Skapa en katalog i /home/site med namnet inioch skapa sedan en .ini-fil i /home/site/ini katalogen (till exempel settings.ini) med de direktiv som du vill anpassa. Använd samma syntax som du skulle använda i en php.ini-fil .

Dricks

I de inbyggda Linux-containrarna i App Service används /home som sparad delad lagring.

Om du till exempel vill ändra värdet för expose_php kör du följande kommandon:

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

Starta om appen för att ändringarna ska börja gälla.

Aktivera PHP-tillägg

De inbyggda PHP-installationerna innehåller de vanligaste tilläggen. Du kan aktivera ytterligare tillägg på samma sätt som du anpassar php.ini-direktiv.

Kommentar

Det bästa sättet att se PHP-versionen och den aktuella php.ini-konfigurationen är att anropa phpinfo() i din app.

Så här aktiverar du ytterligare tillägg:

Lägg till en bin katalog i appens rotkatalog och placera tilläggsfilerna .dll i den (till exempel mongodb.dll). Kontrollera att tilläggen är kompatibla med PHP-versionen i Azure och är VC9- och icke-trådsäkra (nts) kompatibla.

Distribuera dina ändringar.

Följ stegen i Anpassa PHP_INI_SYSTEM-direktiv, lägg till tilläggen i den anpassade .ini-filen med tillägget eller zend_extension-direktiven .

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

Starta om appen för att ändringarna ska börja gälla.

De inbyggda PHP-installationerna innehåller de vanligaste tilläggen. Du kan aktivera ytterligare tillägg på samma sätt som du anpassar php.ini-direktiv.

Kommentar

Det bästa sättet att se PHP-versionen och den aktuella php.ini-konfigurationen är att anropa phpinfo() i din app.

Så här aktiverar du ytterligare tillägg:

Lägg till en bin katalog i appens rotkatalog och placera tilläggsfilerna .so i den (till exempel mongodb.so). Kontrollera att tilläggen är kompatibla med PHP-versionen i Azure och är VC9- och icke-trådsäkra (nts) kompatibla.

Distribuera dina ändringar.

Följ stegen i Anpassa PHP_INI_SYSTEM-direktiv, lägg till tilläggen i den anpassade .ini-filen med tillägget eller zend_extension-direktiven .

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

Starta om appen för att ändringarna ska börja gälla.

Få åtkomst till diagnostikloggar

Använd standardverktyget error_log() för att få diagnostikloggarna att visas i Azure App Service.

Om du vill komma åt konsolloggarna som genereras i din programkod i App Service aktiverar du diagnostisk loggning genom att köra följande kommando i Cloud Shell:

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

Möjliga värden för --level är: Error, Warning, Info och Verbose. Varje efterföljande nivå omfattar den föregående nivån. Exempel: Error omfattar endast felmeddelanden och Verbose omfattar alla meddelanden.

När diagnostisk loggning har aktiverats kör du följande kommando för att visa loggströmmen:

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

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Kommentar

Du kan även granska loggfilerna från din webbläsare via https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Skriv Ctrl+C när som helst för att stoppa loggströmningen.

Du kan komma åt konsolloggarna som genereras inifrån containern.

Aktivera först containerloggning genom att köra följande kommando:

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

Ersätt <app-name> och <resource-group-name> med de namn som är lämpliga för din webbapp.

När containerloggning har aktiverats kör du följande kommando för att visa loggströmmen:

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

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Om du vill stoppa loggströmningen när som helst skriver du Ctrl+C.

Du kan också granska loggfilerna i en webbläsare på https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Felsökning

När en fungerande PHP-app beter sig annorlunda i App Service eller har fel kan du prova följande:

Få åtkomst till loggströmmen.
Testa appen lokalt i produktionsläge. App Service kör appen i produktionsläge, så du måste se till att projektet fungerar som förväntat i produktionsläge lokalt. Till exempel:
- Beroende på din composer.json kan olika paket installeras för produktionsläge (require jämfört med require-dev).
- Vissa webbramverk kan distribuera statiska filer på olika sätt i produktionsläge.
- Vissa webbramverk kan använda anpassade startskript när de körs i produktionsläge.
Kör appen i App Service i felsökningsläge. I Laravel kan du till exempel konfigurera appen så att den matar ut felsökningsmeddelanden i produktion genom att ange appinställningen APP_DEBUG till true.

robots933456 i loggar

Följande meddelande kan visas i containerloggarna:

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

Du kan ignorera det här meddelandet. /robots933456.txt är en dummysökväg för URL:en som App Service använder till att kontrollera om containern kan hantera begäranden. Ett 404-svar innebär helt enkelt att sökvägen inte finns, men det låter App Service veta att containern är felfri och redo att svara på begäranden.

Nästa steg

Självstudie: PHP-app med MySQL

Vanliga frågor och svar om App Service på Linux

Eller se ytterligare resurser:

Referens för miljövariabler och appinställningar

Dela via

Konfigurera en PHP-app för Azure App Service

Visa PHP-version

Ange PHP-version

Kör Composer

Kör Grunt/Bower/Gulp

Bower

Klunk

Grunt

Anpassa versionsautomatisering

Anpassa start

Få åtkomst till miljövariabler

Ändra platsrot

Identifiera HTTPS-sessionen

Anpassa php.ini-inställningar

Anpassa direktiv som inte är PHP_INI_SYSTEM

Anpassa PHP_INI_SYSTEM direktiv

Aktivera PHP-tillägg

Få åtkomst till diagnostikloggar

Felsökning

robots933456 i loggar

Nästa steg

Feedback

Ytterligare resurser