Hvordan sette opp separate PHP-FPM-pooler i NGINX
Publisert: 15. februar 2025 kl. 11:52:46 UTC
I denne artikkelen går jeg over konfigurasjonstrinnene som trengs for å kjøre flere PHP-FPM-pooler og koble NGINX til dem via FastCGI, noe som muliggjør prosessskillelse og isolasjon 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 eller ikke 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 ved å sette opp flere PHP-FPM underordnede prosesspooler i stedet for å kjøre alt i samme pool. Sikkerhet, separasjon/isolasjon og ressursstyring dukker opp i tankene som noen av de viktigste.
Uansett hva motivasjonen din er, vil dette innlegget hjelpe deg med det :-)
Del 1 – Sett opp en ny PHP-FPM-pool
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 kalt www.conf , som inneholder konfigurasjonen for standardpoolen. 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 ettersom standardinnstillingene er for en server med ganske lite kraft, 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 å bruke nano eller hvilken tekstredigerer du foretrekker, og juster den for å passe til formålet ditt. Du vil sannsynligvis ønske å justere barneprosessnumrene og muligens hvilken bruker og gruppe bassenget kjører under, men de to innstillingene som du absolutt må endre er bassengets navn og kontakten det lytter til, ellers vil det komme i konflikt med eksisterende basseng og ting vil slutte å fungere.
Navnet på bassenget er nær toppen av filen, omsluttet av firkantede parenteser. Som standard er det [www] . Endre dette til hva du vil; Jeg foreslår det samme som du kalte konfigurasjonsfilen, 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 gyldig navn du vil, men igjen, jeg foreslår at du holder deg til noe som ligner på konfigurasjonsfilnavnet, slik at du for eksempel kan sette det til:
OK, lagre filen og gå ut av 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 din favoritt tekstredigerer og se etter fastcgi_pass -direktivet (som må være i en stedskontekst) som definerer PHP-FPM-kontakten. Du må endre denne verdien slik at den samsvarer med den nye PHP-FPM bassengkonfigurasjonen du laget under trinn én, så hvis du fortsetter med vårt eksempel, 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 på nytt i stedet for å starte på nytt , men jeg synes det er litt truffet, avhengig av hvilke innstillinger som endres. I det spesielle tilfellet ønsket jeg at de gamle PHP-FPM underordnede prosessene 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 vips, du er ferdig. Hvis du gjorde alt riktig, bør den virtuelle verten du modifiserte nå bruke den nye PHP-FPM-poolen og ikke dele underordnede prosesser med andre virtuelle verter.