От стабильной и быстрой работы сервера зависит судьба сайта. Его медленная работа и частые падения способны отпугнуть как посетителей, так и поисковые системы. Последние ещё и понизят рейтинг тормозящего сайта в результатах поиска и он окажется не в топ-10, а, скажем, в топ-100 по всем запросам.

Использование связки nginx и php-fpm для обслуживания сайтов позволяет увеличить скорость их работы, а также стабильность системы в целом. К тому же, отказавшись от использования apache, мы несколько упрощаем систему и даже защищаем её. Ведь если нет apache, то злоумышленник не сможет использовать, например, файл.htaccess для своих целей.

Связку nginx+php-fpm настраивать довольно легко и она поддерживается многими популярными CMS: WordPress, MODX, DLE, различными фреймворками. Всё это способно работать и без громоздкого apache.

При установке веб-сервера, не обойтись без создания пользователей. В идеале, для каждого сайта должен быть создан отдельный юзер. Так мы сможем защитить другие сайты, если один из пользователей будет взломан. Примеры в этой статье написаны с учётом того, что пользователей вы создали по .

Для начала установим базовые модули: php-fpm, mysql, curl, GD. Всё остальное — по индивидуальной необходимости.

# aptitude install nginx php5-fpm php5-mysqlnd php5-curl php5-gd

Конфигурационные файлы располагаются в каталоге /etc/php5/fpm/ .

Изначально в php-fpm есть только один пул по имени www. Мы будем использовать его в качестве основы для других пулов.

Откроем конфигурационный файл /etc/php5/fpm/pool.d/www.conf , рассмотрим некоторые переменные и подберём для них значения.

Первая переменная — это имя пула. Оно заключается в квадратные скобки и не может совпадать с именем любого существующего в системе пользователя.

User = username group = www-data

Указываем, что пул должен работать в качестве unix-сокета. Переменная $pool будет заменена на имя.

listen = /var/run/php-$pool.sock

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

Почему именно такой выбор? :) Это самый экономный вариант. Каждый процесс пула будет занимать объём оперативной памяти, выделенный переменной memory_limit плюс несколько мегабайт на подключённые модули, кэш и т.п. При статичном варианте все запросы будут обрабатываться только созданными процессами, а новые порождаться (и занимать драгоценную память) не будут. В итоге получим фиксированное потребление памяти.

Указываем необходимое количество процессов, обслуживающих запросы. Подбирается в зависимости от загруженности.

pm.max_children = 3

Каталог для размещения временных файлов:

Php_admin_value = "/var/www/username/tmp"

Каталог для хранения файлов сессий:

Php_admin_value = "/var/www/username/sessions"

По соображениям безопасности, доступ к этим каталогам должен быть только у пользователя, с правами которого запускается пул php-fpm. Также не следует использовать один каталог и для хранения файлов сессий, и для временных файлов.

Ограничение памяти для выполнения скриптов следует подбирать, исходя из требований сайта. Для начала:

Php_admin_value = 50M

Укажите обязательный параметр, который устраняет уязвимость :

Php_admin_value = 0

Переменные sendmail_path и open_basedir не указываются специально. Они будут переданы в качестве параметров fast-cgi в конфигурационном файле nginx. Таким образом, для каждого конкретного сайта можно определить свою настройку. :)

После того, как все необходимые параметры прописаны, следует перезагрузить конфигурацию php-fpm командой:

# service php5-fpm reload

Обработка php скриптов посредством nginx

Остаётся настроить nginx для работы с php-fpm. Готовый конфиг

Server { server_name example.com ; listen 80; access_log /var/log/nginx/example.com .access.log; error_log /var/log/nginx/example.com .error.log; charset utf-8; index index.php; root /var/www location / { try_files $uri $uri/ /index.php$args; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/run/php-www.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i [email protected]"; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/"; } }

example.com заменяем на свой домен.

Описание параметров :

try_files $uri =404; отобразит ошибку 404 в браузере пользователя, вместо сообщения no input file specified , в случае, когда данная ошибка имеет место.

fastcgi_pass — путь к сокету php-fpm.

Fastcgi_pass unix:/run/php-www.sock;

Следующая переменная устанавливает путь к sendmail и параметр, указывающий адрес электропочты администратора сайта. Замените [email protected] на что-то своё.

Fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i [email protected]";

Перечисляем каталоги для open_basedir: каталог с сайтом, каталог для сохранения временных файлов, каталог для файлов сессий.

Fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/";

Если требуется передать несколько параметров, до делать это следует так:

Fastcgi_param PHP_ADMIN_VALUE "sendmail_path=/usr/sbin/sendmail -t -i [email protected]\nopen_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/";

Как можно заметить, параметры разделяются при помощи переноса строки: \n .

Сохраняем все проделанные изменения и перезапускаем nginx.

# service nginx reload

Вконтакте

|

Nginx – один из самых популярных веб-серверов в мире, позволяющий размещать очень объемные сайты с высоким трафиком. Он, как правило, расходует меньше ресурсов, чем Apache. Также его можно использовать в качестве обратного прокси-сервера.

Данное руководство поможет установить Nginx на сервер Ubuntu 16.04.

Требования

  • Сервер Ubuntu 16.04.
  • Не-root пользователь с доступом к команде sudo (об этом – в ).

1: Установка Nginx

Пакет Nginx доступен в стандартном репозитории системы Ubuntu.

Поскольку это первое взаимодействие с системой пакетирования apt в текущей сессии, нужно обновить индекс пакетов. После этого можно установить Nginx.

sudo apt-get update
sudo apt-get install nginx

После этого пакетный менеджер установит веб-сервер и все его зависимости.

2: Настройка брандмауэра

Прежде чем запустить Nginx, нужно настроить брандмауэр для поддержки трафика этого сервиса. Во время установки Nginx регистрируется как сервис в ufw, потому разрешить трафик веб-сервера очень просто.

Откройте список настроек приложений ufw:

sudo ufw app list

Команда вернёт:

Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

Как видите, в списке есть три профиля Nginx:

  • Nginx Full: этот профиль открывает порт 80 (незашифрованный сетевой трафик) и 443 (зашифрованный трафик TLS/SSL).
  • Nginx HTTP: профиль для незашифрованного трафика HTTP на порт 80.
  • Nginx HTTPS: профиль для зашифрованного трафика TLS/SSL на порт 443.

Чтобы включить профиль, введите:

sudo ufw allow "Nginx HTTP"

Убедитесь в том, что профиль включен:

Команда должна сообщить, что трафик HTTP разрешен:

Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)

3: Тестирование веб-сервера

После установки Ubuntu 16.04 запустит Nginx автоматически. На данный момент веб-сервер должен запуститься и работать.

Чтобы убедиться в том, что Nginx запущен, запросите его состояние в системе инициализации systemd.

systemctl status nginx
nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-04-18 16:14:00 EDT; 4min 2s ago
Main PID: 12857 (nginx)
CGroup: /system.slice/nginx.service
├─12857 nginx: master process /usr/sbin/nginx -g daemon on; master_process on
└─12858 nginx: worker process

Как видите, сервис успешно запущен.

Также можно попробовать посетить стандартную посадочную страницу Nginx. Она доступна в браузере по доменному имени или IP-адресу.

Если вы не знаете своего IP-адреса, вы можете узнать его с помощью командной строки. Введите:

ip addr show eth0 | grep inet | awk "{ print $2; }" | sed "s/\/.*$//"

Команда вернёт несколько строк. Проверьте каждый адрес в браузере.

Также можно узнать, как видят ваш IP-адрес другие точки в сети.

sudo apt-get install curl
curl -4 icanhazip.com

Узнав вой IP, введите его в браузер, чтобы убедиться, что веб-сервер работает должным образом.

http://server_domain_or_IP

На экране должна появиться стандартная посадочная страница Nginx:

Welcome to nginx!
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

4: Управление процессами Nginx

Рассмотрим несколько базовых программ для управления веб-сервером.

Чтобы остановить Nginx, введите:

sudo systemctl stop nginx

Чтобы запустить, введите:

sudo systemctl start nginx

Для перезапуска используйте команду:

sudo systemctl restart nginx

Чтобы обновить настройки Nginx, не сбрасывая соединения, введите команду:

sudo systemctl reload nginx

По умолчанию Nginx автоматически запускается во время загрузки сервера. Это поведение можно отключить:

sudo systemctl disable nginx

Чтобы возобновить автозапуск сервиса, введите:

sudo systemctl enable nginx

5: Файлы и каталоги Nginx

Теперь вы знаете, как управлять сервисом. Пора ознакомиться с важными файлами и каталогами Nginx.

Контент

  • /var/www/htm: этот каталог содержит текущий контент сайта. По умолчанию в нём находится только стандартная посадочная страница, которую вы уже видели. Этот каталог можно изменить в конфигурационном файле Nginx.

Настройки сервера

  • /etc/nginx: каталог настроек nginx, в котором хранятся все конфигурационные файлы.
  • /etc/nginx/nginx.conf: главный конфигурационный файл Nginx, содержащий глобальные настройки веб-сервера.
  • /etc/nginx/sites-available: каталог, хранящий настроенные блоки server (виртуальные хосты) каждого отдельного сайта. Nginx не будет использовать эти блоки, пока ссылка на них не появится в каталоге sites-enabled (о нём речь пойдёт дальше). Как правило, этот каталог используется для настройки виртуальных хостов.
  • /etc/nginx/sites-enabled/: каталог, хранящий включенные блоки server. Чтобы включить блок, нужно создать символьную ссылку на файл, хранящийся в каталоге sites-available.
  • /etc/nginx/snippets: этот каталог хранит фрагменты настроек, которые можно включить в конфигурацию Nginx. Как правило, в качестве фрагментов добавляют потенциально повторяемые сегменты конфигурации.

Логи

  • /var/log/nginx/access.log: этот лог регистрирует все запросы, полученные веб-сервером Nginx (если не настроено другое поведение).
  • /var/log/nginx/error.log: этот лог хранит все сообщения об ошибках Nginx.

Заключение

Теперь веб-сервер Nginx установлен и готов к работе. Используйте его для обслуживания контента вашего сайта.

Nginx? Назначение, особенности, варианты настроек - это вещи, с которыми должен быть ознакомлен каждый веб-разработчик, чтобы тестировать свои наработки.

О nginx замолвим слово

Данный инструмент обладает одним главным и несколькими рабочими процессами. Первый занимается чтением и проверкой конфигурации. Также под его контролем находится управление рабочими процессами. Задача последних - обрабатывать поступающие запросы. В nginx применяется модель, что базируется на событиях. Также используются механизмы, зависимые от операционной системы, чтобы добиться эффективного распределения запросов непосредственно между рабочими процессами. Их количество всегда обозначено в конфигурационном файле. Значение может быть как фиксированным, так и устанавливаться автоматически, ориентируясь по числу процессорных ядер, с которыми можно работать. В nginx настройка системы и модулей проводится с помощью конфигурационного файла. Поэтому, если надо что-то изменить, то искать необходимо именно его. Обычно он находится в директиве /etc/nginx (но путь может меняться при использовании других систем) и имеет расширение.conf.

Запуск, перезагрузка и логи

Для этого необходимо заставить работать исполняемый файл. Настройка nginx-сервера возможна, только когда он запущен. Управление осуществляется благодаря вызову исполняемого файла с параметром -s. Для этого используйте такую запись:

nginx -s сигнал

В данном случае подставлять можно такие команды (должны поступать от пользователя, что запустил инструмент):

  1. Stop. Используется для быстрого завершения работы.
  2. Reload. Команда необходима, чтобы перезагрузить конфигурационный файл. Дело в том, что любые изменения не будут применены, пока файл работает. И чтобы они вступили в силу, необходима перезагрузка. Как только будет получен этот сигнал, главный процесс начнёт проверять правильность синтаксической составляющей конфигурационного файла и попробует применить имеющиеся там указания. В случае неудачи он откатит изменения и будет работать со старыми параметрами. Если всё произошло успешно, то будут запущены новые рабочие процессы, а старым будет отправлено требование завершиться.
  3. Quit. Применяется для плавного завершения работы. Применяется, если необходимо подождать, пока закончат обслуживаться текущие запросы.
  4. Reopen. Закрыть и открыть лог-файлы.

Использование утилит

Настройка процессов может осуществляться также с помощью средств Unix (в качестве примера будет рассмотрена утилита kill). Обычно они используют механизм отправки процессу сигнала напрямую с данными. Увязываются они с помощью ID. Эти данные хранятся в файле nginx.pid. Допустим, что нас интересует процесс №134. Тогда для плавного завершения нам необходимо отправить следующую информацию:

kill -s QUIT 1628

Допустим, что мы хотим просмотреть список всех запущенных файлов. Используем для этого утилиту ps. Команда же будет выглядеть следующим образом:

ps -ax | grep nginx

То есть, как видите, при использовании дополнительного инструментария указывается, что идёт именно его применение. А теперь давайте сконцентрируемся на том, как совершается nginx-настройка.

Структура конфигурационного файла

Установка и настройка nginx предусматривает работу с модулями. Они настраиваются с помощью директив, которые указываются в конфигурационном файле. Они бывают простыми и блочными. Первый тип директив состоит из имени и параметров, которые разделяются с помощью пробелов, а их конец указывается точкой с запятой - (;). Блочная имеет похожее строение. Но в данной директиве вместо окончания размещается набор дополнительных инструкций, которые размещают в фигурных скобах ({ указания }). Если в них можно разместить имена и параметры других процессов, то называются такие конструкции уже контекстом. В качестве примера можно привести http, location и server.

Раздача статического содержимого

Это одна их самых важных задач, которая стоит перед конфигурацией nginx. Под раздачей статистического содержимого подразумевают изображения и HTML-страницы (не динамические). Допустим, что нам нужна разовая работа по настройке nix nginx кластера. Сложно ли это сделать? Нет, и давайте рассмотрим пример. Прежде чем приступать к нему, необходимо детализировать условия задачи. Так, зависимо от запросов, файлы будут идти из разных локальных каталогов. Так, в /data/www мы имеем HTML-документы. А в каталоге /data/images содержатся изображения. Оптимальная настройка nginx в данном случае требует редактирования конфигурационного файла, в котором необходимо настроить блок server внутри http. Для поддержки будет использоваться также два location.

Реализация: server

Итак, для начала нам необходимо создать сами каталоги и разместить в них файлы с необходимыми расширениями (в html необходимо добавить содержимое). Затем открываем конфигурационный файл. В нём по умолчанию уже есть несколько блоков server, которые в массе своей закомментированы. Чтобы добиться оптимального результата, этот процесс необходимо проделать по отношению ко всем составляющим по умолчанию. Затем добавляем новый блок server с помощью такого кода:

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

Реализация: location

Определяется внутри server:

Наличие знака «/» необходимо, чтобы сравнивать получаемые данные и смотреть, есть ли такой адрес из обработанного запроса здесь. Если никаких проблем нет, то указываем путь /data/www к необходимому файлу, что находится в данной локальной системе. Если совпадение есть с несколькими блоками, то выбирается тот, у которого самый длинный префикс. В приведённом примере его длина равняется единице, то есть использование будет исключительно в том случае, если нет «конкурентов». Теперь давайте его усовершенствуем:

location /images/ {

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

location /images/ {

Это рабочий вариант, который случает стандартный Этот сервер без проблем может быть доступный на локальном компьютере, если пройти по адресу: http://localhost/. Как же это всё будет работать?

Принцип функционирования примера

Итак, когда придут запросы, что начинаются с с /images, то сервером файлы из соответствующего каталога будут отправляться пользователю. При его отсутствии будет передана информация, указывающая на ошибку 404. Если проводится настройка nginx на локальном компьютере, то при запросе http://localhost/images/example.png нами будет получен файл, месторасположение которого /data/images/example.png. При указании одного символа «/» поиск будет проводиться в директории /data/www. Но мы только изменили конфигурацию. Чтобы она начала работать, её необходимо перезагрузить. Для этого используйте команду nginx -s reload. В случае когда нормальная работа не является возможной, то в файлах error.log и access.log, расположенных в директиве /usr/local/nginx/logs, вы сможете поискать причину неисправностей.

Создание простого прокси-сервера

Можно сказать относительно nginx - настройка данного объекта является одним из частых применений (и довольно легким, между прочим). Здесь используется принцип сервера, который принимает запрос, а потом осуществляет перенаправление их к необходимым сайтам. После этого ожидается ответ от них, который направляет их к тому, кто поставил задачу. Поэтому давайте рассмотрим пример создания базовой точки. Она будет заниматься обслуживанием запросов пользователей и предоставлять им изображения из локального каталога. Итак, к блоку http добавляем ещё один server с таким содержимым:

А теперь давайте для вас расшифрую: создаётся простой сервер. Он будет прослушивать Не указать listen, то сервер будет работать на 80-м. Отображаться будут все запросы в рамках локальной файловой системы, которые направлены на каталог /data/up1 (конечно, его перед этим необходимо будет создать). Для возможности проверки там необходимо поместить файл index.html. Благодаря размещению директивы root в контексте server мы сможем воспользоваться location при любых условиях (поскольку, таким образом, снимаются ограничения доступа). Теперь работаем над созданием прокси-сервера. Для его работы нам понадобится директива proxy_pass, для которой будут указаны протокол, имя, а также порт объекта как параметры (при локальном подключении это будет выглядеть как http://localhost:8080). Получится такой результат:

proxy_pass http://localhost:8080;

location /images/ {

Если вы рассматриваете код и анализируете его, то можете заметить, что второй блок location был изменён. Так, в данном случае он может работать с типичными расширениями изображений. Немного по-другому его можно было бы отобразить таким образом:

location ~ \.(gif|jpg|png)$ {

root /data/images;

Итоговая конфигурация прокси-сервера выглядит следующим образом:

proxy_pass http://localhost:8080/;

location ~ \.(gif|jpg|png)$ {

root /data/images;

Он будет отфильтровывать запросы, в конце которых имеются указанные расширения, и отправлять их тому, кто попросил файлы. Не забывайте, что при желании проверить файл конфигурации его необходимо будет перезагрузить. И поверьте, это простейшая nginx-настройка. Если открыть конфигурационный файл сервера «Вконтакте» или другой крупной компании, у них будет кода больше, чем слов в этой статье.

Классической связкой для работы сайтов написанных на php считается apache + mod_php. Так как mod_php по умолчанию требует prefork_mpm, то apache для обработки каждого отдельного соединения создает отдельный процесс, что сильно не экономно с точки зрения расходования оперативной памяти.

Потом появился nginx - легковесный проксирующий веб-сервер и его начали ставить перед apache чтобы он занимался выдачей статики и не беспокоил apache по мелочам. Следующим логичным шагом является выключение из цепочки nginx - apache - php посредника в лице apache, чем мы и займемся.

php-fpm позволяет демонизировать php дабы избежать затрат на запуск процессов (чем страдает CGI) что умеет и FastCGI. Но php-fpm дает также другие полезные возможности:

  • запуск пулов обработчиков от имени заданных пользователей,
  • динамическое управление количеством запущенных обработчиков,
  • возможность перезапуска обработчиков в случае, если с ними что-то не так,
  • ведение лога медленных запросов по аналогии с mysql,
  • страницы статуса и пинга,
  • прочее.

Установка php-fpm в Debian крайне проста:

Aptitude install php5-fpm

После чего можно править два конфигурационных файла, которые достаточно хорошо документированы сами по себе, но большое количество слов может также мешать найти за ними суть. Первый (/etc/php5/fpm/php-fpm.conf) позволяет задать общие настройки:

include - из какой директории инклудить дополнительные конфиги,
pid - путь до файла с идентификатором процесса,
error_log - путь до лога ошибок,
syslog.facility - позволяет указать в какой лог писать,
syslog.ident - каким именем помечать записи в системном логе,
log_level - уровень лога от алерта до дебага,

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

emergency_restart_threshold - позволяет задать при каком количестве вылетов процессов с сигналами SIGSEGV или SIGBUS за указанный промежуток времени необходимо мягко перезапустить php-fpm,
emergency_restart_interval - заданный промежуток времени.
process_control_timeout - как долго потомкам ждать от мастера реакции на сигналы,
process.max - максимальное количество процессов для всех пулов,
process.priority - можно указать приоритет мастер-процесса,
daemonize - демонизировать или нет. Может пригодиться для дебага,
rlimit_files - количество доступных для мастер-процесса файловых дескрипторов,
rlimit_core - не осознал,
events.mechanism - в linux однозначно epoll,
systemd_interval - если ваша ос использует systemd, то можно задать периодичность отчетов о состоянии процессов. Будет актуально в Debian 8.

Второй конфиг является базовым для настройки пулов и находится по пути /etc/php5/fpm/pool.d/www.conf. В этом файле можно задать еще больше параметров и все они хорошо документированы в нем. Мы же удалим или переименуем этот файл и создадим свой конфигурационный файл.

Интересно, что в конфиге пула можно использовать имя пула в виде переменной $pool . За счет этого можно создать унифицированный конфигурационный файл и использовать его в качестве основы для новых пулов. Имя пула задается в квадратный скобках и предваряет собой блок параметров. Фактически все пулы можно описать в одном файле, но, кажется, так делать не стоит. Пример конфигурационного файла:


prefix = /var/www/$pool

user = $pool
group = $pool

listen = /var/run/phpfpm-$pool.sock
listen.owner = $pool
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 16
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4

pm.status_path = /fpmstat

request_slowlog_timeout = 3s
slowlog = /var/www/logs/$pool.slow.log

При необходимости:

access.log = /var/www/logs/$pool.access.log

Разберем параметры:

prefix - позволяет задать путь по умолчанию, который может использоваться в параметрах slowlog, listen, chroot, chdir, php_values, php_admin_values.
user и group - задает владельца и группу запускаемых процессов.
listen - указывает на каком сокете слушать. Поддерживаются как UNIX, так и TCP-сокеты. В случае, если веб-сервер и php-обработчики находятся на одном сервере, то лучше использовать UNIX-сокеты, так как это потенциально быстрее, так как нет оверхеда связанного с генерацией пакетов.
listen.owner, listen.group, listen.mode - позволяют задать параметры доступа к сокету. В качестве владельца указано имя совпадающее с именем пула. Необходимо создать соответствующего пользователя и убедиться, что для него нет ssh-доступа, конечно, если у вас не виртуальный хостинг. Группа указана www-data вследствие того, что под ней работает nginx и необходимо предоставить ему доступ к файлу сокета. Закрыть доступ остальным позволяют права 660.
pm - указывает как менеджер процессов будет управлять количеством дочерних процессов. Может быть статическим (постоянное количество процессов), динамическим (количество процессов может варьироваться в заданных пределах) и по требованию (когда нужно процесс запускается и убивается по истечении таймаута).
pm.max_children - максимальное количество дочерних процессов.
pm.start_servers - сколько процессов запускается при запуске php-fpm.
pm.min_spare_servers - минимальное количество ожидающих процессов. Если процессов меньше, чем значение параметра, то новые процессы будут созданы.
pm.max_spare_servers - максимальное количество ожидающих процессов. Если ожидающих процессов больше, чем значение параметра, то лишние процессы будут убиты.
pm.status_path - путь к странице статуса.
request_slowlog_timeout - время по прошествии которого запрос считается медленным.
slowlog - путь до файла лога медленных запросов.
access.log - путь до файла с логом доступа.

Другие интересные параметры:

pm.max_requests - количество обработанных запросов после которых процесс нужно перезапустить. Позволяет бороться с утечками памяти.
process.priority - задает приоритет процессов данного пула.
chroot - позволяет зачрутить процессы в указанную директорию. Однако все пути используемые php будут действовать относительно указанной директории, что требует дополнительной настройки.
security.limit_extensions - позволяет указать список расширений файлов для обработки php-fpm.

Также можно переопределять переменные окружения, к примеру:

и переопределять параметры из php.ini почти как это делается в.htaccess:

php_flag = off

То есть мы можем настраивать множество параметров php индивидуально для каждого пула.

Кстати говоря, для изменения параметров php можно использовать в директории сайта.

Реализация

Материал выше изложен как-то сумбурно. Попробуем посмотреть конкретный простой пример реализации.

Исходим из того, что nginx и php-fpm у вас уже установлены.

Теперь вам необходимо настроить виртуальный хост в nginx так чтобы запросы к статике обрабатывал сам nginx, а запросы к php-скриптам передавал на обработку php-fpm. Пример:

server {
listen 80;
server_name webpanels.spb.ru;

root /var/www/webpanels;
index index.php;

location ~ \.php$ {
try_files $uri =404;

fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;
}

location ~ ^/(fpmstat|ping)$ {
access_log off;
allow 127.0.0.1;
allow 123.123.123.123; #your-ip
deny all;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /fpmstat;
fastcgi_pass unix:/var/run/phpfpm-webpanels.sock;
}

location ~* ^.+.(html|jpg|jpeg|gif|css|png|js|ico|txt)$ {
expires 60d;
}
}

Здесь указано куда перенаправлять запросы. В нашем случае используется unix-сокет. Также указываем индексный файл и путь до файла. Как видно, все довольно просто. Данный пример можно использовать как формулу.

Теперь настроим php-fpm. В Debian общие настройки находятся в файле /etc/php5/fpm/php-fpm.conf:

pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
process.max = 64
process.priority = -5
rlimit_files = 1024
events.mechanism = epoll
include=/etc/php5/fpm/pool.d/*.conf

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

Пример настройки пула был дан выше. Стоит напомнить, что каждый пул запускается от отдельного пользователя, которого можно создать командой вида:

Useradd -m -d /var/www/webpanels -s /usr/sbin/nologin -c "webpanels site" -U webpanels

Кроме того, говорят, что для нормальной работы в файле /etc/php5/fpm/php.ini должен быть установлен следующий параметры:

cgi.fix_pathinfo = 0

Так же из-за отказа от Apache может понадобится сконвертировать правила mod_rewrite в правила понятные для nginx. Сделать это можно, к примеру, с помощью конвертеров доступных по адресам:

  • Администрирование доменных имен ,
  • Настройка Linux ,
  • Серверное администрирование ,
  • Системное администрирование

    • Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.

    В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.

    Технологии которые будут использованы в статье: nginx, php-fpm.

    Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе.
    Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.

    Поехали!

    Установка пакетного менеджера aptitude , обновление индекса и пакетов

    Устанавливаем:

    Sudo apt install aptitude
    Обновляем индекс.

    Sudo aptitude update
    Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).

    Sudo aptitude full-upgrade

    Установка и настройка nginx (версия >= 1.10.0)

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

    Sudo aptitude install nginx
    Запускаем.

    Sudo service nginx start
    Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.

    Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:

    Cd /etc/nginx/
    Посмотреть содержимое директории можно командой ls, с флагами -la будет удобнее просматривать содержимое каталога (в действительности эту команду с конкретными флагами можно описать детальнее и вернее, но у нас сегодня другая тема).

    Ls -la
    Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.

    Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).

    Cd /etc/nginx/sites-available
    Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.

    Важное отступление

    В случае установки nginx «с нуля», именно «с нуля», так как при удалении nginx командой
    sudo apt-get remove nginx или sudo apt remove nginx конфигурационные файлы остаются и если вы вдруг будете не понимать, почему nginx не работает и захотите его переустановить (обычно к такому прибегают начинающие пользователи Linux), то и после переустановки он не будет корректно работать, из-за того что в старых конфигурационных файлах (они не удаляются после удаления командой remove) прописаны неверные настройки, их придется удалить, либо настроить верно, только тогда nginx заработает.

    Рекомендую удалять командой sudo apt-get purge nginx или sudo apt purge nginx . Если вы используете пакетный менеджер aptitude, то команда sudo aptitude purge nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.


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

    Ls -la

    Создадим свой конфигурационный файл, который будет соответствовать названию домена нашего локального сайта (или реального, если уже знаете его название). Это удобно, в будущем, когда будет много конфигурационных файлов, то это избавит вас от путаницы в них. У меня этот файл будет называться project.local.

    Sudo touch project.local
    Посмотрим что получилось.

    Теперь откроем его в редакторе, я открою его в nano.

    Sudo nano project.local
    Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.

    Смотрите комментарии прям в конфигурационном файле.

    Server { listen 80; # порт, прослушивающий nginx server_name project.local; # доменное имя, относящиеся к текущему виртуальному хосту root /home/stavanger/code/project.local; # каталог в котором лежит проект, путь к точке входа index index.php; # add_header Access-Control-Allow-Origin *; # serve static files directly location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ { access_log off; expires max; log_not_found off; } location / { # add_header Access-Control-Allow-Origin *; try_files $uri $uri/ /index.php?$query_string; } location ~* \.php$ { try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; # подключаем сокет php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.ht { deny all; } }
    Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.

    Sudo nginx -t
    Если видим такую информацию как на скриншоте, значит у нас все верно, может продолжать настройку. Если вы получаете какие-либо ошибки, стоит перепроверить конфигурационный файл.

    Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.

    Cd /etc/nginx/sites-enabled/
    Теперь мы в нужном каталоге. Давайте создадим наш симлинк. Для создания используется команда ln с флагом -s, далее мы укажем путь до нашего конфига project.local.

    Sudo ln -s /etc/nginx/sites-available/project.local
    Посмотрим на наш созданный симлинк.

    Чтобы убедиться что мы делаем еще все верно опять запустим команду.

    Файл hosts

    Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.

    Открываем файл в редакторе nano.

    Sudo nano /etc/hosts
    У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.

    Установка php-fpm (>=7.0)

    sudo aptitude install php-fpm
    Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.

    Php-fpm7.0 -v

    Убеждаемся что все ок. Стартуем php-fpm.

    Sudo service php7.0-fpm start
    Если будете править конфиги, то не забывайте рестартовать демон. Это делает так. Но нам это не потребуется.

    Sudo service php7.0-fpm restart
    На этом установка и настройка php-fpm закончена. Правда, это все. Это не магия, путь до сокета php-fpm у нас уже был прописан в конфигурационном файле. Конечно, вам могут понадобиться какие-либо расширения php для разработки личных проектов, но их вы можете поставить по мере того как они будут требоваться.

    Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.

    Cd /home/stavanger/code/project.local
    Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.

    Cd .. sudo chmod -R 777 project.local
    На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.

    Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.

    С уважением к читателям, Stavanger.