Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Varning
PHP på Windows nådde slutet av supporten i november 2022. PHP stöds endast för App Service i 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. De vanligaste konfigurationsuppgifterna beskrivs.
Om du inte har använt App Service tidigare bör du först följa snabbstarten Skapa en PHP-webbapp i Azure App Service och självstudien Distribuera en PHP-, MySQL- och Redis-app till Azure App Service .
Visa PHP-versionen
För att visa den aktuella PHP-versionen, kör följande kommando. Du kan använda Azure Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query phpVersion
Ersätt <resource-group-name> och <app-name> med namn som är lämpliga för din webbapp.
Anmärkning
Inkludera parametern --slot följt av namnet på facket för att åtgärda ett utvecklingsfack.
För att visa alla PHP-versioner som stöds, kör följande kommando:
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. De vanligaste konfigurationsuppgifterna beskrivs.
Om du inte har använt App Service tidigare bör du först följa snabbstarten Skapa en PHP-webbapp i Azure App Service och självstudien Distribuera en PHP-, MySQL- och Redis-app till Azure App Service .
Visa PHP-versionen
För att visa den aktuella PHP-versionen, kör följande kommando. Du kan använda Azure Cloud Shell.
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Ersätt <resource-group-name> och <app-name> med namn som är lämpliga för din webbapp.
Anmärkning
Inkludera parametern --slot följt av namnet på facket för att åtgärda ett utvecklingsfack.
För att visa alla PHP-versioner som stöds, kör följande kommando:
az webapp list-runtimes --os linux | grep PHP
Ange PHP-versionen
För att ställa in PHP-versionen till 8.1, kör följande kommando:
az webapp config set --resource-group <resource-group-name> --name <app-name> --php-version 8.1
För att ställa in PHP-versionen till 8.1, kör följande kommando:
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PHP|8.1"
Vad händer med inaktuella körmiljöer i App Service?
Inaktuella körningsmiljöer avvecklas av den underhållande organisationen eller har visat sig ha betydande säkerhetsrisker. Därför tas de bort från skapa och konfigurera sidor i portalen. När en föråldrad runtime är dold från portalen fortsätter alla appar som fortfarande använder den att köra.
Om du vill skapa en app med en inaktuell körningsversion som inte längre visas på portalen använder du Azure CLI, ARM-mallen eller Bicep. Med de här distributionsalternativen kan du skapa föråldrade körmiljöer som har tagits bort i portalen, men som fortfarande stöds.
Om en köremiljö tas bort fullständigt från App Service-plattformen får ägaren av din Azure-prenumeration ett e-postmeddelande före borttagningen.
Kör Composer
Om du vill att App Service ska köra Composer vid distributionen är det enklaste sättet att inkludera Composer på lagringsplatsen.
Från ett lokalt terminalfönster ändrar du katalogen till lagringsplatsens rot. Följ sedan anvisningarna i Ladda ned Composer för att ladda ned composer.phar till katalogroten.
Kör följande kommandon. För att köra dem behöver du npm installerat.
npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt
Lagringsplatsens rot har nu två nya filer: .deployment och deploy.sh.
Öppna deploy.sh och leta reda på Deployment avsnittet, som ser ut så här:
##################################################################################################################################
# Deployment
# ----------
I slutet av Deployment avsnittet lägger du till kodavsnittet som du behöver för att köra det nödvändiga verktyget:
# 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 hjälp av Git eller genom att använda ZIP-distribution med versionsautomatisering aktiverat. Composer bör nu köras som en del av distributionsautomationen.
Kör Bower, Gulp eller Grunt
Om du vill att App Service ska köra populära automatiseringsverktyg vid distributionen, till exempel Bower, Gulp eller Grunt, måste du ange ett anpassat distributionsskript. App Service kör det här skriptet när du distribuerar med hjälp av Git eller med hjälp av 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. För att köra dem behöver du npm installerat.
npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt
Lagringsplatsens rot har nu två nya filer: .deployment och deploy.sh.
Öppna deploy.sh och leta reda på Deployment avsnittet, som ser ut så här:
##################################################################################################################################
# Deployment
# ----------
Det här avsnittet slutar genom att köra npm install --production.
I slutet av Deployment avsnittet lägger du till kodavsnittet som du behöver för att köra det nödvändiga verktyget:
Se ett exempel i MEAN.js exempel, där distributionsskriptet även kör ett anpassat npm install kommando.
Berså
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
Grymta
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 byggautomatisering
Om du distribuerar din app med hjälp av Git eller med hjälp av ZIP-paket med versionsautomation aktiverad går versionsautomationen i App Service igenom följande sekvens:
- Kör ett anpassat skript om det anges av
PRE_BUILD_SCRIPT_PATH. - Kör
php composer.phar install. - Kör ett 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. För att köra förberedda kommandon måste du definiera 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"
Andra miljövariabler för att anpassa versionsautomatisering finns i Oryx-konfiguration.
Information om hur Serviço de Aplicativo kör och skapar PHP-appar i Linux finns i Oryx-dokumentationen om hur PHP-appar identifieras och skapas.
Anpassa uppstart
Du kan köra ett anpassat kommando vid starttiden för containern. Kör följande kommando:
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. Du kan sedan komma åt dessa inställningar 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 webbplatsroten
Det webbramverk du väljer kan använda en underkatalog som platsrot.
Laravel använder till exempel underkatalogen public/ som platsrot.
För att anpassa webbplatseroten ställer du in den virtuella programsökvägen för appen med hjälp av az resource update-kommandot. I följande exempel anges webbplatsroten till underkatalogen public/ i ditt arkiv.
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 rotappsökvägen (/) 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 på /etc/nginx/sites-available/default. Alla ändringar 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 omstarter av appar 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 NGINX-standardkonfigurationsfilen med en fil med namnet default i lagringsplatsens rot och startar om NGINX.
Identifiera en HTTPS-session
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 kontrollerar du 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 webb-ramverk får du åtkomst till X-Forwarded-* information i din standardappstruktur. I CodeIgniter kontrollerar funktionen is_https() värdet X_FORWARDED_PROTO för som standard.
Anpassa php.ini inställningar
Om du behöver göra ändringar i PHP-installationen kan du ändra något av dephp.ini direktiven med hjälp av följande steg.
Anmärkning
Det bästa sättet att se PHP-versionen och den aktuella php.ini konfigurationen är att anropa phpinfo() i din app.
Anpassa icke-PHP_INI_SYSTEM direktiv
Om du vill anpassa PHP_INI_USER, PHP_INI_PERDIRoch PHP_INI_ALL -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 ställa in upload_max_filesize inställningen på 10Minnehåller .user.ini filen den här texten:
; 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-direktivPHP_INI_SYSTEM .
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. Konfigurera först katalogen:
- Gå till din Kudu-webbplats. Om du vill hämta värdena för slumpmässig hash och region kopierar du Standarddomän i appen Översikt.
- På den översta menyn väljer du Felsökningskonsol och sedan Bash eller SSH.
- Gå till din
/home/site/wwwrootkatalog i Bash eller SSH. - Skapa en katalog med namnet
ini(till exempelmkdir ini). - Ändra den aktuella arbetskatalogen till den
inimapp som du skapade.
Skapa sedan en .ini fil där du lägger till dina inställningar. I det här exemplet används extensions.ini. Det finns inga filredigerare som Vi, Vim eller Nano, så använd Echo för att lägga till inställningarna i filen. Ändra värdet 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 det inte redan finns någon:
/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>
I Azure-portalen lägger du 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.
- Gå tillMiljövariabler för >.
- Välj + Lägg till.
- För Namn anger du PHP_INI_SCAN_DIR och för Värde anger du
:/home/site/wwwroot/ini. - Välj Använd och sedan Tillämpa igen. Bekräfta dina ändringar.
Anmärkning
Om du kompilerade om ett PHP-tillägg, till exempel GD, följer du stegen i Kompilera om PHP-tillägg.
Anpassa PHP_INI_SYSTEM direktiv
Om du vill anpassa PHP_INI_SYSTEM direktiv använder du appinställningen PHP_INI_SCAN_DIR .
Kör först följande kommando 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"
I Azure Portal väljer du din app. Under Utvecklingsverktyg i sidofältets meny väljer du Avancerade verktyg och går sedan till att d:\home\site använda SSH.
Skapa en katalog i d:\home\site med namnet ini. Skapa sedan en .ini fil i katalogen d:\home\site\ini , settings.initill exempel , 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 expose_phpför 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 kan du inte använda .htaccess-metoden . App Service tillhandahåller en separat mekanism som använder appinställningen PHP_INI_SCAN_DIR .
Kör först följande kommando 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"
Värdet /usr/local/etc/php/conf.d är standardkatalogen där php.ini det finns. Värdet /home/site/ini är den anpassade katalog där du lägger till en anpassad .ini fil. Du separerar värdena med ett kolon (:).
Gå till webb-SSH-sessionen med din Linux-container.
Skapa en katalog i /home/site med namnet ini. Skapa sedan en .ini fil i katalogen /home/site/ini , settings.initill exempel , med de direktiv som du vill anpassa. Använd samma syntax som du skulle använda i en php.ini fil.
Tips/Råd
De inbyggda Linux-containrarna i App Service använder /home som ihållande delad lagring.
Om du till exempel vill ändra värdet expose_phpför 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 fler tillägg på samma sätt som du anpassar php.ini direktiv.
Anmärkning
Det bästa sättet att se PHP-versionen och den aktuella php.ini konfigurationen är att anropa phpinfo() i din app.
Använd följande steg för att aktivera andra tillägg:
Lägg till en
binkatalog i appens rotkatalog och lägg .dll tilläggsfiler i den, till exempelmongodb.dll. Kontrollera att tilläggen är kompatibla med PHP-versionen i Azure och att de är VC9- och icke-trådsäkra (NTS) kompatibla.Distribuera dina ändringar.
Följ stegen i Anpassa PHP_INI_SYSTEM-direktiv och lägg till tilläggen i den anpassade .ini-filen med tillägget eller zend_extension-direktivet :
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 fler tillägg på samma sätt som du anpassar php.ini direktiv.
Anmärkning
Det bästa sättet att se PHP-versionen och den aktuella php.ini konfigurationen är att anropa phpinfo() i din app.
Använd följande steg för att aktivera andra tillägg:
Lägg till en
binkatalog i appens rotkatalog och lägg .so-tilläggsfilerna i den (till exempelmongodb.so). Kontrollera att tilläggen är kompatibla med PHP-versionen i Azure och att de är VC9- och icke-trådsäkra (NTS) kompatibla.Distribuera dina ändringar.
Följ stegen i Anpassa PHP_INI_SYSTEM-direktiv och lägg till tilläggen i den anpassade .ini-filen med tillägget eller zend_extension-direktivet :
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 inifrån programkoden i App Service aktiverar du diagnostikloggning 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, Infooch Verbose. Varje efterföljande nivå omfattar den föregående nivån. Till exempel innehåller Error endast felmeddelanden.
Verbose innehåller alla meddelanden.
När du har aktiverat diagnostikloggning kör du följande kommando för att se loggströmmen:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.
Om du vill stoppa loggströmningen när som helst väljer du Ctrl+C.
Du kan komma åt konsolloggarna som genereras inifrån containern.
Om du vill aktivera containerloggning kör du 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 namn som är lämpliga för din webbapp.
När du har aktiverat containerloggning kör du följande kommando för att se loggströmmen:
az webapp log tail --name <app-name> --resource-group <resource-group-name>
Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.
Om du vill stoppa loggströmningen när som helst väljer du Ctrl+C.
Felsökning
När en fungerande PHP-app beter sig annorlunda i App Service eller har fel kan du prova följande lösningar:
- Få åtkomst till den diagnostiska 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.jsonfil kan olika paket installeras för produktionsläge (requirejämfört medrequire-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.
- Beroende på din
- 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_DEBUGtilltrue.
Ignorera robots933456-meddelandet i loggar
Du kan se följande meddelande 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 falsk URL-sökväg som App Service använder för att kontrollera om containern kan hantera förfrågningar. Ett 404-svar anger att sökvägen inte finns och signalerar till App Service att containern är felfri och redo att svara på begäranden.