Jak skonfigurować oddzielne pule PHP-FPM w NGINX
Opublikowano: 15 lutego 2025 11:52:50 UTC
Ostatnia aktualizacja: 12 stycznia 2026 08:30:03 UTC
W tym artykule omówię kroki konfiguracji niezbędne do uruchomienia wielu pul PHP-FPM i połączenia z nimi NGINX za pośrednictwem FastCGI, co pozwala na separację procesów i izolację między hostami wirtualnymi.
How to Set Up Separate PHP-FPM Pools in NGINX
Informacje w tym poście dotyczą NGINX 1.4.6 i PHP-FPM 5.5.9 działających na Ubuntu Server 14.04 x64. Mogą być one aktualne dla innych wersji, ale nie muszą. (Aktualizacja: Potwierdzam, że w Ubuntu Server 24.04, PHP-FPM 8.3 i NGINX 1.24.0 wszystkie instrukcje w tym poście nadal działają).
Konfigurowanie wielu pul procesów potomnych PHP-FPM ma szereg zalet w porównaniu z uruchamianiem wszystkich w jednej puli. Wśród najważniejszych wymienia się bezpieczeństwo, separację/izolację i zarządzanie zasobami.
Niezależnie od tego, jaka jest Twoja motywacja, ten post pomoże Ci ją osiągnąć :-)
Część 1 – Konfiguracja nowego puli PHP-FPM
Najpierw musisz zlokalizować katalog, w którym PHP-FPM przechowuje konfiguracje puli. W Ubuntu 14.04 domyślnie jest to /etc/php5/fpm/pool.d. Prawdopodobnie znajduje się tam już plik o nazwie www.conf, który zawiera konfigurację domyślnej puli. Jeśli jeszcze nie zaglądałeś do tego pliku, prawdopodobnie powinieneś go przejrzeć i dostosować ustawienia do swojej konfiguracji, ponieważ domyślne ustawienia są przeznaczone dla dość słabego serwera. Na razie po prostu zrób jego kopię, żebyśmy nie musieli zaczynać od nowa:
Oczywiście, zastąp „mypool” nazwą, jaką chcesz nadać puli.
Teraz otwórz nowy plik za pomocą nano lub dowolnego innego edytora tekstu i dostosuj go do swoich potrzeb. Prawdopodobnie będziesz chciał zmienić numery procesów potomnych, a być może także użytkownika i grupę, w której działa pula. Dwa ustawienia, które musisz bezwzględnie zmienić, to nazwa puli i gniazdo, na którym nasłuchuje. W przeciwnym razie wystąpi konflikt z istniejącą pulą i wszystko przestanie działać.
Nazwa puli znajduje się na górze pliku, w nawiasach kwadratowych. Domyślnie to [www]. Zmień ją na dowolną inną; sugeruję nazwę taką samą, jaką nadałeś plikowi konfiguracyjnemu, więc na potrzeby tego przykładu zmień ją na [mypool]. Jeśli tego nie zmienisz, PHP-FPM prawdopodobnie załaduje tylko pierwszy plik konfiguracyjny o tej nazwie, co prawdopodobnie spowoduje problemy.
Następnie musisz zmienić gniazdo lub adres, którego nasłuchujesz, co jest zdefiniowane w dyrektywie „listening”. Domyślnie PHP-FPM używa gniazd Unix, więc Twoja dyrektywa „listening” prawdopodobnie będzie wyglądać tak:
Możesz zmienić ją na dowolną inną, prawidłową nazwę, ale ponownie sugeruję pozostanie przy czymś podobnym do nazwy pliku konfiguracyjnego, więc możesz na przykład ustawić ją tak:
Dobrze, zapisz plik i wyjdź z edytora tekstu.
Część 2 – Aktualizacja konfiguracji wirtualnego hosta NGINX
Teraz musisz otworzyć plik wirtualnego hosta NGINX z konfiguracją FastCGI, którą chcesz zmienić na nową pulę – lub raczej połączyć się z nowym gniazdem.
Domyślnie w Ubuntu 14.04 są one przechowywane w katalogu /etc/nginx/sites-available, ale można je również zdefiniować w innym miejscu. Prawdopodobnie najlepiej wiesz, gdzie znajdują się konfiguracje hostów wirtualnych ;-)
Otwórz odpowiedni plik konfiguracyjny w swoim ulubionym edytorze tekstu i poszukaj dyrektywy fastcgi_pass (która musi być w kontekście lokalizacji) definiującej gniazdo PHP-FPM. Musisz zmienić tę wartość, aby odpowiadała nowej konfiguracji puli PHP-FPM utworzonej w kroku pierwszym, więc kontynuując nasz przykład, zmień ją na:
Fastcgi_pass unix:/var/run/php5-fpm-mypool.sock;
Następnie zapisz i zamknij również ten plik. Już prawie gotowe.
Część 3 – Ponowne uruchomienie PHP-FPM i NGINX
Aby zastosować wprowadzone zmiany konfiguracji, zrestartuj zarówno PHP-FPM, jak i NGINX. Przeładowanie zamiast restartu może wystarczyć, ale moim zdaniem jest to trochę niepewne, w zależności od tego, które ustawienia zostały zmienione. W tym konkretnym przypadku chciałem, aby stare procesy potomne PHP-FPM natychmiast przestały działać, więc konieczne było ponowne uruchomienie PHP-FPM, ale w przypadku NGINX przeładowanie może być wystarczające. Wypróbuj to sam.
sudo service nginx restart
I voilà, gotowe. Jeśli wszystko zrobiłeś poprawnie, zmodyfikowany wirtualny host powinien teraz korzystać z nowej puli PHP-FPM i nie współdzielić procesów potomnych z żadnym innym wirtualnym hostem.
