Sådan opsætter du separate PHP-FPM-puljer i NGINX

Oplysningerne i dette indlæg er baseret på NGINX 1.4.6 og PHP-FPM 5.5.9, der kører på Ubuntu Server 14.04 x64. Det er muligvis ikke gyldigt for andre versioner. (Opdatering: Jeg kan bekræfte, at fra og med Ubuntu Server 24.04, PHP-FPM 8.3 og NGINX 1.24.0 virker alle instruktionerne i dette indlæg stadig)

Der er en række fordele ved at opsætte flere PHP-FPM underordnede procespuljer i stedet for at køre alt i den samme pulje. Sikkerhed, adskillelse/isolation og ressourcestyring dukker op som nogle få vigtige ting.

Uanset hvad din motivation er, vil dette indlæg hjælpe dig med at gøre det :-)

Del 1 – Opsæt en ny PHP-FPM-pulje

Først skal du finde den mappe, hvor PHP-FPM gemmer sine pool-konfigurationer. På Ubuntu 14.04 er dette /etc/php5/fpm/pool.d som standard. Der er sandsynligvis allerede en fil der kaldet www.conf , som indeholder konfigurationen for standardpuljen. Hvis du ikke har kigget på den fil før, er der stor sandsynlighed for, at du skal gennemgå den og justere indstillingerne i den til din opsætning, da standardindstillingerne er for en server med ret understrøm, men foreløbig skal du bare lave en kopi af den, så vi ikke behøver at starte fra bunden:

Udskift selvfølgelig "mypool" med hvad du vil have din pool skal hedde.

Åbn nu den nye fil ved hjælp af nano eller hvilken som helst teksteditor, du foretrækker, og juster den, så den passer til dit formål. Du vil sikkert gerne justere på de underordnede procesnumre og eventuelt hvilken bruger og gruppe poolen kører under, men de to indstillinger, som du absolut skal ændre, er poolens navn og den socket, den lytter til, ellers vil den komme i konflikt med den eksisterende pool, og tingene holder op med at virke.

Navnet på poolen er tæt på toppen af ​​filen, omgivet af firkantede parenteser. Som standard er det [www] . Skift dette til hvad du vil; Jeg foreslår det samme som du navngav konfigurationsfilen, så for dette eksempels skyld skal du ændre den til [mypool] . Hvis du ikke ændrer det, ser det ud til, at PHP-FPM kun vil indlæse den første konfigurationsfil med det navn, hvilket sandsynligvis vil ødelægge tingene.

Du skal derefter ændre den stikkontakt eller adresse, du lytter til, hvilket er defineret af lyttedirektivet . Som standard bruger PHP-FPM Unix-sockets, så dit lyttedirektiv vil sandsynligvis se sådan ud:

Du kan ændre det til et hvilket som helst gyldigt navn, du ønsker, men igen, jeg foreslår, at du holder dig til noget, der ligner konfigurationsfilnavnet, så du for eksempel kan indstille det til:

OK, så gem filen og afslut teksteditoren.

Del 2 – Opdater konfigurationen af ​​den virtuelle NGINX-vært

Nu skal du åbne den virtuelle NGINX-værtsfil med den FastCGI-konfiguration, du vil ændre til en ny pool – eller rettere, oprette forbindelse til den nye socket.

Som standard på Ubuntu 14.04 er disse gemt under /etc/nginx/sites-available, men kan også defineres andre steder. Du ved nok bedst, hvor dine virtuelle værtskonfigurationer er placeret ;-)

Åbn den relevante konfigurationsfil i din foretrukne teksteditor og se efter fastcgi_pass- direktivet (som skal være i en lokalitetskontekst), der definerer PHP-FPM-socket. Du skal ændre denne værdi, så den matcher den nye PHP-FPM-puljekonfiguration, du lavede under trin et, så hvis du fortsætter vores eksempel, vil du ændre dette til:

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

Gem og luk derefter filen også. Du er næsten færdig nu.

Del 3 – Genstart PHP-FPM og NGINX

For at anvende de konfigurationsændringer, du har foretaget, skal du genstarte både PHP-FPM og NGINX. Det kan være nok at genindlæse i stedet for at genstarte , men jeg synes, det er en smule hit and miss, afhængig af hvilke indstillinger der ændres. I det særlige tilfælde ønskede jeg, at de gamle PHP-FPM underordnede processer skulle dø med det samme, så genstart af PHP-FPM var nødvendig, men for NGINX kan en genindlæsning være tilstrækkelig. Prøv det selv.

Og voila, du er færdig. Hvis du gjorde alt korrekt, skulle den virtuelle vært, du ændrede, nu bruge den nye PHP-FPM-pulje og ikke dele underordnede processer med andre virtuelle værter.