Configurare un'app PHP per il servizio app Azure

Articolo
08/31/2023

Visualizzare la versione di PHP

Avviso

PHP in Windows ha raggiunto la fine della vita a novembre 2022 ed è supportato solo in servizio app in Linux. Questo articolo è solo per riferimento..

Questa guida illustra come configurare le app Web PHP, i back-end per dispositivi mobili e le app per le API nel servizio app Azure.

Questa guida fornisce concetti chiave e istruzioni per gli sviluppatori PHP che distribuiscono app in servizio app. Se non si è mai usato Servizio app di Azure, seguire per prima cosa l'Avvio rapido di PHP e l'esercitazione di PHP con MySQL.

Per visualizzare la versione corrente di PHP, eseguire il comando seguente in Cloud Shell:

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

Nota

Per risolvere uno slot di sviluppo, includere il parametro --slot seguito dal nome dello slot.

Per visualizzare tutte le versioni di PHP supportate, eseguire il comando seguente in Cloud Shell:

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

Questa guida illustra come configurare le app Web PHP, i back-end per dispositivi mobili e le app per le API nel servizio app Azure.

Per visualizzare la versione corrente di PHP, eseguire il comando seguente in Cloud Shell:

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

Nota

Per risolvere uno slot di sviluppo, includere il parametro --slot seguito dal nome dello slot.

Per visualizzare tutte le versioni di PHP supportate, eseguire il comando seguente in Cloud Shell:

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

Impostare la versione di PHP

Eseguire il comando seguente in Cloud Shell per impostare la versione PHP su 8.1:

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

Eseguire il comando seguente in Cloud Shell per impostare la versione PHP su 8.1:

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

Eseguire Composer

Se si vuole servizio app eseguire Composer in fase di distribuzione, il modo più semplice consiste nell'includere Composer nel repository.

Da una finestra del terminale locale modificare la directory nella radice del repository e seguire le istruzioni in scaricare Composer per scaricare composer.phar nella directory radice.

Eseguire i comandi seguenti (è necessario installare npm ):

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

La radice del repository include ora due file aggiuntivi: .deployment e deploy.sh.

Aprire deploy.sh e trovare la Deployment sezione simile alla seguente:

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

Aggiungere la sezione del codice necessaria per eseguire lo strumento necessario alla fine della Deployment sezione:

# 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

Eseguire il commit di tutte le modifiche e distribuire il codice usando Git o Zip deploy con l'automazione della compilazione abilitata. Composer dovrebbe ora essere in esecuzione come parte dell'automazione della distribuzione.

Eseguire Grunt/Bower/Gulp

Se si vuole servizio app eseguire gli strumenti di automazione più diffusi in fase di distribuzione, ad esempio Grunt, Bower o Gulp, è necessario fornire uno script di distribuzione personalizzato. servizio app esegue questo script quando si esegue la distribuzione con Git o con Distribuzione zip con con automazione della compilazione abilitata.

Per abilitare il repository per eseguire questi strumenti, è necessario aggiungerli alle dipendenze in package.json. Per esempio:

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

Da una finestra del terminale locale modificare la directory nella radice del repository ed eseguire i comandi seguenti (è necessario installare npm ):

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

La radice del repository include ora due file aggiuntivi: .deployment e deploy.sh.

Aprire deploy.sh e trovare la Deployment sezione simile alla seguente:

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

Questa sezione termina con l'esecuzione npm install --productiondi . Aggiungere la sezione del codice necessaria per eseguire lo strumento necessario alla fine della Deployment sezione:

Bower
Gulp
Grunt

Vedere un esempio nell'esempio MEAN.js, in cui lo script di distribuzione esegue anche un comando personalizzato npm install .

Bower

Questo frammento di codice esegue 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

Gulp

Questo frammento di codice esegue 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

Questo frammento di codice esegue grunt.

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

Personalizzare l'automazione della compilazione

Se si distribuisce l'app usando Git o si usano pacchetti ZIP con l'automazione della compilazione abilitata, la procedura di automazione della compilazione servizio app seguire questa sequenza:

Esegue lo script personalizzato se specificato da PRE_BUILD_SCRIPT_PATH.
Eseguire php composer.phar install.
Esegue lo script personalizzato se specificato da POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND e POST_BUILD_COMMAND sono variabili di ambiente vuote per impostazione predefinita. Per eseguire comandi pre-compilazione, definire PRE_BUILD_COMMAND. Per eseguire comandi post-compilazione, definire POST_BUILD_COMMAND.

Nell'esempio seguente vengono specificate le due variabili, separate da virgole, per una serie di comandi.

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"

Per altre variabili di ambiente per personalizzare l'automazione della compilazione, vedere Configurazione Oryx.

Per altre informazioni su come servizio app viene eseguita e compilata app PHP in Linux, vedere la documentazione di Oryx: Come vengono rilevate e compilate le app PHP.

Personalizzare l’avvio

Se si vuole, è possibile eseguire un comando personalizzato all'avvio del contenitore eseguendo il comando seguente in Cloud Shell:

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

Accedere alle variabili di ambiente

Nel servizio app è possibile configurare le impostazioni dell'app al di fuori del codice dell'app. È quindi possibile accedervi usando il modello standard getenv(). Ad esempio, per accedere a un'impostazione dell'app denominata DB_HOST, usare il codice seguente:

getenv("DB_HOST")

Modificare la radice del sito

Il framework Web scelto può usare una sottodirectory come radice del sito. Ad esempio, Laravel usa la sottodirectory public/ subdirectory come radice del sito.

Per personalizzare la radice del sito, impostare il percorso dell'applicazione virtuale per l'app usando il az resource update comando . L'esempio seguente imposta la radice del sito sulla sottodirectory public/ nel repository.

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

Per impostazione predefinita, il servizio app di Azure fa in modo che il percorso virtuale dell'applicazione radice (/) punti alla directory radice dei file dell'applicazione distribuiti (sites\wwwroot).

Il framework Web scelto può usare una sottodirectory come radice del sito. Laravel, ad esempio, usa la sottodirectory public/ come radice del sito.

L'immagine PHP predefinita per servizio app usa Nginx e si modifica la radice del sito configurando il server Nginx con la root direttiva . Questo file di configurazione di esempio contiene i frammenti di codice seguenti che modificano la root direttiva:

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

Il contenitore predefinito usa il file di configurazione trovato in /etc/nginx/sites-available/default. Tenere presente che qualsiasi modifica apportata a questo file viene cancellata al riavvio dell'app. Per apportare una modifica efficace tra i riavvii dell'app, aggiungere un comando di avvio personalizzato come nell'esempio seguente:

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

Questo comando sostituisce il file di configurazione Nginx predefinito con un file denominato default nella radice del repository e riavvia Nginx.

Rilevare una sessione HTTPS

In servizio app la terminazione TLS/SSL avviene nei servizi di bilanciamento del carico di rete, in modo che tutte le richieste HTTPS raggiungano l'app come richieste HTTP non crittografate. Se la logica dell'app deve controllare se le richieste degli utenti sono crittografate o meno, esaminare l'intestazione X-Forwarded-Proto.

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

I framework Web più diffusi consentono di accedere alle informazioni X-Forwarded-* nel modello di app standard. In CodeIgniter is_https() controlla il valore di X_FORWARDED_PROTO per impostazione predefinita.

Personalizzare le impostazioni di php.ini

Se è necessario apportare modifiche all'installazione di PHP, è possibile modificare qualsiasi direttiva di php.ini seguendo questa procedura.

Nota

Il modo migliore per visualizzare la versione di PHP e la configurazione corrente di php.ini è chiamare phpinfo() nell'app.

Personalizzare le direttive non PHP_INI_SYSTEM

Per personalizzare PHP_INI_Uedizione Standard R, PHP_INI_PERDIR e direttive PHP_INI_ALL (vedere direttive php.ini), aggiungere un .user.ini file alla directory radice dell'app.

Aggiungere le impostazioni di configurazione al file .user.ini usando la stessa sintassi che si userebbe in un file php.ini. Ad esempio, se si desidera attivare l'impostazione display_errors e impostare upload_max_filesize su 10 M, il file .user.ini conterrà il testo seguente:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

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

Ridistribuire l'app con le modifiche e riavviarla.

In alternativa all'uso di un .user.ini file, puoi usare ini_set() nella tua app per personalizzare queste direttive non PHP_INI_SYSTEM.

Per personalizzare PHP_INI_Uedizione Standard R, PHP_INI_PERDIR e direttive PHP_INI_ALL per le app Web Linux, ad esempio upload_max_filesize e expose_php, usare un file "ini" personalizzato. È possibile crearlo in una sessione SSH.

Passare al sito KUDU https://< sitename.scm.azurewebsites.net>.
Selezionare Bash o SSH dal menu in alto.
In Bash/SSH passare alla directory "/home/site/wwwroot".
Creare una directory denominata "ini", ad esempio mkdir ini.
Modificare la directory di lavoro corrente nella cartella "ini" appena creata.

È necessario creare un file "ini" a cui aggiungere le impostazioni. In questo esempio viene usato "extensions.ini". Non sono presenti editor di file come Vi, Vim o Nano, quindi si userà echo per aggiungere le impostazioni al file. Modificare "upload_max_filesize" da 2M a 50M. Usare il comando seguente per aggiungere l'impostazione e creare un file "extensions.ini" se non esiste già.

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

Passare quindi al portale di Azure e aggiungere un'impostazione applicazione per analizzare la directory "ini" appena creata per applicare la modifica per upload_max_filesize.

Passare al portale di Azure e selezionare l'applicazione PHP servizio app Linux.
Selezionare Application Impostazioni per l'app.
Nella sezione Impostazioni applicazione selezionare + Aggiungi nuova impostazione.
Per Nome impostazione app immettere "PHP_INI_SCAN_DIR" e per valore immettere "/home/site/wwwroot/ini".
Fare clic sul pulsante Salva.

Nota

Se è stata ricompilata un'estensione PHP, ad esempio GD, seguire la procedura descritta in Ricompilazione delle estensioni PHP nel servizio app Azure - Aggiunta di estensioni PHP

Personalizzare le direttive PHP_INI_SYSTEM

Per personalizzare le direttive PHP_INI_SYSTEM (vedere direttive php.ini), usare l'impostazione dell'app PHP_INI_SCAN_DIR .

Eseguire prima di tutto il comando seguente in Cloud Shell per aggiungere un'impostazione dell'app denominata 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"

Passare alla console Kudu (https://<app-name>.scm.azurewebsites.net/DebugConsole) e passare a d:\home\site.

In d:\home\site creare una directory denominata ini, quindi creare un file INI nella directory d:\home\site\ini (ad esempio, settings.ini) con le direttive che si vogliono personalizzare. Usare la stessa sintassi che si userebbe in un file php.ini.

Ad esempio, per modificare il valore di expose_php, eseguire i comandi seguenti:

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

Per rendere effettive le modifiche apportate, riavviare l'app.

Per personalizzare le direttive PHP_INI_SYSTEM (vedere le direttive di php.ini), non è possibile usare l'approccio basato sul file con estensione htaccess. Il servizio app fornisce un meccanismo separato che usa l'impostazione dell'app PHP_INI_SCAN_DIR.

Eseguire prima di tutto il comando seguente in Cloud Shell per aggiungere un'impostazione dell'app denominata 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 è la directory predefinita in cui si trova php.ini. /home/site/ini è la directory personalizzata in cui si aggiungerà un file INI personalizzato. Separare i valori con :.

Passare alla sessione SSH Web con il contenitore Linux (https://<app-name>.scm.azurewebsites.net/webssh/host).

In /home/site creare una directory denominata ini, quindi creare un file INI nella directory /home/site/ini (ad esempio, settings.ini) con le direttive che si vogliono personalizzare. Usare la stessa sintassi che si userebbe in un file php.ini.

Suggerimento

Nei contenitori Linux predefiniti nel servizio app, /home viene usata come risorsa di archiviazione condivisa persistente.

Ad esempio, per modificare il valore di expose_php, eseguire i comandi seguenti:

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

Per rendere effettive le modifiche apportate, riavviare l'app.

Abilitare le estensioni di PHP

Le installazioni di PHP predefinite contengono le estensioni usate più di frequente. È possibile abilitare altre estensioni nello stesso modo in cui si personalizzano le direttive di php.ini.

Nota

Il modo migliore per visualizzare la versione di PHP e la configurazione corrente di php.ini è chiamare phpinfo() nell'app.

Per abilitare le estensioni aggiuntive, eseguire la procedura seguente:

Aggiungere una bin directory alla directory radice dell'app e inserirli nei .dll file di estensione, ad esempio mongodb.dll. Verificare che le estensioni siano compatibili con la versione di PHP in Azure e con VC9, ma non con thread-safe (nts).

Distribuire le modifiche.

Seguire la procedura descritta in Personalizzare le direttive PHP_INI_SYSTEM, aggiungere le estensioni nel file INI personalizzato con le direttive extension o zend_extension.

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

Per rendere effettive le modifiche apportate, riavviare l'app.

Le installazioni di PHP predefinite contengono le estensioni usate più di frequente. È possibile abilitare altre estensioni nello stesso modo in cui si personalizzano le direttive di php.ini.

Nota

Il modo migliore per visualizzare la versione di PHP e la configurazione corrente di php.ini è chiamare phpinfo() nell'app.

Per abilitare le estensioni aggiuntive, eseguire la procedura seguente:

Aggiungere una directory bin alla directory radice dell'app e inserirvi i file con estensione .so (ad esempio, mongodb.so). Verificare che le estensioni siano compatibili con la versione di PHP in Azure e con VC9, ma non con thread-safe (nts).

Distribuire le modifiche.

Seguire la procedura descritta in Personalizzare le direttive PHP_INI_SYSTEM, aggiungere le estensioni nel file INI personalizzato con le direttive extension o zend_extension.

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

Per rendere effettive le modifiche apportate, riavviare l'app.

Accedere ai log di diagnostica

Usare l'utilità standard error_log() per visualizzare i log di diagnostica in app Azure Servizio.

Per accedere ai log della console generati dall'interno del codice dell'applicazione nel servizio app, attivare la registrazione diagnostica eseguendo il comando seguente in Cloud Shell:

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

I valori possibili per --level sono: Error, Warning, Info e Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo i messaggi di errore, mentre Verbose include tutti i messaggi.

Dopo aver attivato la registrazione diagnostica, eseguire il comando seguente per visualizzare il flusso di registrazione:

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

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Nota

È anche possibile esaminare i file di log nel browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Per interrompere lo streaming dei log in qualsiasi momento, digitare Ctrl+C.

È possibile accedere ai log della console generati dall'interno del contenitore.

Prima di tutto attivare la registrazione del contenitore eseguendo questo comando:

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

Sostituire <app-name> e <resource-group-name> con i valori appropriati per l'app Web.

Dopo che la registrazione del contenitore è attivata, eseguire il comando seguente per visualizzare il flusso di registrazione:

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

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Per interrompere lo streaming dei log in qualsiasi momento, premere CTRL+C.

È anche possibile ispezionare i file di log in un browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Risoluzione dei problemi

Quando un'app PHP funzionante si comporta in modo diverso nel servizio app o presenta errori, provare a eseguire le operazioni seguenti:

Accedere al flusso di log.
Testare l'app in locale nella modalità di produzione. servizio app esegue l'app in modalità di produzione, quindi è necessario assicurarsi che il progetto funzioni come previsto in modalità di produzione in locale. ad esempio
- A seconda del file composer.json, è possibile che siano installati pacchetti diversi per la modalità di produzione (require o require-dev).
- Alcuni framework Web possono distribuire i file statici in modo diverso in modalità di produzione.
- Alcuni framework Web possono usare script di avvio personalizzati durante l'esecuzione in modalità di produzione.
Eseguire l'app nel servizio app in modalità di debug. In Laravel è ad esempio possibile configurare l'app per l'output di messaggi di debug in fase di produzione impostando l'impostazione dell'app APP_DEBUG su true.

robots933456 nei log

È possibile che nei log del contenitore venga visualizzato il messaggio seguente:

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

Questo messaggio può tranquillamente essere ignorato. /robots933456.txt è un percorso URL fittizio usato dal servizio app per verificare se il contenitore è in grado di gestire le richieste. Una risposta 404 indica semplicemente che il percorso non esiste, ma consente al servizio app di capire che il contenitore è integro e pronto per rispondere alle richieste.

Passaggi successivi

Esercitazione: App PHP con MySQL

Domande frequenti sul Servizio app di Azure in Linux

In alternativa, vedere risorse aggiuntive:

Informazioni di riferimento sulle variabili di ambiente e sulle impostazioni dell'app

Condividi tramite

Configurare un'app PHP per il servizio app Azure

Visualizzare la versione di PHP

Impostare la versione di PHP

Eseguire Composer

Eseguire Grunt/Bower/Gulp

Bower

Gulp

Grunt

Personalizzare l'automazione della compilazione

Personalizzare l’avvio

Accedere alle variabili di ambiente

Modificare la radice del sito

Rilevare una sessione HTTPS

Personalizzare le impostazioni di php.ini

Personalizzare le direttive non PHP_INI_SYSTEM

Personalizzare le direttive PHP_INI_SYSTEM

Abilitare le estensioni di PHP

Accedere ai log di diagnostica

Risoluzione dei problemi

robots933456 nei log

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive