NGINX에서 별도의 PHP-FPM 풀을 설정하는 방법
게시됨: 2025년 2월 15일 오전 11시 52분 42초 UTC
이 문서에서는 여러 개의 PHP-FPM 풀을 실행하고 FastCGI를 통해 NGINX를 연결하여 가상 호스트 간의 프로세스 분리 및 격리를 허용하는 데 필요한 구성 단계를 살펴봅니다.
How to Set Up Separate PHP-FPM Pools in NGINX
이 게시물의 정보는 Ubuntu Server 14.04 x64에서 실행되는 NGINX 1.4.6 및 PHP-FPM 5.5.9를 기반으로 합니다. 다른 버전에는 유효할 수도 있고 그렇지 않을 수도 있습니다. (업데이트: Ubuntu Server 24.04, PHP-FPM 8.3 및 NGINX 1.24.0부터 이 게시물의 모든 지침이 여전히 작동한다는 것을 확인할 수 있습니다.)
모든 것을 동일한 풀에서 실행하는 것보다 여러 PHP-FPM 자식 프로세스 풀을 설정하는 데는 여러 가지 이점이 있습니다. 보안, 분리/격리 및 리소스 관리가 몇 가지 주요 사항으로 떠오릅니다.
당신의 동기가 무엇이든, 이 글이 당신이 그 동기를 갖도록 도울 것입니다 :-)
1부 – 새로운 PHP-FPM 풀 설정
먼저 PHP-FPM이 풀 구성을 저장하는 디렉토리를 찾아야 합니다. Ubuntu 14.04에서는 기본적으로 /etc/php5/fpm/pool.d입니다. 아마도 www.conf 라는 파일이 이미 있을 것입니다. 여기에는 기본 풀의 구성이 들어 있습니다. 해당 파일을 살펴보지 않았다면 아마도 해당 파일을 살펴보고 설정에 맞게 설정을 조정해야 할 것입니다. 기본값은 성능이 상당히 낮은 서버에 대한 것이지만 지금은 처음부터 시작하지 않아도 되도록 복사본을 만드십시오.
물론, "mypool"을 원하는 이름으로 바꿔도 됩니다.
이제 nano나 원하는 텍스트 편집기를 사용하여 새 파일을 열고 목적에 맞게 조정합니다. 아마도 자식 프로세스 번호와 풀이 실행되는 사용자 및 그룹을 조정하고 싶을 것입니다. 하지만 반드시 변경해야 하는 두 가지 설정은 풀 이름과 수신하는 소켓입니다. 그렇지 않으면 기존 풀과 충돌하여 작동이 중단됩니다.
풀의 이름은 파일 맨 위에 있으며, 대괄호로 묶습니다. 기본값은 [www] 입니다. 원하는 대로 변경하세요. 저는 구성 파일 이름을 지정한 것과 동일하게 하는 것을 제안하므로 이 예제에서는 [mypool] 로 변경합니다. 변경하지 않으면 PHP-FPM이 해당 이름을 가진 첫 번째 구성 파일만 로드하는 듯하며, 이로 인해 문제가 발생할 가능성이 높습니다.
그런 다음 listen 지시문에 정의된 수신 대기 중인 소켓 또는 주소를 변경해야 합니다. 기본적으로 PHP-FPM은 Unix 소켓을 사용하므로 listen 지시문은 아마도 다음과 같을 것입니다.
원하는 유효한 이름으로 변경할 수 있지만, 다시 한번 말하지만, 설정 파일 이름과 비슷한 것을 고수하는 것이 좋습니다. 예를 들어 다음과 같이 설정할 수 있습니다.
좋습니다, 그러면 파일을 저장하고 텍스트 편집기를 종료하세요.
2부 – NGINX 가상 호스트 구성 업데이트
이제 변경하려는 FastCGI 구성으로 NGINX 가상 호스트 파일을 새 풀로 열거나 새 소켓에 연결해야 합니다.
기본적으로 Ubuntu 14.04에서는 /etc/nginx/sites-available에 저장되지만 다른 곳에서 정의할 수도 있습니다. 가상 호스트 구성이 어디에 있는지 아는 것이 가장 좋습니다 ;-)
좋아하는 텍스트 편집기에서 관련 구성 파일을 열고 PHP-FPM 소켓을 정의하는 fastcgi_pass 지시문(위치 컨텍스트에 있어야 함)을 찾습니다. 1단계에서 만든 새 PHP-FPM 풀 구성과 일치하도록 이 값을 변경해야 하므로 예를 계속하면 다음과 같이 변경합니다.
fastcgi_pass 유닉스:/var/run/php5-fpm-mypool.sock;
그런 다음 해당 파일도 저장하고 닫습니다. 이제 거의 끝났습니다.
3부 – PHP-FPM 및 NGINX 다시 시작
변경한 설정을 적용하려면 PHP-FPM과 NGINX를 모두 다시 시작합니다. restart 대신 reload 로 충분할 수 있지만 , 어떤 설정을 변경하는지에 따라 약간 엉뚱한 느낌이 듭니다. 이 특정한 사례에서, 저는 오래된 PHP-FPM 자식 프로세스를 바로 종료하고 싶었기 때문에 PHP-FPM을 다시 시작해야 했지만, NGINX의 경우 reload로 충분할 수 있습니다. 직접 시도해 보세요.
sudo service nginx restart
그리고 짜잔, 끝났습니다. 모든 것을 올바르게 했다면, 수정한 가상 호스트는 이제 새로운 PHP-FPM 풀을 사용하고 다른 가상 호스트와 자식 프로세스를 공유하지 않을 것입니다.