Php fpm nginx


Я уже писал статью по данной теме, и она формально даже не устарела, если брать все пакеты из официальных репозиториев. Сегодня я настрою производительный веб сервер на свежих версиях nginx, php-fpm, где сам php версии 7.1.  Сейчас использовать версию php54, которую предлагает CentOS по-умолчанию, очень странно, поэтому я решил актуализировать статью и все настроить в соответствии с современными реалиями.

Введение

Ранее я рассказывал о настройке nginx и php-fpm. В принципе, статья полностью актуальна, по ней получится настроить веб сервер, если вас устраивают версии предложенных в стандартном репозитории пакетов. Если же хочется версий посвежее, то читайте далее.

Работать будем на сервере под управлением CentOS 7. Если у вас его еще нет, то читайте мои статьи на тему установки и базовой настройки centos. Не забудьте уделить внимание теме настройки iptables. В данной статье я ее не буду касаться, хотя тема важная для web сервера.

В своей тестовой среде я буду использовать следующие сущности.

hl.zeroxzed.ru имя тестового виртуального хоста и сайта
/web/sites директория для размещения виртуальных хостов
 95.169.190.64  внешний ip адрес сервера
 p1m2a.zeroxzed.ru  имя виртуального хоста для phpmyadmin

Подопытным сервером будет выступать виртуальная машина от keyweb, расположенная на сервере в Германии. Характеристики следующие:

Процессор 2 ядра
Память 8 Gb
Диск 150 Gb SSD

Указанный сервер включает в себя администрирование. То есть вы можете его заказать и прислать в техподдержку ссылку на эту статью. Они за вас все настроят. Если все же хотите настраивать сами, то берите сервер из линейки PRO. Они дешевле, но настраивать все придется самому. Чем я и займусь ?

Установка nginx на CentOS 7

Для установки самой свежей стабильной версии nginx на centos подключим родной репозиторий.

# rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

Если по какой-то причине ссылка изменится или устареет, то можно создать файл с конфигурацией репозитория nginx вручную. Для этого рисуем такой конфиг /etc/yum.repos.d/nginx.repo.

[nginx]  name=nginx repo  baseurl=http://nginx.org/packages/centos/7/$basearch/  gpgcheck=0  enabled=1

Устанавливаем nginx на сервер.

# yum install nginx


Установка nginx на CentOS 7

Запускаем nginx и добавляем в автозагрузку.

# systemctl start nginx  # systemctl enable nginx

Проверяем, запустился ли web сервер. Для этого идем по ссылке http://95.169.190.64/. Вы должны увидеть стандартную страницу заглушку.

Проверка nginx

Если страница не открывается, то скорее всего вы не настроили firewall. Свою статью по его настройке я приводил в самом начале.

Настройка nginx

Расскажу, как настроить nginx для работы разных виртуальных хостов. Создадим виртуальный хост и подготовим директории для размещения исходников сайта и панели управления phpmyadmin.

# mkdir -p /web/sites/hl.zeroxzed.ru/www && mkdir /web/sites/hl.zeroxzed.ru/log  # mkdir -p /web/sites/p1m2a.zeroxzed.ru/www && mkdir /web/sites/p1m2a.zeroxzed.ru/log

Создадим конфиги nginx для этих виртуальных хостов. Я сразу буду делать их с учетом https, который мы настроим позже. Так что после создания не надо перезапускать веб сервер и проверять работу — будут ошибки. Виртуальный хост сайта показан на примере wordpress. Конфигурация собрана на основе рекомендаций из официальной документации конкретно для веб сервера nginx.


# mcedit /etc/nginx/conf.d/hl.zeroxzed.ru.conf
server {   listen 80;   server_name hl.zeroxzed.ru;   root /web/sites/hl.zeroxzed.ru/www/;   index index.php index.html index.htm;   access_log /web/sites/hl.zeroxzed.ru/log/access.log main;   error_log /web/sites/hl.zeroxzed.ru/log/error.log;     location / {   return 301 https://hl.zeroxzed.ru$request_uri;   }     location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ {   return 301 https://hl.zeroxzed.ru$request_uri;   }     location ~ .php$ {   return 301 https://hl.zeroxzed.ru$request_uri;   }     location = /favicon.ico {   log_not_found off;   access_log off;   }     location = /robots.txt {   rewrite ^ /robots.txt break;   allow all;   log_not_found off;   access_log off;   }     location ~ /.ht {   deny all;   }  }    server {   listen 80;   server_name www.hl.zeroxzed.ru;   rewrite ^ https://hl.zeroxzed.ru$request_uri? permanent;  }    server {   listen 443 ssl http2;   server_name hl.zeroxzed.ru;   root /web/sites/hl.zeroxzed.ru/www/;   index index.php index.html index.htm;   access_log /web/sites/hl.zeroxz.  

-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/ssl/certs/dhparam.pem; add_header Strict-Transport-Security 'max-age=604800'; location / { try_files $uri $uri/ /index.php?$args; } location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { access_log off; expires max; } location ~ .php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; #fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /web/sites/hl.zeroxzed.

out 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ /.ht { deny all; } } server { listen 443 ssl http2; server_name www.hl.zeroxzed.ru; rewrite ^ https://hl.zeroxzed.ru$request_uri? permanent; }

В данной конфигурации настроены все необходимые редиректы, при этом отключен редирект файла robots.txt. Он отдельно отдается по http и https. Это требуется для яндекса во время перехода с http на https и склейки зеркал.

Для phpmyadmin рисуем конфиг попроще.

# mcedit /etc/nginx/conf.d/p1m2a.zeroxzed.ru.conf
server {   listen 443 ssl http2;   server_name p1m2a.zeroxzed.ru;   root /web/sites/p1m2a.zeroxzed.ru.  

CDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/ssl/certs/dhparam.pem; add_header Strict-Transport-Security 'max-age=604800'; location ~ .php$ { fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; #fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /web/sites/p1m2a.zeroxzed.ru/www/; fastcgi_param SCRIPT_FILENAME /web/sites/p1m2a.zeroxzed.ru/www$fastcgi_sc.

fers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } } server { listen 443 ssl http2; server_name www.p1m2a.zeroxzed.ru; rewrite ^ https://p1m2a.zeroxzed.ru$request_uri? permanent; } server { listen 80; server_name p1m2a.zeroxzed.ru; root /web/sites/p1m2a.zeroxzed.ru/www/; index index.php index.html index.htm; access_log /web/sites/p1m2a.zeroxzed.ru/log/access.log main; error_log /web/sites/p1m2a.zeroxzed.ru/log/error.log; location / { return 301 https://p1m2a.zeroxzed.ru$request_uri; try_files $uri $uri/ /index.php?$args; } }

Сохраняем конфиги виртуальных хостов nginx и продолжаем настройку производительного веб сервера.

Установка php-fpm 7.1

Установка и настройка 7-й версии php на centos не очень простая задача. Ранее я уже рассказывал как обновить php до 7-й версии, но в итоге откатился назад. Прошло прилично времени и откатываться уже не будем, так как большинство проблем исправлены.


Основные трудности возникают с тем, что в официальных репозиториях очень старые версии php, но при этом они часто есть в зависимостях к другим пакетам. В итоге, обновившись неаккуратно до 7.1 можно получить проблемы с установкой и обновлением, к примеру, phpmyadmin или zabbix. В комментариях к моим статьям я иногда вижу эти ошибки и по тексту ошибок сразу понимаю, что проблема с зависимостями.

Вторая проблема в том, что надо определить, какой репозиторий использовать для установки php7. Их существует очень много. К примеру, мой хороший знакомый в своей статье по настройке web сервера использует репозиторий Webtatic. В принципе, чтобы просто поставить php 7-й версии это нормальный вариант. Но если вы после этого захотите установить phpmyadmin через yum уже ничего не получится. Будет ошибка зависимостей, которые нужно будет как-то руками разбирать.

То же самое будет и с другими пакетами. К примеру, zabbix без плясок с бубнами скорее всего не встанет. В сторонних репозиториях есть еще одна проблема. Иногда они закрываются. И это станет для вас большой проблемой на боевом сервере. Так что к выбору репозитория нужно подходить очень аккуратно и внимательно. Я до сих пор иногда встречаю настроенные сервера centos 5 с очень популярным в прошлом репозиторием centos.alt.ru, который закрылся. Сейчас это уже не так актуально, так как таких серверов осталось мало, но некоторое время назад мне это доставляло серьезные неудобства.


Для установки свежей версии php я буду использовать репозиторий Remi. Это известный и популярный репозиторий, который ведет сотрудник RedHat. И хотя надежность репозитория, который ведет один человек не так высока, но ничего лучше и надежнее remi лично я не нашел для своих целей. Если вы можете что-то посоветовать на этот счет — комментарии в вашем распоряжении. Буду благодарен за дельный совет.

Подключаем remi репозиторий для centos 7.

# rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm

Я получил ошибку:

Retrieving http://rpms.remirepo.net/enterprise/remi-release-7.rpm  warning: /var/tmp/rpm-tmp.nwcDV1: Header V4 DSA/SHA1 Signature, key ID 00f97f56: NOKEY  error: Failed dependencies:    epel-release = 7 is needed by remi-release-7.3-2.el7.remi.noarch

Тут все понятно, нужен репозиторий epel. Те, кто готовили сервер по моей статье по базовой настройке сервера его уже подключили, а те кто не делали этого, подключают сейчас:

# yum install epel-release

После этого повторяем установку remi, все должно пройти нормально. Проверим список подключенных репозиториев.

# yum repolist

Список репозиториев

У меня такая картинка получилась.

Активируем репу remi-php71, для этого выполняем команду:

# yum-config-manager --enable remi-php71

Если получаете ошибку:

bash: yum-config-manager: command not found

то установите пакет yum-utils.

# yum install yum-utils

Теперь устанавливаем php7.1.

# yum install php71


Установка php 7.1 на CentOS 7

Установим php-fpm и наиболее популярные модули, которые могут пригодится в процессе эксплуатации веб сервера.

# yum install php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-pecl-memcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip

Установка php-fpm

Запускаем php-fpm и добавляем в автозагрузку.

# systemctl start php-fpm  # systemctl enable php-fpm

Проверяем, запустился ли он.

# netstat -tulpn | grep php-fpm  tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 9084/php-fpm: maste

Все в порядке, повис на порту 9000. Запустим его через unix сокет. Для этого открываем конфиг /etc/php-fpm.d/www.conf и комментируем строку:

;listen = 127.0.0.1:9000

Вместо нее добавляем несколько других:

listen = /var/run/php-fpm/php-fpm.sock  listen.mode = 0660  listen.owner = nginx  listen.group = nginx

Заодно измените пользователя, от которого будет работать php-fpm. Вместо apache укажите nginx.

user = nginx  group = nginx

Перезапускаем php-fpm.

# systemctl restart php-fpm

Проверяем, стартовал ли указанный сокет.

# ll /var/run/php-fpm/php-fpm.sock   srw-rw----. 1 nginx nginx 0 Oct 26 18:08 /var/run/php-fpm/php-fpm.sock

На текущий момент с настройкой php-fpm закончили, двигаемся дальше.

Для того, чтобы проверить работу нашего веб сервера, нужно установить ssl сертификаты. Без них nginx с текущим конфигом не запустится. Исправляем это.

Настройка бесплатного ssl сертификата Lets Encrypt

Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt.

# yum install certbot

Запускаем программу для генерации сертификата.

# certbot certonly

Вам в консоли будут заданы несколько вопросов. Вот мои ответы, необходимые для успешного получения сертификата. Первый раз мы получим сертификаты, используя временный веб сервер самого certbot, так как наш еще не работает. Далее обновлять сертификаты будем в автоматическом режиме с помощью временной директории в корне виртуального хоста.

# certbot certonly  Saving debug log to /var/log/letsencrypt/letsencrypt.log    How would you like to authenticate with the ACME CA?  -------------------------------------------------------------------------------  1: Spin up a temporary webserver (standalone)  2: Place files in webroot directory (webroot)  -------------------------------------------------------------------------------  Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1  Plugins selected: Authenticator standalone, Installer None  Enter email address (used for urgent renewal and security notices) (Enter 'c' to  cancel): zeroxzed@gmail.com  Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org    -------------------------------------------------------------------------------  Please read the Terms of Service at  https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree  in order to register with the ACME server at  https://acme-v01.api.letsencrypt.org/directory  -------------------------------------------------------------------------------  (A)gree/(C)ancel: A    -------------------------------------------------------------------------------  Would you be willing to share your email address with the Electronic Frontier  Foundation, a founding partner of the Let's Encrypt project and the non-profit  organization that develops Certbot? We'd like to send you email about EFF and  our work to encrypt the web, protect its users and defend digital rights.  -------------------------------------------------------------------------------  (Y)es/(N)o: N  Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'  to cancel): hl.zeroxzed.ru  Obtaining a new certificate  Performing the following challenges:  tls-sni-01 challenge for hl.zeroxzed.ru  Waiting for verification...  Cleaning up challenges    IMPORTANT NOTES:   - Congratulations! Your certificate and chain have been saved at:   /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem   Your key file has been saved at:   /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem   Your cert will expire on 2018-01-24. To obtain a new or tweaked   version of this certificate in the future, simply run certbot   again. To non-interactively renew *all* of your certificates, run   "certbot renew"   - Your account credentials have been saved in your Certbot   configuration directory at /etc/letsencrypt. You should make a   secure backup of this folder now. This configuration directory will   also contain certificates and private keys obtained by Certbot so   making regular backups of this folder is ideal.   - If you like Certbot, please consider supporting our work by:     Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate   Donating to EFF: https://eff.org/donate-le  

Для успешного создания бесплатных ssl сертификатов от lets encrypt у вас должны быть корректно настроены DNS записи для доменов, на которые выпускаются сертификаты.

Итак, сертификаты получили. Теперь можно проверить конфигурацию nginx и запустить его. Проверяем конфиг:

# nginx -t

Если получаете ошибку:

nginx: [emerg] BIO_new_file("/etc/ssl/certs/dhparam.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/ssl/certs/dhparam.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)  nginx: configuration file /etc/nginx/nginx.conf test failed

То генерируете необходимый ключ:

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

Генерация будет длиться долго (у меня 20 минут длилось на двух ядрах). Снова проверяйте конфигурацию. Если ошибок нет, то перезапустим nginx.

# systemctl restart nginx

Настройка nginx на этом завершена. Он должен корректно запуститься и работать в рабочем режиме.

Теперь сделаем так, чтобы сертификаты автоматически обновлялись перед истечением срока действия. Для этого необходимо изменить конфигурации доменов. Они располагаются в директории /etc/letsencrypt/renewal. Так как мы генерировали сертификаты с помощью временного веб сервера, наш текущий конфиг hl.zeroxzed.ru.conf выглядит вот так:

# renew_before_expiry = 30 days  version = 0.18.1  archive_dir = /etc/letsencrypt/archive/hl.zeroxzed.ru  cert = /etc/letsencrypt/live/hl.zeroxzed.ru/cert.pem  privkey = /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem  chain = /etc/letsencrypt/live/hl.zeroxzed.ru/chain.pem  fullchain = /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem    # Options used in the renewal process  [renewalparams]  authenticator = standalone  installer = None  account = e9c86e6aa57b45f9614bc7c0015927a5

Приводим его к следующему виду:

# renew_before_expiry = 30 days  version = 0.18.1  archive_dir = /etc/letsencrypt/archive/hl.zeroxzed.ru  cert = /etc/letsencrypt/live/hl.zeroxzed.ru/cert.pem  privkey = /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem  chain = /etc/letsencrypt/live/hl.zeroxzed.ru/chain.pem  fullchain = /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem    # Options used in the renewal process  [renewalparams]  authenticator = webroot  installer = None  account = e9c86e6aa57b45f9614bc7c0015927a5  post_hook = nginx -s reload  [[webroot_map]]  www.hl.zeroxzed.ru = /web/sites/hl.zeroxzed.ru/www  hl.zeroxzed.ru = /web/sites/hl.zeroxzed.ru/www

По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:

# Cert Renewal  30 2 * * * root /usr/bin/certbot renew --post-hook "nginx -s reload" >> /var/log/le-renew.log

Все, с сертификатами закончили. Двигаемся дальше в настройке web сервера.

Установка mariadb 10 на CentOS 7

Дошла очередь до установки сервера баз данных для web сервера на CentOS 7 — MariaDB. По аналогии с другим софтом, в официальном репозитории очень старая версия mariadb — 5.5. Я же буду устанавливать последнюю стабильную версию на момент написания статьи — 10.2.

Для того, чтобы подключить репозиторий MariaDB, можно воспользоваться специальной страницей на официальном сайте, где можно задать параметры системы и получить конфиг репозитория.

В моем случае конфиг получился следующий.

# cat /etc/yum.repos.d/mariadb.repo
[mariadb]  name = MariaDB  baseurl = http://yum.mariadb.org/10.2/centos7-amd64  gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB  gpgcheck=1

Устанавливаем последнюю версию mariadb на centos.

# yum install MariaDB-server MariaDB-client

Установка MariaDB 10 на web сервер

Убедитесь, что база данных ставится из нужного репозитория.

Запускаем mariadb и добавляем в автозагрузку.

# systemctl start mariadb  # systemctl enable mariadb

Запускаем скрипт начальной конфигурации mysql и задаем пароль для root. Все остальное можно оставить по-умолчанию.

# /usr/bin/mysql_secure_installation

Сервер баз данных mysql для нашего web сервера готов. Продолжаем настройку. Установим панель управления mysql — phpmyadmin.

Установка phpmyadmin

Кратко расскажу про установку phpmyadmin в контексте данной статьи. Подробно не буду останавливаться на этом, так как статья и так получается очень объемная, а я еще не все рассказал. Вопрос настройки phpmyadmin я очень подробно рассмотрел отдельно. За подробностями можно сходить туда.

Устанавливаем phpmyadmin через yum. Если ранее все сделали правильно, то конфликтов с зависимостями быть не должно.

# yum install phpmyadmin

Установка phpmyadmin на nginx и php-fpm

Phpmyadmin по-умолчанию сконфигурирована для работы с httpd. Для того, чтобы в будущем автоматически обновлять ее, просто сделаем символьную ссылку из директории с исходниками панели в наш виртуальный хост.

# rm -df /web/sites/p1m2a.zeroxzed.ru/www  # ln -s /usr/share/phpMyAdmin /web/sites/p1m2a.zeroxzed.ru/www

Выставляем правильные права на директорию с php сессиями. Без этого работать phpmyadmin не будет.

# chown nginx:nginx /var/lib/php/session/

Можно заходить и проверять работу phpmyadmin. Ее установка закончена.

Доступ к сайту по sftp

Настройка сервера почти завершена. Если вы администратор и единственный пользователь, то больше можно ничего не делать. Вы и так сможете загрузить на сервер все что нужно тем или иным способом. Если же вы будете передавать управление сайтами другим людям, им нужен доступ к директории с исходниками сайта. Раньше для этих целей повсеместно использовали ftp. Если вы хотите так сделать, у меня есть статья по настройке ftp сервера vsftpd.

Я же предлагаю использовать sftp по нескольким причинам:

  1. Он безопаснее.
  2. Его быстрее настроить.
  3. Не надо отдельно настраивать firewall.

Статью по настройке sftp доступа я уже тоже писал, все подробности там. Здесь без комментариев выполним необходимые действия.

Создаем пользователя для подключения к сайту. Я обычно использую имя пользователя пересекающееся с названием сайта. Так удобнее управлять.

# useradd -s /sbin/nologin hl.zeroxzed.ru  # passwd hl.zeroxzed.ru

Открываем конфиг ssh по пути /etc/ssh/sshd_config и комментируем там одну строку, добавляя далее несколько новых.

#Subsystem sftp /usr/libexec/openssh/sftp-server  Subsystem sftp internal-sftp  Match User hl.zeroxzed.ru  ChrootDirectory /web/sites/hl.zeroxzed.ru  ForceCommand internal-sftp

Перезапускаем службу sshd.

# systemctl restart sshd

Этого уже достаточно, чтобы вы могли подключиться к сайту, к примеру, с помощью программы winscp. Если что-то пойдет не так и будут какие-то ошибки, то смотреть подробности нужно в логе /var/log/secure. Но тут возникает много нюансов с правами к файлам и директориям. Дальше я расскажу, как их аккуратно и грамотно разрулить, чтобы у нас не было проблем с дальнейшей работой сайтов от разных пользователей.

Работа с сайтами разных пользователей на одном веб сервере

Самый простой способ решить проблему с правами доступа, это сделать владельцем папки с сайтом пользователя, который подключается по sftp. Тогда он сможет нормально работать с файлами, загружать и удалять их. Если доступ в качестве группы установить для nginx, то в целом все будет работать. Для каких-то сайтов такой вариант может оказаться подходящим. То есть сделать надо вот так:

# chown -R hl.zeroxzed.ru:nginx /web/sites/hl.zeroxzed.ru/  # chmod -R 0775 /web/sites/hl.zeroxzed.ru/

Но при такой схеме будут проблемы с движками сайтов, которые автоматом что-то к себе загружают. Какие-то галереи не будут работать. К примеру, wordpress не сможет автоматически загружать плагины, будет просить доступ к ftp. В общем, могут возникнуть некоторые неудобства. Сейчас мы их исправим.

Еще обращаю внимание на один нюанс. Chroot доступ для sftp не будет работать, если владельцем директории, куда чрутимся, будет не root. Только что мы сделали владельцем каталога с сайтом и всего, что внутри него пользователя hl.zeroxzed.ru. Теперь надо вернуть обратно владельцем исходного каталога рута, а все, что внутри него остается как мы и хотим — будет принадлежать hl.zeroxzed.ru.

# chown root:root /web/sites/hl.zeroxzed.ru/  # chmod 0755 /web/sites/hl.zeroxzed.ru/

А теперь сделаем все красиво. Назначаем владельцем содержимого нашего сайта только отдельного пользователя.

# chown -R hl.zeroxzed.ru:hl.zeroxzed.ru /web/sites/hl.zeroxzed.ru/

Возвращаем обратно рута владельцем корня chroot.

# chown root:root /web/sites/hl.zeroxzed.ru/  # chmod 0755 /web/sites/hl.zeroxzed.ru/

Обращаю внимание, что сначала мы рекурсивно назначаем права на все содержимое директорий, а потом возвращаем владельца root только на корень.

Добавляем пользователя nginx в группу hl.zeroxzed.ru.

# usermod -aG hl.zeroxzed.ru nginx

Создаем отдельный pool для php-fpm, который будет обслуживать сайт hl.zeroxzed.ru и будет запускаться от этого пользователя. Для этого копируем существующий конфиг /etc/php-fpm.d/www.conf и изменяем в нем несколько строк.

# cd /etc/php-fpm.d && cp www.conf hl.zeroxzed.ru.conf
[hl.zeroxzed.ru]  user = hl.zeroxzed.ru  group = hl.zeroxzed.ru  listen = /var/run/php-fpm/hl.zeroxzed.ru.sock  listen.owner = hl.zeroxzed.ru  listen.group = hl.zeroxzed.ru

Мы поменяли название пула, запустили его от отдельного пользователя и назначили ему отдельный сокет. Теперь идем в настройки этого виртуального хоста в nginx — /etc/nginx/conf.d/hl.zeroxzed.ru.conf и везде меняем старое значение сокета

fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

на новое

fastcgi_pass unix:/var/run/php-fpm/hl.zeroxzed.ru.sock;

Перезапускаем nginx и php-fpm и проверяем работу сайта от отдельного пользователя.

# systemctl restart nginx  # systemctl restart php-fpm

Я рекомендую подключиться по sftp, закинуть исходники wordpress, установить его и добавить новую тему, чтобы проверить, что все корректно работает.  По аналогии проделанные выше действия повторяются для всех остальных сайтов.

Ротация логов виртуальных хостов

Последний штрих в настройке web сервера — ротация логов виртуальных хостов. Если этого не сделать, то через какое-то, обычно продолжительное, время возникает проблема в связи с огромным размером лог файла.

У нас уже будет файл конфигурации logrotate для nginx, который был создан во время установки — /etc/logrotate.d/nginx. Приведем его к следующему виду:

/var/log/nginx/*log  /web/sites/p1m2a.zeroxzed.ru/log/*log {     create 0644 nginx nginx   size=1M   rotate 10   missingok   notifempty   compress   sharedscripts   postrotate   /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true   endscript  }    /web/sites/hl.zeroxzed.ru/log/*log {     create 0644 hl.zeroxzed.ru hl.zeroxzed.ru   size=1M   rotate 10   missingok   notifempty   compress   sharedscripts   postrotate   /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true   endscript  }  

Я предлагаю ротировать файлы логов по достижению ими размера в 1Мб, сжимать после ротации и хранить 10 архивов с логом. Для виртуальных хостов, работающих от отдельного пользователя, новые логи создаются сразу с соответствующими правами, чтобы у пользователя был доступ к ним. Для всех остальных хостов можно использовать самое первое правило, просто добавляя туда новые пути для логов.

Это просто пример конфигурации. Все параметры вы можете поменять по своему усмотрению. Примеров конфигурации logrotate в интернете много.

На этом все. Я рассмотрел все основные моменты, которые необходимы для установки и настройки производительного web сервера на основе nginx и php-fpm последних версий. При этом рассказал о некоторых вещах, которые повышают удобство и гибкость эксплуатации сервера.

Заключение

Тема настройки веб сервера обширна. Рассмотреть все варианты в одной статье невозможно, так как функционал будет разниться, в зависимости от назначения сервера. Тем не менее приведу еще несколько ссылок на материалы, которые имеют отношение к настройке web сервера:

  • Полный бэкап сервера или отдельных сайтов.
  • Мониторинг веб сервера и веб сайта с помощью zabbix.
  • Защита админки wordpress с помощью fail2ban.
  • Если у вас будут проблемы с ботами, то пригодится статья по блокировке доступа к сайту по странам.

Если еще что-то полезное вспомню, добавлю ссылки. Пока вроде все. Жду комментариев и отзывов. Написал все по своему опыту, как я обычно настраиваю веб сервера. Возможно что-то можно сделать более удобно и правильно.

Эта статья будет первой из цикла статей по настройке современного веб сервера. Далее мы будем защищать web сервер и готовить его к максимальным нагрузкам.

serveradmin.ru

Введение

В статье рассматривается настройка сервера Debian 7 для размещения проектов PHP в связке с Nginx и PHP-FPM.

Долгое время мне вполне хватало возможностей Apache для разработки моих проектов на PHP. Были некоторые трудности с .htaccess и перенаправлением всех запросов на Front Controller, однако, чуть позже я понял, что Apache уже не может полностью удовлетворить моей тяги к максимальной производительности и начал искать другие пути. Почитав, я выяснил, что доля интернет-серверов под управлением Apache неуклонно снижается на протяжении уже нескольких лет, на замену ему приходят другие, которые дают бОльшую произодительность с меньшей затратой машинных ресурсов. Среди множества решений я выбрал PHP-FPM. Судя по тестам производительности, произведённым многими энтузиастами, именно он в связке с Nginx является наиболее перспективным способом размещения сайтов на PHP.

Цели

  • Увязка PHP-FPM с nginx
  • Конфигурирование параметров сайта для его корректной работы через Front Controller

Установка необходимого ПО

Добавим в список репозитории nginx, предварительно создав файл nginx.list в каталоге /etc/apt/sources.list.d/:

cd /etc/apt/sources.list.d/ touch nginx.list

/etc/apt/sources.list.d/nginx.list

deb http://nginx.org/packages/debian/ wheezy nginx deb-src http://nginx.org/packages/debian/ wheezy nginx

Скачиваем ключ репозитория:

wget http://nginx.org/keys/nginx_signing.key

Установка ключей в deb-системах делается так:

apt-key add nginx_signing.key

Теперь можно выполнить установку всех необходимых программ:

apt-get update && apt-get install php5 php5-fpm nginx -y

Кратко по списку:

  • php5 и php5-fpm — интерпретатор и FastCGI-сервер для него
  • nginx — проксирующий сервер, будет нашим Front-End, т.е. сервером, принимающим запросы пользователя. Не путать с Front Controller, это совершенно разные вещи!

Настройка PHP и PHP-FPM

При установке PHP-FPM создаёт внутри каталога /etc/php5 подкаталог fpm. Внутри этого каталога находится несколько нужных нам файлов и подкаталогов. Первым делом вносим изменения в файл /etc/php5/fpm/php.ini

cd /etc/php5/fpm nano php.ini

Здесь множество настроек, которые влияют на поведение PHP. В качестве символа комментария следует использовать точку с запятой. Самыми полезными я считаю следующие настройки:

  • short_open_tag = Off — использование коротких тегов считать ошибкой. Официальная документация по PHP рекомендует не использовать короткие теги.
  • asp_tags = Off — мы тут всё-таки на PHP пишем, а не на ASP.NET
  • max_execution_time = 60 — для некоторых CMS, например, Drupal, стандартных 30 секунд часто не хватает для выполнения некоторых скриптов, например, обновления
  • error_reporting = E_ALL — разработчику нужно видеть все ошибки. Если сервер боевой, нужно выставить в значение E_ALL & ~E_DEPRECATED & ~E_STRICT
  • display_errors = On — для разработки, для боевых условий — Off
  • display_startup_errors = On — аналогично
  • post_max_size = 16M — можно и больше, если через POST будут передаваться достаточно большие объёмы данных
  • default_charset = «UTF-8» — обязательно, если хочется избавиться от большинства проблем с кодировкой. Осторожно! Настройка влияет на весь сервер. Также кодировку можно задать в самом скрипте!
  • cgi.fix_pathinfo=1 — пригодится, если приложение работает через Front Controller
  • upload_max_filesize = 32M — можно и больше, если на сервер будут загружаться большие файлы
  • default_socket_timeout = 60 — в нашем случае связь с Nginx будет именно через сокет. Не стоит выставлять слишком большие значения, это приведёт к падению производительности.

Остальные настройки в этом файле можете делать по своему усмотрению.

Теперь нужно подредактировать файл www.conf в каталоге pool.d/www.conf

nano pool.d/www.conf

Следует изменить user и group на те, от имени которых будут выполняться скрипты. Не следует выполнять их от имени root, это дыра в безопасности. Я рекомендую указывать здесь владельца каталога /var/www

user = www-data group = www-data

Не менее важная настройка:

listen = /var/run/php5-fpm.sock

Именно через этот сокет будет производиться обмен данными с Nginx. Остальные настройки я рекомендую оставить по умолчанию. Их тонкая настройка заслуживает отдельной подробной статьи.

После сохранения изменений следует перезапустить php-fpm:

service php5-fpm restart

Настройка Nginx

Перейдём в каталог настроек nginx:

cd /etc/nginx/

Здесь нам нужны 2 файла:

  • nginx.conf — основной файл конфигурации сервера
  • fastcgi_params — настройки Nginx для работы с FastCGI-серверами, например, PHP-FPM

Я привёл содержимое этих файлов к следующему виду:

nginx.conf

user nginx; worker_processes 2; # По числу ядер/процессоров, либо эмпирическим путём worker_priority -5; # Отрицательные числа задают более высокий приоритет worker_rlimit_nofile 2048; # Можно открыть сразу 2048 подключений без изменения параметров ядра  error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid;  events {  worker_connections 1024; }  http {  include /etc/nginx/mime.types;  default_type application/octet-stream;   log_format main '$remote_addr - $remote_user [$time_local] "$request" '  '$status $body_bytes_sent "$http_referer" '  '"$http_user_agent" "$http_x_forwarded_for"';   access_log /var/log/nginx/access.log main;   sendfile on;  tcp_nopush on;  tcp_nodelay on;   keepalive_timeout 60; #Поддерживать подключение 1 минуту   client_max_body_size 20m; #Разрешить загрузку файлов до 20 МБ  server_tokens off;   #Сжатие передаваемых данных  gzip on;  gzip_disable "msie6";  gzip_comp_level 2;  gzip_proxied any;  gzip_types text/plain text/css application/x-javascript text/xml application/xml+rss text/javascript;   include /etc/nginx/conf.d/*.conf; }

В конец файла fastcgi_params нужно добавить всего одну строчку, вот эту:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Теперь в каталоге /etc/nginx/conf.d/ создадим файл site.conf

nano /etc/nginx/conf.d/site.conf
index index.php; server {  server_name www.site.ru;  rewrite ^ $scheme://site.ru$request_uri? permanent; } server {  server_name site.ru;  access_log /var/www/site.ru/log/access.log;  error_log /var/www/site.ru/log/error.log;  root /var/www/site.ru;   location / {  try_files $uri $uri/ /index.php?$request_uri;  index index.php;  }   location ^~ /protected/ {  deny all;  }   location ~ .php$ {  try_files $uri = 404;  include fastcgi_params;  fastcgi_pass unix:/var/run/php5-fpm.sock;  } }

Разберём по частям этот файл:

index index.php;

Считать страницей по-умолчанию index.php

server {  server_name www.site.ru;  rewrite ^ $scheme://site.ru$request_uri? permanent; }

Все запросы на http://www.site.ru автоматически переадресовывать к http://site.ru/

server_name site.ru; access_log /var/www/site.ru/log/access.log; error_log /var/www/site.ru/log/error.log; root /var/www/site.ru;

Собственно наш сервер, с указанием его имени, логов и указанием корневого каталога

location / {  try_files $uri $uri/ /index.php?$request_uri;  index index.php; }

Тут указано, что все запросы вида http://site.ru/login/auth следует переадресовывать к http://site.ru/index.php — как раз то, что нужно для Front Controller’а

location ^~ /protected/ {  deny all; }

Запрещаем любые обращения к папке protected нашего сайта. Там лежат исходные коды, к которым будет обращаться только index.php, веб-сервер их отдавать не должен.

location ~ .php$ {  try_files $uri = 404;  include fastcgi_params;  fastcgi_pass unix:/var/run/php5-fpm.sock; }

Выдавать ошибку 404, если запрошенный php-файл не найден. В остальном — просто переадресовать запрос на наш PHP-FPM-сервер. Также в этих строках выполняется подключение файла настроек /etc/nginx/fastcgi_params.

После выполнения всех операций следует перезапустить сервис Nginx

service nginx restart

Если исходные файлы сайта размещены в каталоге /var/www/site.ru/, а также этот каталог содержит подкаталог log, владельцем которого является www-data, то при обращении к сайту мы увидим главную страницу.

dunmaksim.blogspot.com

Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой

sudo nano /etc/php5/fpm/php.ini

после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)

;cgi.fix_pathinfo = 1

и привести её к виду

cgi.fix_pathinfo = 0

Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).

Если планируется загрузка больших файлов (важно для ownCloud версий < 8, в новой версии 8 и выше имеется отдельный файл для этих настроек), то можно увеличить максимальный объем загружаемых данных, например, до 200 МБ

post_max_size = 200M

и ниже

upload_max_filesize = 200M

Затем сохранить изменения в файле.

Далее, необходимо отрыть для редактирования файл «/etc/php5/fpm/pool.d/www.conf», например, командой

sudo nano /etc/php5/fpm/pool.d/www.conf

найти строчку с параметров «security.limit_extensions» и привести её к виду

security.limit_extensions = .php .php3 .php4 .php5

Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду

listen = /var/run/php5-fpm.sock

Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду

listen.owner = www-data listen.group = www-data listen.mode = 0660

Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой

sudo service php5-fpm restart

Можно убедится в том, что права доступа к сокету установлены верно:

ls -la /var/run/php5-fpm.sock

Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,

srw-rw---- 1 www-data www-data 0 May 2 16:36 /var/run/php5-fpm.sock

help.ubuntu.ru

Советы по настройке и оптимизации Nginx

Совет №1 — Организация файлов конфигурации Nginx

Обычно файлы конфигурации Nginx хранятся в /etc/nginx.

Один из удобных способов организации файлов конфигурации в стиле Debian/Ubuntu Apache:

Файлы виртуальных хостов разделены на две директории. Директория sites-available может содержать любые файлы: тестовые, старые конфиги, копии конфигов и прочие. А директория sites-enabled содержит только реально работающие конфигурации, в действительности являющиеся только символическими ссылками на файлы в директории sites-available.

Не забудьте добавить следующие строки в файл nginx.conf:

Совет №2 — Определить Nginx worker_processes и worker_connections

Настройки по умолчанию  хороши, но их стоит немного оптимизировать: max_clients = worker_processes * worker_connections.

Базовые настройки Nginx могут обрабатывать сотни одновременных соединений:

Обычно 1000 одновременных соединений на один сервер это хорошо, но порою другие части, например жесткий диск могут оказаться медленными и это приведет к тому, что Nginx будет заблокирован на операции ввода-вывода (I/O). Чтобы избежать блокировки используйте, например, следующие настройки: одни worker_process на ядро процессора:

Worker Processes

Чтобы определить сколько ядер имеет ваш процессор, введите:

В данном случае у меня четыре ядра, поэтому окончательный парамерт worker_processes устанавливаем как 4:

Worker Connections

Лично я придерживаюсь 1024 соединений на один воркер, потому что у меня нет никаких оснований для повышения этого значения. Но если например 4096 соединений в секунду не хватает, то можно попробовать удвоить 2048 соединений на процесс.

Окончательные настройки выглядят седующим образом:

Совет №3 — Скрыть токены Nginx / Скрыть номер версии Nginx

Это хорошо из соображений безопасности — скрыть токены Nginx и скрыть номер версии Nginx, тем более если вы используете устаревшую версию Nginx. Это очень легко сделать — достаточно добавить в секцию http/server/location файла конфигурации следующую строку:

Совет №4 — Ограничение на размер передаваемых данных сервером Nginx

Если вы хотите разрешить пользователям загружать файлы, то вы должны увеличить размер сообщения. Это может быть сделано с помощью значения client_max_body_size, которое находится в секции http/server/location файла конфигурации. По умолчанию он равен 1 Мб, но его можно увеличить, например, до 20 Мб, а также увеличить размер буфера:

Если вы получаете сообщение об ошибке, то вы знаете, что client_max_body_size слишком мало:

«Request Entity Too Large» (413)

Совет №5 — Управление кешем для статических файлов

Кэш браузера сохранит ресурсы и пропускную способность вашего сервера. Это несложная настройка Nginx позволит выключить ведение логов (access log и not found log), и установить срок истечения заголовка в 360 дней.

Если вы хотите более сложный заголовки или другие типы файлов, то вы можете настроить их отдельно.

Совет №6 — Проксируйте PHP запросы к PHP-FPM

Вы можете использовать по умолчанию стек tcp/ip или соединение через Unix-сокет. Также необходимо установить PHP-FPM слушать точно такой же ip:port или Unix-сокет. Вот очень простой пример конфигурации (вариант с Unix-сокетом  закоментирован):

Это дает возможность запуска PHP-FPM другим сервером.

Совет №7 — Предотвращение (запрет) доступа к скрытым файлам

Это очень распространено, когда корень сервера или другие публичные каталоги имеют скрытые файлы, которые начинаются с точки (.) И, как правило, они не предназначены для пользователей сайта. Публичный каталог может содержать файлы системы контроля версий: .git, .svn; файлы IDE: .idea; .htaccess файлы. Настройки запещают доступ к скрытым файлам и отключают ведение логов:

 Советы по настройке и оптимизации PHP-FPM

Совет №1 — Файлы конфигурации PHP-FPM

Обычно конфигурации PHP-FPM расположенны в файле /etc/php-fpm.conf и в каталоге /etc/php-fpm.d/. Весь пулл конфигов расопложен в дикертории /etc/php-fpm.d/. Чтобы это работало, вы должны добавить следующую строку в php-fpm.conf:

Совет №2 — Глобальная конфигурация PHP-FPM

Настройки emergency_restart_thresholdemergency_restart_interval и process_control_timeout по умолчанию выключены, но я считаю что их стоит влючить, например, со следующими значениями:

Что это значит? Если 10 дочерних процессов PHP-FPM завершатся с помощью SIGSEGV или SIGBUS в течении 1 минуты, то PHP-FPM перезагрузится автоматически. А также дочерним процессам  установлен лимит времени реакции в 10 секунд на сигнал от мастера.

Совет №3 — Конфигурация пулов PHP-FPM

В PHP-FPM возможно использовать отденьные пулы для каждого сайта и точно распределять ресурсы, а также использовать разных пользователей и разные группы для каждого пула. Приведем примеры конфигураци трех различнх сайтов (или фактически три части одного сайта):

/etc/php-fpm.d/site.conf
/etc/php-fpm.d/blog.conf
/etc/php-fpm.d/forums.conf

Примеры конфигурации каждого пула:
/etc/php-fpm.d/site.conf

/etc/php-fpm.d/blog.conf

/etc/php-fpm.d/forums.conf

Это просто примеры как настроить несколько различных пулов.

Совет №4 — Конфигурация менеджера процессов (Pool Process Manager) PHP-FPM

Лучший способ использовать менеджер процессов PHP-FPM — это донамическое управление процессами, поэтому PHP-FPM запускает процессы только при необходимости. Это почти такой же подход как в Nginx с параметрами worker_processes и worker_connections. Таким образом большие значения не обеспечивают хорошего результата. Каждый процесс ест определнное количество памяти и, конечно, если у сайта очень большой трафик  и много оперативной памяти на сервере, то высокие значения — это правильный выбор. Но такие серверы как VPS обычно имеют ограниченное количество памяти: 256 Мб, 512 Мб, 1024 Мб. Такого небольшого объема ОЗУ достаточно даже для очень большого трафика (даже десятки запросов в секунду), если эту память использовать с умом.

Проверим сколько процессов PHP-FPM позволит легко справляться серверу с нагрузкой. Сначала запустим Nginx и PHP-FPM и загрузим несколько страниц PHP, желательно самые тяжелые. Затем проверим сколько использует памяти процесс PHP-FPM — в Linux можно воспользоваться утилитами top или htop. Предположим что наш сервер имеет 512 Мб оперативной памяти и 220 Мб может быть использованно PHP-FPM, каждый процесс использует 24 Мб оператичной памяти (некоторые CMS с плагинами могут легко кушать 20-40 Мб на один запрос или даже больше). Затем просто вычислим значние max_children для сервера:

220 / 24 = 9.17

Приемлемым значнием pm.max_children будет 9. Это значние основанно на среднем значении и возможно далее его необходимо будет изменить, когда вы заметите длительное время использования памяти процессом. После быстрого тестирования несложно выбрать значния pm.start_servers value, pm.min_spare_servers и pm.max_spare_servers.

Окончательная конфигурация нашего примера может выглядеть следующим образом:

Максималоное количество запросов на процесс по умолчанию не ограничено, но хорошо бы установить какое-нибудь небольшое значение, например 200, и избежать проблем с памятью. Такого вида настрока может обрабарывать большое количество запросов, даже если значение параметра невелико.

У вас проблемы с натройкой Nginx или PHP-FPM или есть еще советы?

Не стесняйтеся писать замечания, вопросы и советы в комментариях.

Оригинальный пост на английском языке

pektop.net

Nginx Configuration and Optimizing Tips and Tricks

Nginx Tip 1. – Organize Nginx Configuration Files

Normally Nginx configuration files are located under /etc/nginx path.
One good way to organize configuration files is use Debian/Ubuntu Apache style setup:

  ## Main configuration file ##  /etc/nginx/nginx.conf    ## Virtualhost configuration files on ##  /etc/nginx/sites-available/  /etc/nginx/sites-enabled/    ## Other config files on (if needed) ##  /etc/nginx/conf.d/  

Virtualhost files have 2 paths, because sites-available directory can contain any stuff, like test configs, just copied/created configs, old configs and so on. And sites-enabled contains only really enabled configurations, actually just only symbolic links to sites-available directory.

Remember add following includes at the end of your nginx.conf file:

  ## Load virtual host conf files. ##  include /etc/nginx/sites-enabled/*;    ## Load another configs from conf.d/ ##  include /etc/nginx/conf.d/*;  

Nginx Tip 2. – Determine Nginx worker_processes and worker_connections

Default setup is okay for worker_processes and worker_connections, but these values could be little bit optimized:
max_clients = worker_processes * worker_connections

Just Nginx basic setup can handle hundreds of concurrent connection:

  worker_processes 1;  worker_connections 1024;  

Normally 1000 concurrent connection / per one server is good, but sometimes other parts like disks on server might be slow, and it causes that the Nginx is locked on I/O operations. To avoid locking use example following setup: one worker_precess / per processor core, like:
Worker Processes

  worker_processes [number of processor cores];  

To check how many processor cores do you have, run following command:

  cat /proc/cpuinfo |grep processor  processor	: 0  processor	: 1  processor	: 2  processor	: 3  

So here is 4 cores and worker_processes final setup could be following:

  worker_processes 4;  

Worker Connections
Personally I stick with 1024 worker connections, because I don’t have any reason to raise this value. But if example 4096 connections per second is not enough then it’s possible to try to double this and set 2048 connections per process.

worker_processes final setup could be following:

  worker_connections 1024;  

I have seen some configurations where server admins are used too much Apache and think if I set Nginx worker_processes to 50 and worker_connections to 20000 then my server could handle all traffic once what we get monthly…but yes it’s not true. It’s just wasting of resources and might cause some serious problems…

Nginx Tip 3. – Hide Nginx Server Tokens / Hide Nginx version number

This is good for security reasons hide server tokens / hide Nginx version number, especially, if run some outdated version of Nginx. This is very easy to do just set server_tokens off under http/server/location section, like:

  server_tokens off;  

Nginx Tip 4. – Nginx Request / Upload Max Body Size (client_max_body_size)

If you want to allow users upload something or upload personally something over the HTTP then you should maybe increase post size. It can be done with client_max_body_size value which goes under http/server/location section. On default it’s 1 Mb, but it can be set example to 20 Mb and also increase buffer size with following configuration:

  client_max_body_size 20m;  client_body_buffer_size 128k;  

If you get following error, then you know that client_max_body_size is too low:
“Request Entity Too Large” (413)

Nginx Tip 5. – Nginx Cache Control for Static Files (Browser Cache Control Directives)

Browser caching is import if you want save resources and bandwith. It’s easy setup with Nginx, following is very basic setup where logging (access log and not found log) is turned off and expires headers are set to 360 days.

  location ~* .(jpg|jpeg|gif|png|css|js|ico|xml)$ {   access_log off;   log_not_found off;   expires 360d;  }  

If you want more complicated headers or some other expiration by filetypes then you could configure those separately.

Nginx Tip 6. – Nginx Pass PHP requests to PHP-FPM

Here you could use default tpc/ip stack or use directly Unix socket connection. You have to also setup PHP-FPM listen exactly same ip:port or unix socket (with Unix socket also socket permission have to be right). Default setup is use ip:port (127.0.0.1:9000) you could of course change ips and ports what PHP-FPM listens. Here is very basic configuration with Unix socket example commented out:

  # Pass PHP scripts to PHP-FPM  location ~* .php$ {   fastcgi_index index.php;   fastcgi_pass 127.0.0.1:9000;   #fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;   include fastcgi_params;   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;   fastcgi_param SCRIPT_NAME $fastcgi_script_name;  }  

It’s also possible to run PHP-FPM another server and Nginx another.

Nginx Tip 7. – Prevent (deny) Access to Hidden Files with Nginx

It’s very common that server root or other public directories have hidden files, which starts with dot (.) and normally those is not intended to site users. Public directories can contain version control files and directories, like .svn, some IDE properties files and .htaccess files. Following deny access and turn off logging for all hidden files.

  location ~ /. {   access_log off;   log_not_found off;    deny all;  }  

PHP-FPM Configuration Tips and Tricks

PHP-FPM Tip 1. – PHP-FPM Configuration files

Normally PHP-FPM configuration files are located on /etc/php-fpm.conf file and /etc/php-fpm.d path. This is normally excellent start and all pool configs goes to /etc/php-fpm.d directory. You need to add following include line on your php-fpm.conf file:

  include=/etc/php-fpm.d/*.conf  

PHP-FPM Tip 2. – PHP-FPM Global Configuration Tweaks

Set up emergency_restart_threshold, emergency_restart_interval and process_control_timeout. Default values for these options are totally off, but I think it’s better use these options example like following:

  emergency_restart_threshold 10  emergency_restart_interval 1m  process_control_timeout 10s  

What this mean? So if 10 PHP-FPM child processes exit with SIGSEGV or SIGBUS within 1 minute then PHP-FPM restart automatically. This configuration also sets 10 seconds time limit for child processes to wait for a reaction on signals from master.

PHP-FPM Tip 3. – PHP-FPM Pools Configuration

With PHP-FPM it’s possible to use different pools for different sites and allocate resources very accurately and even use different users and groups for every pool. Following is just example configuration files structure for PHP-FPM pools for three different sites (or actually three different part of same site):

/etc/php-fpm.d/site.conf  /etc/php-fpm.d/blog.conf  /etc/php-fpm.d/forums.conf  

Just example configurations for every pool:
/etc/php-fpm.d/site.conf

  [site]  listen = 127.0.0.1:9000  user = site  group = site  request_slowlog_timeout = 5s  slowlog = /var/log/php-fpm/slowlog-site.log  listen.allowed_clients = 127.0.0.1  pm = dynamic  pm.max_children = 5  pm.start_servers = 3  pm.min_spare_servers = 2  pm.max_spare_servers = 4  pm.max_requests = 200  listen.backlog = -1  pm.status_path = /status  request_terminate_timeout = 120s  rlimit_files = 131072  rlimit_core = unlimited  catch_workers_output = yes  env[HOSTNAME] = $HOSTNAME  env[TMP] = /tmp  env[TMPDIR] = /tmp  env[TEMP] = /tmp  

/etc/php-fpm.d/blog.conf

  [blog]  listen = 127.0.0.1:9001  user = blog  group = blog  request_slowlog_timeout = 5s  slowlog = /var/log/php-fpm/slowlog-blog.log  listen.allowed_clients = 127.0.0.1  pm = dynamic  pm.max_children = 4  pm.start_servers = 2  pm.min_spare_servers = 1  pm.max_spare_servers = 3  pm.max_requests = 200  listen.backlog = -1  pm.status_path = /status  request_terminate_timeout = 120s  rlimit_files = 131072  rlimit_core = unlimited  catch_workers_output = yes  env[HOSTNAME] = $HOSTNAME  env[TMP] = /tmp  env[TMPDIR] = /tmp  env[TEMP] = /tmp  

/etc/php-fpm.d/forums.conf

  [forums]  listen = 127.0.0.1:9002  user = forums  group = forums  request_slowlog_timeout = 5s  slowlog = /var/log/php-fpm/slowlog-forums.log  listen.allowed_clients = 127.0.0.1  pm = dynamic  pm.max_children = 10  pm.start_servers = 3  pm.min_spare_servers = 2  pm.max_spare_servers = 4  pm.max_requests = 400  listen.backlog = -1  pm.status_path = /status  request_terminate_timeout = 120s  rlimit_files = 131072  rlimit_core = unlimited  catch_workers_output = yes  env[HOSTNAME] = $HOSTNAME  env[TMP] = /tmp  env[TMPDIR] = /tmp  env[TEMP] = /tmp  

So this is just example howto configure multiple different size pools.

PHP-FPM Tip 4. – PHP-FPM Pool Process Manager (pm) Configuration

Best way to use PHP-FPM process manager is use dynamic process management, so PHP-FPM processes are started only when needed. This is almost same style setup than Nginx worker_processes and worker_connections setup. So very high values does not mean necessarily anything good. Every process eat memory and of course if site have very high traffic and server lot’s of memory then higher values are right choise, but servers, like VPS (Virtual Private Servers) memory is normally limited to 256 Mb, 512 Mb, 1024 Mb. This low RAM is enough to handle even very high traffic (even dozens of requests per second), if it’s used wisely.

It’s good to test how many PHP-FPM processes a server could handle easily, first start Nginx and PHP-FPM and load some PHP pages, preferably all of the heaviest pages. Then check memory usage per PHP-FPM process example with Linux top or htop command. Let’s assume that the server has 512 Mb memory and 220 Mb could be used for PHP-FPM, every process use 24 Mb RAM (some huge content management system with plugins can easily use 20-40 Mb / per PHP page request or even more). Then simply calculate the server max_children value:
220 / 24 = 9.17

So good pm.max_children value is 9. This is based just quick average and later this could be something else when you see longer time memory usage / per process. After quick testing it’s much easier to setup pm.start_servers value, pm.min_spare_servers value and pm.max_spare_servers value.

Final example configuration could be following:

  pm.max_children = 9  pm.start_servers = 3  pm.min_spare_servers = 2  pm.max_spare_servers = 4  pm.max_requests = 200  

Max request per process is unlimited by default, but it’s good to set some low value, like 200 and avoid some memory issues. This style setup could handle large amount of requests, even if the numbers seems to be small.

Do you have problems or some nice Nginx and PHP-FPM tips and trick?

Please feel free to post your questions and tips and tricks here.

www.if-not-true-then-false.com


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.