Hur man ställer in separata PHP-FPM-pooler i NGINX

Informationen i detta inlägg är baserad på NGINX 1.4.6 och PHP-FPM 5.5.9 som körs på Ubuntu Server 14.04 x64. Det kan eller kanske inte är giltigt för andra versioner. (Uppdatering: Jag kan bekräfta att från och med Ubuntu Server 24.04, PHP-FPM 8.3 och NGINX 1.24.0 fungerar alla instruktioner i det här inlägget fortfarande)

Det finns ett antal fördelar med att ställa in flera PHP-FPM underordnade processpooler istället för att köra allt i samma pool. Säkerhet, separation/isolering och resurshantering dyker upp som några viktiga saker.

Oavsett vad din motivation är, kommer det här inlägget att hjälpa dig att göra det :-)

Del 1 – Skapa en ny PHP-FPM-pool

Först måste du hitta katalogen där PHP-FPM lagrar sina poolkonfigurationer. På Ubuntu 14.04 är detta /etc/php5/fpm/pool.d som standard. Det finns förmodligen redan en fil där som heter www.conf , som innehåller konfigurationen för standardpoolen. Om du inte har tittat på den filen innan är chansen stor att du bör gå igenom den och justera inställningarna i den för din installation eftersom standardinställningarna är för en ganska underdriven server, men för nu är det bara att göra en kopia av den så att vi inte behöver börja från början:

Byt självklart ut "mypool" med vad du vill att din pool ska heta.

Öppna nu den nya filen med nano eller vilken textredigerare du föredrar och justera den för att passa ditt syfte. Du kommer antagligen att vilja justera underordnade processnummer och eventuellt vilken användare och grupp poolen körs under, men de två inställningarna som du absolut måste ändra är poolens namn och socket den lyssnar på, annars kommer den att komma i konflikt med den befintliga poolen och saker och ting kommer att sluta fungera.

Namnet på poolen är nära toppen av filen, omsluten av hakparenteser. Som standard är det [www] . Ändra detta till vad du vill; Jag föreslår samma sak som du namngav konfigurationsfilen, så för detta exempels skull ändra den till [mypool] . Om du inte ändrar det verkar det som att PHP-FPM bara kommer att ladda den första konfigurationsfilen med det namnet, vilket sannolikt kommer att bryta saker.

Du behöver då byta uttaget eller adressen du lyssnar på, vilket definieras av lyssningsdirektivet . Som standard använder PHP-FPM Unix-sockets så ditt lyssningsdirektiv kommer förmodligen att se ut så här:

Du kan ändra det till vilket giltigt namn du vill, men återigen, jag föreslår att du håller dig till något som liknar konfigurationsfilnamnet, så att du till exempel kan ställa in det till:

Okej, spara filen och avsluta textredigeraren.

Del 2 – Uppdatera konfigurationen av den virtuella NGINX-värden

Nu måste du öppna den virtuella NGINX-värdfilen med den FastCGI-konfiguration du vill ändra till en ny pool – eller snarare ansluta till den nya sockeln.

Som standard på Ubuntu 14.04 lagras dessa under /etc/nginx/sites-available, men kan även definieras på annat håll. Du vet förmodligen bäst var dina virtuella värdkonfigurationer finns ;-)

Öppna den relevanta konfigurationsfilen i din favorittextredigerare och leta efter fastcgi_pass- direktivet (som måste vara i en platskontext) som definierar PHP-FPM-socket. Du måste ändra detta värde så att det matchar den nya PHP-FPM-poolkonfigurationen du gjorde under steg ett, så om du fortsätter med vårt exempel skulle du ändra detta till:

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

Spara och stäng sedan den filen också. Du är nästan klar nu.

Del 3 – Starta om PHP-FPM och NGINX

För att tillämpa de konfigurationsändringar du har gjort, starta om både PHP-FPM och NGINX. Det kan räcka med att ladda om istället för att starta om , men jag tycker att det är lite hit and miss, beroende på vilka inställningar som ändras. I det specifika fallet ville jag att de gamla PHP-FPM underordnade processerna skulle dö direkt, så att starta om PHP-FPM behövdes, men för NGINX kan en omladdning vara tillräcklig. Prova det själv.

Och voila, du är klar. Om du gjorde allt korrekt bör den virtuella värden du modifierade nu använda den nya PHP-FPM-poolen och inte dela underordnade processer med några andra virtuella värdar.