Cómo configurar grupos PHP-FPM separados en NGINX

La información de esta publicación se basa en NGINX 1.4.6 y PHP-FPM 5.5.9 ejecutándose en Ubuntu Server 14.04 x64. Puede que sea válida para otras versiones. (Actualización: Confirmo que, a partir de Ubuntu Server 24.04, PHP-FPM 8.3 y NGINX 1.24.0, todas las instrucciones de esta publicación siguen funcionando).

Configurar varios grupos de procesos secundarios PHP-FPM ofrece varias ventajas en lugar de ejecutar todo en el mismo grupo. Entre las principales se encuentran la seguridad, la separación/aislamiento y la gestión de recursos.

Sea cual sea tu motivación, este post te ayudará a lograrlo :-)

Parte 1: Configurar un nuevo pool PHP-FPM

Primero, necesitas localizar el directorio donde PHP-FPM almacena las configuraciones del pool. En Ubuntu 14.04, este es /etc/php5/fpm/pool.d por defecto. Probablemente ya exista un archivo llamado www.conf, que contiene la configuración del pool predeterminado. Si no has consultado ese archivo antes, probablemente deberías revisarlo y ajustar la configuración para tu configuración, ya que los valores predeterminados son para un servidor con poca potencia. Por ahora, simplemente haz una copia para no tener que empezar desde cero:

Por supuesto, reemplaza “mypool” con el nombre que quieras que se le dé a tu pool.

Ahora abra el nuevo archivo con nano o el editor de texto que prefiera y ajústelo para que se ajuste a sus necesidades. Probablemente quiera ajustar la cantidad de procesos secundarios y posiblemente el usuario y grupo bajo el que se ejecuta el grupo, pero los dos ajustes que debe cambiar son el nombre del grupo y el socket al que escucha; de lo contrario, entrará en conflicto con el grupo existente y dejará de funcionar.

El nombre del pool se encuentra casi al principio del archivo, entre corchetes. Por defecto, es [www]. Cámbialo como prefieras; te sugiero que uses el mismo nombre que el del archivo de configuración, así que, para este ejemplo, cámbialo a [mypool]. Si no lo cambias, parece que PHP-FPM solo cargará el primer archivo de configuración con ese nombre, lo que probablemente genere problemas.

A continuación, debe cambiar el socket o la dirección que está escuchando, definidos por la directiva listen. Por defecto, PHP-FPM usa sockets Unix, por lo que su directiva listen probablemente se verá así:

Puedes cambiarlo a cualquier nombre válido que desees, pero nuevamente, te sugiero que te quedes con algo similar al nombre del archivo de configuración, por lo que podrías, por ejemplo, configurarlo como:

Muy bien, guarde el archivo y salga del editor de texto.

Parte 2: Actualizar la configuración del host virtual NGINX

Ahora debe abrir el archivo de host virtual NGINX con la configuración FastCGI que desea cambiar a un nuevo grupo, o mejor dicho, conectarse al nuevo socket.

Por defecto en Ubuntu 14.04, estos se almacenan en /etc/nginx/sites-available, pero también se pueden definir en otro lugar. Probablemente ya sepas dónde se encuentran tus configuraciones de host virtual ;-)

Abra el archivo de configuración correspondiente en su editor de texto favorito y busque la directiva fastcgi_pass (que debe estar en un contexto de ubicación) que define el socket PHP-FPM. Debe cambiar este valor para que coincida con la nueva configuración del grupo PHP-FPM que realizó en el paso 1. Siguiendo con nuestro ejemplo, cámbielo a:

Fastcgi_pass unix:/var/run/php5-fpm-mypool.sock;

Luego, guarda y cierra ese archivo también. Ya casi terminas.

Parte 3: Reiniciar PHP-FPM y NGINX

Para aplicar los cambios de configuración, reinicie PHP-FPM y NGINX. Puede que sea suficiente con recargar en lugar de reiniciar, pero me parece que es un poco impredecible, dependiendo de la configuración modificada. En este caso, quería que los procesos secundarios antiguos de PHP-FPM se cerraran de inmediato, por lo que fue necesario reiniciar PHP-FPM; sin embargo, para NGINX, recargar podría ser suficiente. Pruébelo usted mismo.

Y listo, ya está. Si hiciste todo correctamente, el host virtual que modificaste debería usar el nuevo pool PHP-FPM y no compartir procesos secundarios con otros hosts virtuales.