NGINX로 PHP-FPM을 구성하는 방법
PHP-FPM(FastCGI Process Manager)은 트래픽이 많은 사이트에 유용한 몇 가지 추가 기능이 있는 PHP의 FastCGI 구현에 대한 대안입니다. 이것은 NGINX로 PHP 페이지를 처리하는 데 선호되는 방법이며 PHP 스크립트를 실행하기 위한 SUPHP 또는 mod_php
와 같은 기존 CGI 기반 방법보다 빠릅니다. PHP-FPM을 사용하는 주요 이점은 PHP를 실행하는 다른 방법과 비교할 때 상당히 적은 양의 메모리와 CPU를 사용한다는 것입니다. 주된 이유는 PHP를 악마화하여 PHP 요청을 관리하기 위한 CLI 스크립트를 제공하면서 백그라운드 프로세스로 변환하기 때문입니다.
PHP-FPM NGINX 구성 전제 조건
- 루트 또는 sudo 활성화 사용자를 사용하여 Ubuntu 18.04 시스템에 대한 SSH 세션을 열 수 있습니다.
- Ubuntu 18.04 시스템에 이미 NGINX와 PHP를 설치했습니다.
NGINX PHP-FPM 구성 단계
- PHP-FPM 설치
- PHP-FPM 풀 구성
- PHP-FPM용 NGINX 구성
- NGINX PHP-FPM 구성 테스트
1. PHP-FPM 설치
Nginx는 자체 PHP 스크립트를 실행하는 방법을 모릅니다. PHP 스크립트를 효율적으로 관리하려면 PHP-FPM과 같은 PHP 모듈이 필요합니다. 반면에 PHP-FPM은 자체 프로세스를 생성하여 NGINX 환경 외부에서 실행됩니다. 따라서 사용자가 PHP 페이지를 요청하면 nginx 서버는 FastCGI를 사용하여 요청을 PHP-FPM 서비스로 전달합니다. Ubuntu 18.04의 php-fpm 설치는 PHP 및 해당 버전에 따라 다릅니다. 서버에 FPM 설치를 진행하기 전에 설치된 PHP 문서를 확인하십시오. 최신 PHP 7.3을 이미 설치했다고 가정하면 다음 apt-get 명령을 사용하여 FPM을 설치할 수 있습니다.
# apt-get install php7.3-fpm
설치가 끝나면 FPM 서비스가 자동으로 시작됩니다. 다음 systemd 명령을 사용하여 확인할 수 있습니다.
# systemctl status php7.3-fpm
● php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-02-17 06:29:31 UTC; 30s ago
Docs: man:php-fpm7.3(8)
Main PID: 32210 (php-fpm7.3)
Status: "Processes active: 0, idle: 2, Requests: 0, slow: 0, Traffic: 0req/sec"
Tasks: 3 (limit: 1152)
CGroup: /system.slice/php7.3-fpm.service
├─32210 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
├─32235 php-fpm: pool www
└─32236 php-fpm: pool www
2. PHP-FPM 풀 구성
php-fpm 서비스는 /etc/php/7.3/fpm/pool.d
폴더에서 찾을 수 있는 구성(www.conf)인 기본 풀을 만듭니다. 요구 사항에 따라 기본 풀을 사용자 지정할 수 있습니다. 그러나 각 FPM 프로세스에 대한 리소스 할당을 더 잘 제어하기 위해 별도의 풀을 만드는 것이 표준 관행입니다. 또한 FPM 풀을 분리하면 자체 마스터 프로세스를 생성하여 독립적으로 실행할 수 있습니다. 즉, 각 PHP 애플리케이션은 PHP-FPM을 사용하여 자체 캐시 설정으로 구성할 수 있습니다. 한 풀의 구성을 변경해도 나머지 FPM 풀을 시작하거나 중지할 필요가 없습니다. 별도의 사용자를 통해 PHP 애플리케이션을 효과적으로 실행하기 위한 FPM 풀을 생성해 보겠습니다. 먼저 이 풀에 대한 독점 권한을 가질 새 사용자를 만듭니다.
# groupadd wordpress_user
# useradd -g wordpress_user wordpress_user
이제 FPM 구성 디렉토리로 이동하고 vi와 같이 선호하는 텍스트 편집기를 사용하여 구성 파일을 생성합니다.
# cd /etc/php/7.3/fpm/pool.d
# vi wordpress_pool.conf
[wordpress_site]
user = wordpress_user
group = wordpress_user
listen = /var/run/php7.2-fpm-wordpress-site.sock
listen.owner = www-data
listen.group = www-data
php_admin_value[disable_functions] = exec,passthru,shell_exec,system
php_admin_flag[allow_url_fopen] = off
; Choose how the process manager will control the number of child processes.
pm = dynamic
pm.max_children = 75
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.process_idle_timeout = 10s
위의 FPM 구성 옵션 및 해당 값은 아래에 설명되어 있습니다.
- [wordpress_site]: 풀의 이름이며 모든 풀 이름에서 고유해야 합니다.
- 사용자 및 그룹: 풀이 실행될 사용자 및 그룹입니다.
- listen: 이 풀에 대한 소켓 파일의 이름입니다.
- listen.owner 및 listen.group: NGINX가 실행 중인 사용자 및 그룹과 일치해야 합니다. 우리의 경우에는 www-data입니다.
- php_admin_value: 사용자 지정 php 구성 값을 설정할 수 있습니다.
- php_admin_flag: PHP 부울 플래그를 설정할 수 있습니다.
- pm: 프로세스 관리자 설정 및 값이 Dynamic인 경우 하위 프로세스 수가 다음 지시문에 따라 동적으로 설정됨을 의미합니다.
- pm.max_children: 동시에 살아 있을 수 있는 최대 자식 수입니다.
- pm.start_servers: 시작 시 생성된 자식 수입니다.
- pm.min_spare_servers: '유휴' 상태(처리 대기 중)의 최소 하위 수입니다. 유휴 프로세스 수가 이 수보다 적으면 일부 자식이 생성됩니다.
- pm.max_spare_servers: 유휴 상태(처리 대기)에 있는 최대 하위 수입니다. 유휴 프로세스 수가 이 수보다 크면 일부 자식이 종료됩니다.
- pm.process_idle_timeout: 원하는 최대 유휴 서버 프로세스 수입니다. pm 값이 dynamic으로 설정된 경우에만 사용됩니다. 위의 설정 외에도
env[PHP_FOO] = $bar
와 같은 것을 사용하여 몇 가지 시스템 환경 변수를 php-fpm 서비스에 전달할 수도 있습니다. 예를 들어 위의 구성 파일에 다음 옵션을 추가하면 호스트 이름과 임시 폴더 위치가 PHP 환경으로 설정됩니다.
...
...
env[HOSTNAME] = $HOSTNAME
env[TMP] = /tmp
...
...
또한 위의 풀 구성 파일의 프로세스 관리자 설정은 dynamic으로 설정됩니다. 요구 사항에 가장 적합한 설정을 선택하십시오. 프로세스 관리자의 다른 구성 옵션은 다음과 같습니다. 정적: 고정된 수의 PHP 프로세스가 유지됩니다.
- 주문형: 시작 시 하위 항목이 생성되지 않습니다. 서버에서 새로운 요청이 수신되면 자식이 분기됩니다.
위의 구성 파일 생성이 완료되면 fpm 서비스를 다시 시작하여 새 설정을 적용합니다.
# systemctl start php7.3-fpm
FPM 풀은 PHP 페이지를 제공하기 위해 즉시 생성됩니다. 위의 FPM 구성 파일을 지정하여 다른 풀에 영향을 주지 않고 이 풀을 시작/중지할 수 있도록 하여 별도의 systemd 서비스를 만들 수 있습니다.
3. PHP-FPM용 NGINX 구성
이제 위의 FPM 풀을 사용할 NGINX 서버 블록을 만듭니다. 그렇게 하려면 NGINX 구성 파일을 편집하고 php의 위치 블록 내에서 fastcgi_pass
옵션을 사용하여 풀의 소켓 파일 경로를 전달하십시오.
server {
listen 80;
server_name example.journaldev.com;
root /var/www/html/wordpress;
access_log /var/log/nginx/example.journaldev.com-access.log;
error_log /var/log/nginx/example.journaldev.com-error.log error;
index index.html index.htm index.php;
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php7.2-fpm-wordpress-site.sock;
fastcgi_index index.php;
include fastcgi.conf;
}
}
위의 구성 설정이 구문상 올바른지 확인하고 NGINX를 다시 시작하십시오.
# nginx-t
# systemctl restart nginx
4. PHP-FPM NGINX 구성 테스트
위의 NGINX 구성 파일이 실제로 새로 생성된 FPM 풀을 사용하고 있는지 테스트하려면 웹 루트 내에 php info 파일을 생성합니다. 위의 NGINX 구성 파일에서 /var/www/html/wordpress
를 웹 루트로 사용했습니다. 환경에 따라 이 값을 조정하십시오.
# cd /var/www/html/wordpress
# echo "<?php echo phpinfo();?>" > info.php
PHP 정보 페이지 생성이 완료되면 선호하는 웹 브라우저를 이 페이지로 지정하십시오. $_SERVER[USER]
및 $_SERVER[HOME]
변수의 값이 wordpress_user
및 /home을 가리키고 있음을 알 수 있습니다. 이전에 FPM 구성 파일에서 설정한 /wordpress_user
이므로 NGINX가 원하는 FPM 풀을 사용하여 PHP 페이지를 제공하고 있음을 확인합니다.
요약
이 기사에서는 php-fpm을 설치하고 다양한 사용자 및 애플리케이션에 대해 별도의 풀을 구성하는 방법을 배웠습니다. 또한 PHP-FPM 서비스에 연결하기 위해 NGINX 서버 블록을 구성하는 방법도 배웠습니다. PHP-FPM은 많은 성능 조정 옵션과 함께 안정성, 보안, 확장성 및 속도를 제공합니다. 이제 기본 PHP-FPM 풀을 여러 리소스 풀로 분할하여 다양한 애플리케이션을 제공할 수 있습니다. 이렇게 하면 서버 보안이 강화될 뿐만 아니라 서버 리소스를 최적으로 할당할 수 있습니다!