Como configurar pools PHP-FPM separados no NGINX

As informações neste post são baseadas no NGINX 1.4.6 e no PHP-FPM 5.5.9 a correr no Ubuntu Server 14.04 x64. Pode ou não ser válido para outras versões. (Actualização: posso confirmar que, a partir do Ubuntu Server 24.04, PHP-FPM 8.3 e NGINX 1.24.0, todas as instruções deste post ainda funcionam)

Há uma série de vantagens em configurar vários pools de processos filhos PHP-FPM em vez de executar tudo no mesmo pool. A segurança, a separação/isolamento e a gestão de recursos vêm à mente como alguns dos principais.

Não importa qual a sua motivação, este post vai ajudá-lo a fazê-lo :-)

Parte 1 – Configurar um novo pool PHP-FPM

Primeiro, precisa de localizar o diretório onde o PHP-FPM armazena as suas definições de pool. No Ubuntu 14.04, o ficheiro predefinido é /etc/php5/fpm/pool.d. Provavelmente já existe um ficheiro chamado www.conf , que contém a configuração do pool padrão. Se não olhou para este ficheiro antes, é provável que deva examiná-lo e ajustar as definições para a sua instalação, uma vez que os padrões são para um servidor com pouca potência, mas por enquanto, faça uma cópia dele para não termos de começar do zero:

Claro, substitua “mypool” pelo nome que pretende que o seu pool seja chamado.

Agora abra o novo ficheiro utilizando o nano ou qualquer editor de texto da sua preferência e ajuste-o de acordo com as suas necessidades. Provavelmente, vai querer ajustar os números do processo filho e possivelmente em que utilizador e grupo o pool é executado, mas as duas definições que tem absolutamente de alterar são o nome do pool e o socket que está a escutar, caso contrário, entrará em conflito com o pool existente e as coisas deixarão de funcionar.

O nome do pool está junto ao topo do ficheiro, entre parêntesis rectos. Por defeito é [www] . Altere isso para o que pretende; Sugiro que nomeie o ficheiro de configuração da mesma forma, por isso, para efeitos deste exemplo, altere-o para [mypool] . Se não o alterar, parece que o PHP-FPM apenas carregará o primeiro ficheiro de configuração com esse nome, o que provavelmente causará problemas.

Necessita então de alterar o socket ou endereço que está a escutar, que é definido pela diretiva listen . Por defeito, o PHP-FPM utiliza sockets Unix, pelo que a sua diretiva listen será provavelmente semelhante a esta:

Pode alterá-lo para qualquer nome válido que desejar, mas, mais uma vez, sugiro que utilize algo semelhante ao nome do ficheiro de configuração, para que possa, por exemplo, defini-lo como:

Muito bem, então guarde o ficheiro e saia do editor de texto.

Parte 2 – Atualizar a configuração do host virtual NGINX

Agora precisa de abrir o ficheiro do host virtual NGINX com a configuração FastCGI que pretende alterar para um novo pool – ou melhor, ligar-se ao novo socket.

Por defeito no Ubuntu 14.04, são armazenados em /etc/nginx/sites-available, mas também podem ser definidos noutro local. Provavelmente é melhor saber onde estão localizadas as suas definições de host virtual ;-)

Abra o ficheiro de configuração relevante no seu editor de texto favorito e procure a diretiva fastcgi_pass (que deve estar num contexto de localização) que define o socket PHP-FPM. Deve alterar este valor para que corresponda à nova configuração do pool PHP-FPM feita no passo um.

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

Depois guarde e feche também esse ficheiro. Está quase a terminar agora.

Parte 3 – Reinicie o PHP-FPM e o NGINX

Para aplicar as alterações de configuração efetuadas, reinicie o PHP-FPM e o NGINX. Pode ser suficiente recarregar em vez de reiniciar , mas acho que é um pouco impreciso, dependendo de quais as definições que são alteradas. No caso específico, eu queria que os antigos processos filhos do PHP-FPM morressem imediatamente, pelo que reiniciar o PHP-FPM era necessário, mas para o NGINX uma recarga pode ser suficiente. Experimente você mesmo.

E pronto, está pronto. Se fez tudo corretamente, o host virtual que modificou deve agora estar a utilizar o novo pool PHP-FPM e não partilhar processos filho com qualquer outro host virtual.