Condividi tramite

Configurare un'app PHP nel servizio app di Azure

Avvertimento

PHP in Windows ha raggiunto la fine del supporto a novembre 2022. PHP è supportato solo per il 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 di Azure. Vengono illustrate le attività di configurazione più comuni.

Se non si ha familiarità con App Service, seguire prima di tutto il quickstart Creare un'app Web PHP in Azure App Service e l'esercitazione Distribuire un'app PHP, MySQL e Redis in Azure App Service.

Visualizzare la versione di PHP

Per mostrare la versione corrente di PHP, esegui il seguente comando. È possibile usare Azure Cloud Shell:

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

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

Annotazioni

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 seguente comando:

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 di Azure. Vengono illustrate le attività di configurazione più comuni.

Se non si ha familiarità con App Service, seguire prima di tutto il quickstart Creare un'app Web PHP in Azure App Service e l'esercitazione Distribuire un'app PHP, MySQL e Redis in Azure App Service.

Visualizzare la versione di PHP

Per mostrare la versione corrente di PHP, esegui il seguente comando. È possibile usare Azure Cloud Shell.

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

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

Annotazioni

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 seguente comando:

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

Impostare la versione php

Per impostare la versione di PHP su 8.1, eseguire il seguente comando:

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

Per impostare la versione di PHP su 8.1, eseguire il seguente comando:

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

Cosa accade ai runtime obsoleti nel servizio app?

I runtime obsoleti sono deprecati dall'organizzazione di gestione o hanno rilevato vulnerabilità significative. Di conseguenza, vengono rimossi dalle pagine di creazione e configurazione nel portale. Quando un runtime obsoleto è nascosto dal portale, qualsiasi app che usa ancora tale runtime continua a essere eseguita.

Se si vuole creare un'app con una versione di runtime obsoleta non più visualizzata nel portale, usare l'interfaccia della riga di comando di Azure, il modello arm o Bicep. Queste alternative di distribuzione consentono di creare runtime obsoleti, che sono stati rimossi dal portale, ma sono ancora supportati.

Se un runtime viene rimosso completamente dalla piattaforma del servizio app, il proprietario della sottoscrizione di Azure riceve un avviso di posta elettronica prima della rimozione.

Avvia Composer

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

Da una finestra del terminale locale, cambia la directory nella radice del tuo repository. Seguire quindi le istruzioni in Scaricare Composer per scaricare composer.phar nella directory principale.

Eseguire i comandi seguenti. Per eseguirli, è necessario installare npm .

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

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

Apri deploy.sh e trova la sezione Deployment, che sembra questo esempio:

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

Alla fine della Deployment sezione, aggiungere la sezione del codice necessario per eseguire lo strumento richiesto:

# 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 usando la distribuzione ZIP con l'automazione della compilazione abilitata. Composer dovrebbe ora essere funzionante come parte dell'automazione della distribuzione.

Eseguire Bower, Gulp o Grunt

Se si vuole che il servizio app esegua gli strumenti di automazione più diffusi in fase di distribuzione, ad esempio Bower, Gulp o Grunt, è necessario fornire uno script di distribuzione personalizzato. Il servizio app esegue questo script quando si esegue la distribuzione usando Git o tramite ZIP deploy con l'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, passare alla directory principale del repository ed eseguire i comandi seguenti. Per eseguirli, è necessario installare npm .

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

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

Apri deploy.sh e trova la sezione Deployment, che sembra questo esempio:

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

Questa sezione termina con l'esecuzione di npm install --production. Alla fine della Deployment sezione, aggiungere la sezione del codice necessario per eseguire lo strumento richiesto:

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

Pergola

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

Sorso

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

Grugnito

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 usando pacchetti ZIP con l'automazione della compilazione abilitata, l'automazione della compilazione nel servizio app illustra la sequenza seguente:

  1. Eseguire uno script personalizzato se PRE_BUILD_SCRIPT_PATH lo specifica.
  2. Esegui php composer.phar install.
  3. Eseguire uno script personalizzato se POST_BUILD_SCRIPT_PATH lo specifica.

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

Nell'esempio seguente vengono specificate le due variabili di una serie di comandi, separati da virgole:

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 informazioni su come il servizio app esegue e compila app PHP in Linux, vedere la documentazione di Oryx su come vengono rilevate e compilate le app PHP.

Personalizzare l'avvio

È possibile eseguire un comando personalizzato al momento dell'avvio del contenitore. Eseguire il comando seguente:

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 impostare le impostazioni dell'app all'esterno del codice dell'app. È quindi possibile accedere a tali impostazioni 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 di propria scelta potrebbe usare una sottodirectory come radice del sito. Ad esempio, Laravel usa la public/ sottodirectory come radice del sito.

Per personalizzare la radice del sito, impostare il percorso dell'applicazione virtuale per l'app usando il comando az resource update. L'esempio seguente definisce la radice del sito alla 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 punta il percorso dell'applicazione virtuale radice (/) alla directory radice dei file dell'applicazione distribuiti (sites\wwwroot).

Il framework Web di propria scelta potrebbe usare una sottodirectory come radice del sito. Ad esempio, Laravel usa la public/ sottodirectory come radice del sito.

L'immagine predefinita PHP per App Service usa NGINX e la radice del sito può essere modificata configurando il server NGINX con la root direttiva. Questo file di configurazione di esempio contiene il seguente frammento di codice che modifica 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 in /etc/nginx/sites-available/default. Qualsiasi modifica apportata a questo file viene cancellata al riavvio dell'app. Per apportare una modifica effettiva 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

Nel servizio app la terminazione TLS/SSL avviene nei servizi di bilanciamento del carico di rete, quindi tutte le richieste HTTPS raggiungono l'app come richieste HTTP non crittografate. Se la logica dell'app deve verificare se le richieste utente sono crittografate, 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 la funzione 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 una delle direttivephp.ini seguendo questa procedura.

Annotazioni

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

Personalizzare le direttive che non sono PHP_INI_SYSTEM

Per personalizzare le direttive PHP_INI_USER, PHP_INI_PERDIR e PHP_INI_ALL, aggiungere un file .user.ini alla directory radice dell'app.

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

 ; 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 nonPHP_INI_SYSTEM .

Per personalizzare PHP_INI_USER, PHP_INI_PERDIR, e le PHP_INI_ALL direttive per le app Web Linux, ad esempio upload_max_filesize e expose_php, usare un file .ini personalizzato. È possibile crearlo in una sessione SSH. Prima di tutto, configurare la directory:

  1. Accedi al tuo sito Kudu. Per ottenere i valori di hash e area casuali, in Overview copiare Dominio Predefinito nell'app.
  2. Nel menu in alto selezionare Console di debug, quindi Bash o SSH.
  3. In Bash o SSH passare alla /home/site/wwwroot directory.
  4. Creare una directory denominata ini , ad esempio mkdir ini.
  5. Cambia la directory di lavoro corrente alla cartella ini che hai creato.

Quindi, crea un file .ini in cui aggiungi le tue impostazioni. Questo esempio usa extensions.ini. Non ci sono editor di file come Vi, Vim o Nano, quindi usalo Echo per aggiungere le impostazioni al file. Modificare il valore upload_max_filesize da 2M a 50M. Usare il comando seguente per aggiungere l'impostazione e creare un extensions.ini file se non ne esiste già uno:

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

Nel portale di Azure aggiungere un'impostazione dell'applicazione per analizzare la ini directory appena creata per applicare la modifica per upload_max_filesize:

  1. Passare al portale di Azure e selezionare l'applicazione PHP Linux del servizio app.
  2. Passare a Impostazioni>Variabili d'ambiente.
  3. Seleziona + Aggiungi.
  4. In Nome immettere PHP_INI_SCAN_DIR e per Valore immettere :/home/site/wwwroot/ini.
  5. Selezionare Applica, quindi di nuovo Applica . Confermare le modifiche.

Annotazioni

Se è stata ricompilata un'estensione PHP, ad esempio GD, seguire la procedura descritta in Ricompilazione delle estensioni PHP.

Personalizzare le direttive PHP_INI_SYSTEM

Per personalizzare PHP_INI_SYSTEM le direttive, utilizzare l'impostazione dell'app PHP_INI_SCAN_DIR.

Innanzitutto, esegui il seguente comando per aggiungere un'impostazione dell'app chiamata 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"

Nel portale di Azure selezionare l'app. In Strumenti di sviluppo nel menu della barra laterale, seleziona Strumenti avanzati, quindi vai a d:\home\site Utilizzo di SSH.

Creare una directory in d:\home\site denominata ini. Quindi, creare un file .ini nella directory d:\home\site\ini, ad esempio settings.ini, con le direttive che si desidera personalizzare. Usare la stessa sintassi usata in un php.ini file.

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, riavviare l'app.

Per personalizzare le direttive PHP_INI_SYSTEM, non è possibile utilizzare l'approccio .htaccess. Il *App Service* utilizza un meccanismo separato che usa l'impostazione dell'app PHP_INI_SCAN_DIR.

Innanzitutto, esegui il seguente comando per aggiungere un'impostazione dell'app chiamata 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"

Il valore /usr/local/etc/php/conf.d è la directory predefinita in cui php.ini esiste. Il valore /home/site/ini è la directory personalizzata in cui si aggiunge un file personalizzato di.ini. Separare i valori con due punti (:).

Passare alla sessione SSH Web con il contenitore Linux.

Creare una directory in /home/site denominata ini. Quindi, creare un file .ini nella directory /home/site/ini, ad esempio settings.ini, con le direttive che si desidera personalizzare. Usare la stessa sintassi usata in un php.ini file.

Suggerimento

I contenitori Linux predefiniti nel servizio app usano /home 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, riavviare l'app.

Abilitare le estensioni PHP

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

Annotazioni

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

Per abilitare altre estensioni, seguire questa procedura:

  1. Aggiungi una bin directory alla directory principale dell'app e inseriscivi i file di estensione.dll , ad esempio mongodb.dll. Assicurarsi che le estensioni siano compatibili con la versione PHP in Azure e che siano compatibili con VC9 e non thread-safe (NTS).

  2. Distribuire le modifiche.

  3. Seguire la procedura descritta in Personalizzare le direttive PHP_INI_SYSTEM e aggiungere le estensioni nel file di .ini personalizzato con l'estensione o la direttiva zend_extension:

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

Per rendere effettive le modifiche, riavviare l'app.

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

Annotazioni

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

Per abilitare altre estensioni, seguire questa procedura:

  1. Aggiungi una bin directory alla directory principale dell'app e inseriscivi i file con estensione .so (ad esempio, mongodb.so). Assicurarsi che le estensioni siano compatibili con la versione PHP in Azure e che siano compatibili con VC9 e non thread-safe (NTS).

  2. Distribuire le modifiche.

  3. Seguire la procedura descritta in Personalizzare le direttive PHP_INI_SYSTEM e aggiungere le estensioni nel file di .ini personalizzato con l'estensione o la direttiva zend_extension:

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

Per rendere effettive le modifiche, riavviare l'app.

Accedere ai log di diagnostica

Usare lo strumento standard error_log() per visualizzare i log di diagnostica nel servizio app di Azure.

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, Infoe Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo messaggi di errore. Verbose include tutti i messaggi.

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

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

Se i log della console non vengono visualizzati immediatamente, controllare di nuovo in 30 secondi.

Per arrestare lo streaming dei log in qualsiasi momento, selezionare CTRL+C.

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

Per attivare la registrazione dei contenitori, eseguire il comando seguente:

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 nomi appropriati per l'app Web.

Dopo aver attivato la registrazione dei contenitori, eseguire il comando seguente per visualizzare il flusso di log:

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

Se i log della console non vengono visualizzati immediatamente, controllare di nuovo in 30 secondi.

Per arrestare lo streaming dei log in qualsiasi momento, selezionare CTRL+C.

Risoluzione dei Problemi

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

  • Accedi al flusso del registro diagnostico.
  • Testare l'app in locale in modalità di produzione. Il servizio app esegue l'app in modalità di produzione, quindi è necessario assicurarsi che il progetto funzioni come previsto in modalità di produzione in locale. Per esempio:
    • A seconda del file composer.json, è possibile installare pacchetti diversi per la modalità di produzione (require rispetto a require-dev).
    • Alcuni framework Web potrebbero distribuire file statici in modo diverso in modalità di produzione.
    • Alcuni framework Web potrebbero usare script di avvio personalizzati durante l'esecuzione in modalità di produzione.
  • Eseguire l'app nel servizio app in modalità di debug. Ad esempio, in Laravel è possibile configurare l'app per l'output dei messaggi di debug nell'ambiente di produzione impostando l'impostazione dell'app APP_DEBUG su true.

Ignorare il messaggio robots933456 nei log

Nei log del contenitore potrebbe essere 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 che il percorso non esiste e segnala al servizio app che il contenitore è integro e pronto per rispondere alle richieste.

Contenuti correlati