Partekatu honen bidez:

Configuración de una aplicación PHP en Azure App Service

Advertencia

PHP en Windows alcanzó el final del soporte técnico en noviembre de 2022. PHP solo se admite para App Service en Linux. Este artículo sirve solo como referencia.

En esta guía se muestra cómo configurar las aplicaciones web PHP, los back-ends móviles y las aplicaciones de API en Azure App Service. Se tratan las tareas de configuración más comunes.

Si no está familiarizado con App Service, primero debe seguir el tutorial Creación de una aplicación web PHP en Azure App Service e Implementación de una aplicación PHP, MySQL y Redis en Azure App Service .

Mostrar la versión de PHP

Para mostrar la versión actual de PHP, ejecute el siguiente comando. Puede usar Azure Cloud Shell:

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

Reemplace <resource-group-name> y <app-name> por los nombres adecuados para la aplicación web.

Nota:

Para abordar una ranura de desarrollo, incluya el parámetro --slot seguido del nombre de la ranura.

Para mostrar todas las versiones de PHP compatibles, ejecute el siguiente comando:

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

En esta guía se muestra cómo configurar las aplicaciones web PHP, los back-ends móviles y las aplicaciones de API en Azure App Service. Se tratan las tareas de configuración más comunes.

Si no está familiarizado con App Service, primero debe seguir el tutorial Creación de una aplicación web PHP en Azure App Service e Implementación de una aplicación PHP, MySQL y Redis en Azure App Service .

Mostrar la versión de PHP

Para mostrar la versión actual de PHP, ejecute el siguiente comando. Puede usar Azure Cloud Shell.

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

Reemplace <resource-group-name> y <app-name> por los nombres adecuados para la aplicación web.

Nota:

Para abordar una ranura de desarrollo, incluya el parámetro --slot seguido del nombre de la ranura.

Para mostrar todas las versiones de PHP compatibles, ejecute el siguiente comando:

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

Establecimiento de la versión de PHP

Para establecer la versión de PHP en 8.1, ejecute el siguiente comando:

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

Para establecer la versión de PHP en 8.1, ejecute el siguiente comando:

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

¿Qué ocurre con los tiempos de ejecución obsoletos en App Service?

Los tiempos de ejecución obsoletos están en desuso por parte de la organización de mantenimiento o han detectado que tienen vulnerabilidades significativas. En consecuencia, se eliminan de las páginas de creación y configuración en el portal. Cuando un tiempo de ejecución obsoleto está oculto en el portal, cualquier aplicación que siga usando ese tiempo de ejecución continúa ejecutándose.

Si quiere crear una aplicación con una versión en tiempo de ejecución obsoleta que ya no se muestra en el portal, use la CLI de Azure, la plantilla de ARM o Bicep. Estas alternativas de implementación permiten crear entornos de ejecución en desuso que se han quitado en el portal, pero aún se admiten.

Si un entorno de ejecución se quita completamente de la plataforma de App Service, el propietario de la suscripción de Azure recibe un aviso por correo electrónico antes de la eliminación.

Ejecución de Composer

Si quiere que App Service ejecute Composer en el momento de la implementación, la manera más sencilla es incluir Composer en el repositorio.

En una ventana de terminal local, cambie el directorio a la raíz del repositorio. A continuación, siga las instrucciones de Download Composer (Descargar Composer ) para descargar composer.phar en la raíz del directorio.

Ejecute los siguientes comandos. Para ejecutarlos, necesita npm instalado.

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

La raíz del repositorio ahora tiene dos nuevos archivos: .deployment y deploy.sh.

Abra deploy.sh y busque la Deployment sección , que tiene el aspecto de este ejemplo:

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

Al final de la Deployment sección, agregue la sección de código que necesita para ejecutar la herramienta necesaria:

# 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

Confirme todos los cambios e implemente el código mediante Git o mediante la implementación ZIP con la automatización de compilación habilitada. Composer debería estar ejecutándose como parte de la automatización de la implementación.

Ejecutar Bower, Gulp o Grunt

Si quiere que App Service ejecute herramientas de automatización populares en el momento de la implementación, como Bower, Gulp o Grunt, debe proporcionar un script de implementación personalizado. App Service ejecuta este script cuando se implementa mediante Git o mediante la implementación ZIP con la automatización de compilación habilitada.

Para permitir que el repositorio ejecute estas herramientas, debe agregarlas a las dependencias de package.json. Por ejemplo:

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

En una ventana de terminal local, cambie el directorio a la raíz del repositorio y ejecute los siguientes comandos. Para ejecutarlos, necesita npm instalado.

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

La raíz del repositorio ahora tiene dos nuevos archivos: .deployment y deploy.sh.

Abra deploy.sh y busque la Deployment sección , que tiene el aspecto de este ejemplo:

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

En esta sección termina con la ejecución de npm install --production. Al final de la Deployment sección, agregue la sección de código que necesita para ejecutar la herramienta necesaria:

Consulte un ejemplo en la muestra de MEAN.js, donde el script de implementación también ejecuta un comando npm install personalizado.

Glorieta

Este fragmento de código ejecuta 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

Trago

Este fragmento de código ejecuta 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

Gruñido

Este fragmento de código ejecuta grunt:

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

Personalización de la automatización de compilaciones

Si implementa la aplicación mediante Git o mediante paquetes ZIP con la automatización de compilación habilitada, la automatización de compilación de App Service le guiará por la secuencia siguiente:

  1. Ejecute un script personalizado si PRE_BUILD_SCRIPT_PATH lo especifica.
  2. Ejecute php composer.phar install.
  3. Ejecute un script personalizado si POST_BUILD_SCRIPT_PATH lo especifica.

PRE_BUILD_COMMAND y POST_BUILD_COMMAND son variables de entorno que, de forma predeterminada, están vacías. Para ejecutar comandos anteriores a la compilación, defina PRE_BUILD_COMMAND. Para ejecutar comandos posteriores a la compilación, defina POST_BUILD_COMMAND.

En el ejemplo siguiente se especifican las dos variables en una serie de comandos, separados por comas:

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"

Para más variables de entorno para personalizar la automatización de compilaciones, consulte la configuración de Oryx.

Para obtener información sobre cómo App Service ejecuta y compila aplicaciones PHP en Linux, consulte la documentación de Oryx sobre cómo se detectan y compilan las aplicaciones PHP.

Personalización del inicio

Puede ejecutar un comando personalizado en el momento de inicio del contenedor. Ejecute el siguiente comando:

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

Acceso a variables de entorno

En App Service, puede establecer la configuración de la aplicación fuera del código de la aplicación. A continuación, puede acceder a esa configuración mediante el patrón estándar getenv() . Por ejemplo, para acceder a una configuración de una aplicación denominada DB_HOST, use el código siguiente:

getenv("DB_HOST")

Cambiar la raíz del sitio

El marco web de su elección podría usar un subdirectorio como raíz del sitio. Por ejemplo, Laravel usa el public/ subdirectorio como raíz del sitio.

Para personalizar la raíz del sitio, establezca la ruta de acceso de la aplicación virtual usando el comando az resource update. En el ejemplo siguiente se establece la raíz del sitio en el public/ subdirectorio del repositorio:

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

De forma predeterminada, Azure App Service apunta la ruta de acceso de la aplicación virtual raíz (/) al directorio raíz de los archivos de aplicación implementados (sites\wwwroot).

El marco web de su elección podría usar un subdirectorio como raíz del sitio. Por ejemplo, Laravel usa el public/ subdirectorio como raíz del sitio.

La imagen PHP predeterminada para el Servicio de Aplicaciones usa NGINX, y puedes cambiar la raíz del sitio configurando el servidor NGINX con la root directiva. Este archivo de configuración de ejemplo contiene el siguiente fragmento de código que cambia la root directiva:

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

El contenedor predeterminado usa el archivo de configuración en /etc/nginx/sites-available/default. Las modificaciones que realice en este archivo se borran cuando se reinicia la aplicación. Para realizar un cambio eficaz en los reinicios de la aplicación, agregue un comando de inicio personalizado como este ejemplo:

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

Este comando reemplaza el archivo de configuración NGINX predeterminado por un archivo denominado default en la raíz del repositorio y reinicia NGINX.

Detección de una sesión HTTPS

En App Service, la terminación de TLS/SSL se produce en los equilibradores de carga de red, por lo que todas las solicitudes HTTPS llegan a la aplicación como solicitudes HTTP sin cifrar. Si la lógica de la aplicación necesita comprobar si las solicitudes de usuario están cifradas, inspeccione el X-Forwarded-Proto encabezado:

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

Los marcos web más usados le permiten acceder a la información de X-Forwarded-* en el patrón de aplicación estándar. En CodeIgniter, la función is_https() comprueba el valor de de X_FORWARDED_PROTO forma predeterminada.

Personalización de la configuración de php.ini

Si necesita realizar cambios en la instalación de PHP, puede cambiar cualquiera de las directivas dephp.ini mediante los pasos siguientes.

Nota:

La mejor manera de ver la versión de PHP y la configuración actual php.ini es llamar a phpinfo() en tu aplicación.

Personalizar directivas que no sean PHP_INI_SYSTEM

Para personalizar las directivas PHP_INI_USER, PHP_INI_PERDIR y PHP_INI_ALL, agregue un archivo .user.ini al directorio raíz de su aplicación.

Agregue valores de configuración al .user.ini archivo mediante la misma sintaxis que usaría en un php.ini archivo. Por ejemplo, si desea activar la configuración display_errors y establecer la configuración upload_max_filesize en 10M, su archivo .user.ini contendrá este texto:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

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

Vuelva a implementar la aplicación con los cambios y reiníciela.

Como alternativa al uso de un archivo .user.ini, puedes usar ini_set() en tu aplicación para personalizar estas directivas que no son PHP_INI_SYSTEM.

Para personalizar las directivas PHP_INI_USER, PHP_INI_PERDIR y PHP_INI_ALL de las aplicaciones web de Linux, como upload_max_filesize y expose_php, utilice un archivo .ini personalizado. Puede crearlo en una sesión SSH. En primer lugar, configure el directorio :

  1. Vaya al sitio de Kudu. Para obtener los valores aleatorios de hash y región, en la información general de la aplicación, copie el dominio predeterminado.
  2. En el menú superior, seleccione Consola de depuración y, a continuación, Bash o SSH.
  3. En Bash o SSH, vaya al directorio /home/site/wwwroot.
  4. Cree un directorio denominado ini (por ejemplo, mkdir ini).
  5. Cambie el directorio de trabajo actual a la ini carpeta que creó.

A continuación, cree un archivo de.ini donde agregue su configuración. En este ejemplo se usa extensions.ini. No hay editores de archivos como Vi, Vim o Nano, así que úselo Echo para agregar la configuración al archivo. Cambie el valor de upload_max_filesize de 2M a 50M. Use el siguiente comando para agregar la configuración y crear un extensions.ini archivo si aún no existe 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>

En Azure Portal, agregue una configuración de aplicación para examinar el ini directorio que acaba de crear para aplicar el cambio para upload_max_filesize:

  1. Vaya a Azure Portal y seleccione la aplicación PHP de App Service Linux.
  2. Vaya a Configuración>Variables de entorno.
  3. Seleccione +Agregar.
  4. En Nombre , escriba PHP_INI_SCAN_DIR y, en Valor, escriba :/home/site/wwwroot/ini.
  5. Seleccione Aplicar y vuelva a aplicar . Confirme los cambios.

Nota:

Si ha vuelto a compilar una extensión PHP, como GD, siga los pasos descritos en Volver a compilar extensiones PHP.

Personalización de directivas de PHP_INI_SYSTEM

Para personalizar directivas PHP_INI_SYSTEM, use la configuración de aplicación PHP_INI_SCAN_DIR.

Primero, ejecute el siguiente comando para agregar una configuración de la aplicación llamada 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"

En Azure Portal, seleccione la aplicación. En Herramientas de desarrollo , en el menú de la barra lateral, seleccione Herramientas avanzadas y, a continuación, vaya a d:\home\site usar SSH.

Cree un directorio en d:\home\site denominado ini. A continuación, cree un archivo .ini en el d:\home\site\ini directorio, por ejemplo, settings.ini, con las directivas que desea personalizar. Use la misma sintaxis que usaría en un php.ini archivo.

Por ejemplo, para cambiar el valor de expose_php, ejecute los siguientes comandos:

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

Para que los cambios surtan efecto, reinicie la aplicación.

Para personalizar directivas PHP_INI_SYSTEM, no puede usar el enfoque de .htaccess. App Service proporciona un mecanismo independiente que usa la configuración de aplicación PHP_INI_SCAN_DIR.

Primero, ejecute el siguiente comando para agregar una configuración de la aplicación llamada 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"

El valor /usr/local/etc/php/conf.d es el directorio predeterminado donde php.ini existe. El valor /home/site/ini es el directorio personalizado en el que se agrega un archivo de.ini personalizado. Separa los valores con dos puntos (:).

Vaya a la sesión SSH web con su contenedor de Linux.

Cree un directorio en /home/site denominado ini. A continuación, cree un archivo .ini en el /home/site/ini directorio, por ejemplo, settings.ini, con las directivas que desea personalizar. Use la misma sintaxis que usaría en un php.ini archivo.

Sugerencia

Los contenedores integrados de Linux de App Service usan /home como almacenamiento compartido persistente.

Por ejemplo, para cambiar el valor de expose_php, ejecute los siguientes comandos:

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

Para que los cambios surtan efecto, reinicie la aplicación.

Habilitación de extensiones PHP

Las instalaciones PHP integradas contienen las extensiones más usadas. Puede habilitar extensiones adicionales en la misma forma que personaliza las directivas de php.ini.

Nota:

La mejor manera de ver la versión de PHP y la configuración actual php.ini es llamar a phpinfo() en tu aplicación.

Para habilitar otras extensiones, siga estos pasos:

  1. Agregue un bin directorio al directorio raíz de la aplicación y coloque en él los archivos de extensión .dll , por ejemplo, mongodb.dll. Asegúrese de que las extensiones son compatibles con la versión de PHP en Azure y que son compatibles con VC9 y que no son compatibles con subprocesos (NTS).

  2. Implemente los cambios.

  3. Siga los pasos descritos en Personalizar directivas PHP_INI_SYSTEM y agregue las extensiones al archivo de .ini personalizado con la directiva de extensión o zend_extension :

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

Para que los cambios surtan efecto, reinicie la aplicación.

Las instalaciones PHP integradas contienen las extensiones más usadas. Puede habilitar extensiones adicionales en la misma forma que personaliza las directivas de php.ini.

Nota:

La mejor manera de ver la versión de PHP y la configuración actual php.ini es llamar a phpinfo() en tu aplicación.

Para habilitar otras extensiones, siga estos pasos:

  1. Agregue un bin directorio al directorio raíz de la aplicación y coloque en él los archivos de extensión .so (por ejemplo, mongodb.so). Asegúrese de que las extensiones son compatibles con la versión de PHP en Azure y que son compatibles con VC9 y que no son compatibles con subprocesos (NTS).

  2. Implemente los cambios.

  3. Siga los pasos descritos en Personalizar directivas PHP_INI_SYSTEM y agregue las extensiones al archivo de .ini personalizado con la directiva de extensión o zend_extension :

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

Para que los cambios surtan efecto, reinicie la aplicación.

Acceso a los registros de diagnóstico

Use la herramienta estándar error_log() para que los registros de diagnóstico aparezcan en Azure App Service.

Para acceder a los registros de consola generados desde el código de la aplicación en App Service, active el registro de diagnóstico mediante la ejecución del siguiente comando en Cloud Shell:

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

Los valores posibles para --level son Error, Warning, Info y Verbose. Cada nivel subsiguiente incluye el nivel anterior. Por ejemplo, Error solo incluye mensajes de error. Verbose incluye todos los mensajes.

Después de activar el registro de diagnóstico, ejecute el siguiente comando para ver la secuencia de registro:

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

Si los registros de consola no aparecen inmediatamente, vuelva a comprobar en 30 segundos.

Para detener el streaming de registros en cualquier momento, seleccione Ctrl+C.

Puede acceder a los registros de consola generados desde dentro del contenedor.

Para activar el registro de contenedores, ejecute el siguiente comando:

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

Reemplace <app-name> y <resource-group-name> por los nombres adecuados para la aplicación web.

Después de activar el registro de contenedores, ejecute el siguiente comando para ver la secuencia de registro:

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

Si los registros de consola no aparecen inmediatamente, vuelva a comprobar en 30 segundos.

Para detener el streaming de registros en cualquier momento, seleccione Ctrl+C.

Solución de problemas

Cuando una aplicación PHP en funcionamiento se comporta de forma diferente en App Service o tiene errores, pruebe las siguientes soluciones:

  • Acceda a la secuencia de registros de diagnóstico.
  • Pruebe la aplicación localmente en modo de producción. App Service ejecuta la aplicación en modo de producción, por lo que debe asegurarse de que el proyecto funciona según lo previsto en el modo de producción localmente. Por ejemplo:
    • Dependiendo del composer.json archivo, es posible que se instalen paquetes diferentes para el modo de producción (require frente a require-dev).
    • Es posible que algunas plataformas web implementen archivos estáticos de forma diferente en modo de producción.
    • Es posible que algunas plataformas web usen scripts de inicio personalizados cuando se ejecutan en modo de producción.
  • Ejecute la aplicación en App Service en modo de depuración. Por ejemplo, en Laravel, puede configurar la aplicación para que genere mensajes de depuración en producción al configurar el ajuste de la aplicación APP_DEBUG en true.

Omitir el mensaje robots933456 en los registros

Es posible que vea el mensaje siguiente en los registros de contenedor:

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

Puede omitir este mensaje sin problemas. /robots933456.txt es una ruta URL ficticia que utiliza App Service para comprobar si el contenedor es capaz de procesar solicitudes. Una respuesta 404 indica que la ruta de acceso no existe y indica a App Service que el contenedor está en buen estado y listo para responder a las solicitudes.

Contenido relacionado