Hvordan sette opp separate PHP-FPM-pooler i NGINX
Publisert: 15. februar 2025 kl. 11:52:46 UTC
Sist oppdatert: 13. september 2025 kl. 22:52:55 UTC
I denne artikkelen går jeg gjennom konfigurasjonstrinnene som trengs for å kjøre flere PHP-FPM-bassenger og koble NGINX til dem via FastCGI, noe som muliggjør prosessseparasjon og isolering mellom virtuelle verter.
How to Set Up Separate PHP-FPM Pools in NGINX
Informasjonen i dette innlegget er basert på NGINX 1.4.6 og PHP-FPM 5.5.9 som kjører på Ubuntu Server 14.04 x64. Det kan være gyldig for andre versjoner. (Oppdatering: Jeg kan bekrefte at fra og med Ubuntu Server 24.04, PHP-FPM 8.3 og NGINX 1.24.0, fungerer alle instruksjonene i dette innlegget fortsatt)
Det er en rekke fordeler med å sette opp flere PHP-FPM-underordnede prosessbassenger i stedet for å kjøre alt i samme pool. Sikkerhet, separasjon/isolasjon og ressursstyring dukker opp som noen få viktigste.
Uansett hva motivasjonen din er, vil dette innlegget hjelpe deg med det :-)
Del 1 – Sett opp et nytt PHP-FPM-basseng
Først må du finne katalogen der PHP-FPM lagrer bassengkonfigurasjonene. På Ubuntu 14.04 er dette /etc/php5/fpm/pool.d som standard. Det er sannsynligvis allerede en fil der som heter www.conf, som inneholder oppsettet for standardutvalget. Hvis du ikke har sett på den filen før, er sjansen stor for at du bør gå gjennom den og justere innstillingene i den for oppsettet ditt, da standardinnstillingene er for en ganske underdrevet server, men foreløpig er det bare å lage en kopi av den slik at vi ikke trenger å starte fra bunnen av:
Bytt selvfølgelig ut "mypool" med det du vil at bassenget ditt skal hete.
Åpne nå den nye filen ved hjelp av nano eller hvilket som helst tekstredigeringsprogram du foretrekker, og juster den for å passe ditt formål. Du vil sannsynligvis justere de underordnede prosessnumrene og muligens hvilken bruker og gruppe bassenget kjører under, men de to innstillingene du absolutt må endre er bassengets navn og kontakten det lytter til, ellers vil det komme i konflikt med det eksisterende bassenget og ting vil slutte å fungere.
Navnet på bassenget er nær toppen av filen, omsluttet av hakeparenteser. Som standard er det [www]. Endre dette til hva du vil; Jeg foreslår det samme som du kalte oppsettsfilen, så for dette eksemplets skyld endre den til [mypool]. Hvis du ikke endrer det, ser det ut til at PHP-FPM bare vil laste den første konfigurasjonsfilen med det navnet, noe som sannsynligvis vil ødelegge ting.
Du må da endre kontakten eller adressen du lytter til, som er definert av lyttedirektivet . Som standard bruker PHP-FPM Unix-sockets, så lyttedirektivet ditt vil sannsynligvis se slik ut:
Du kan endre det til hvilket som helst gyldig navn du vil, men igjen, jeg foreslår at du holder deg til noe som ligner på oppsettsfilnavnet, slik at du for eksempel kan sette det til:
Greit, lagre deretter filen og avslutt tekstredigeringsprogrammet.
Del 2 - Oppdater NGINX virtuell vertskonfigurasjon
Nå må du åpne den virtuelle NGINX-vertsfilen med FastCGI-konfigurasjonen du vil endre til et nytt basseng – eller rettere sagt, koble til den nye kontakten.
Som standard på Ubuntu 14.04 er disse lagret under /etc/nginx/sites-available, men kan også defineres andre steder. Du vet sannsynligvis best hvor dine virtuelle vertskonfigurasjoner er plassert ;-)
Åpne den relevante konfigurasjonsfilen i ditt favoritttekstredigeringsprogram og se etter det fastcgi_pass direktivet (som må være i en plasseringskontekst) som definerer PHP-FPM-kontakten. Du må endre denne verdien slik at den samsvarer med den nye PHP-FPM-poolkonfigurasjonen du laget under trinn én, så hvis du fortsetter eksemplet vårt, vil du endre dette til:
fastcgi_pass unix:/var/run/php5-fpm-mypool.sock;
Lagre og lukk deretter filen også. Du er nesten ferdig nå.
Del 3 - Start PHP-FPM og NGINX på nytt
For å bruke konfigurasjonsendringene du har gjort, start både PHP-FPM og NGINX på nytt. Det kan være nok å laste inn på nytt i stedet for å starte på nytt, men jeg synes det er litt hit and miss, avhengig av hvilke innstillinger som endres. I det spesielle tilfellet ønsket jeg at de gamle PHP-FPM-barneprosessene skulle dø med en gang, så det var nødvendig å starte PHP-FPM på nytt, men for NGINX kan en omlasting være tilstrekkelig. Prøv det selv.
sudo service nginx restart
Og voila, du er ferdig. Hvis du gjorde alt riktig, skal den virtuelle verten du endret nå bruke det nye PHP-FPM-bassenget og ikke dele underordnede prosesser med andre virtuelle verter.