Php fpm: Nginx, Php-Fpm и что это вообще?

Nginx, Php-Fpm и что это вообще?

PHP-FPM — это разновидность SAPI для PHP. Чтобы понять, что это такое, стоит рассказать о понятии SAPI.

FPM

SAPI, он же Server API. В php есть несколько таких API для разных вариантов его работы:

• CLI SAPI — в качестве консольной команды `php` для запуска наших кронов и других cli-программ (Command Line Interface)

• apxs2 SAPI — в качестве модуля к apache2

• CGI SAPI — в качестве запускаемого на каждом запросе CGI (сейчас так почти никто не делает)

• FPM SAPI — Fast Process Manager, написанный для PHP разработчиками из комании Badoo и теперь поддерживаемый сообществом

Работа с FPM отличается от работы с Apache в первую очередь тем, что FPM — это только PHP. Это не веб-сервер, не что-то умное. Это наоборот — максимально простой, легкий и быстрый менеджер процессов для PHP. В отличие от апача, он даже не использует http-протокол, а работает со специальным fastcgi-протоколом. В первую очередь FPM быстрее обрабатывает запросы благодаря его легковесности и простоте.

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

Нужно помнить, что независимо от того, какое SAPI вы используете, будь то модуль Apache, CGI или PHP-FPM — это не отнимает ни каких особенностей php. А первая его особенность:

• Один процесс одновременно обрабатывает один запрос. Это абсолютно так же свойственно для PHP-FPM, как и для Apache.

• Количество процессов определяет, сколько одновременно может «висеть» запросов в обработке.

• Точно также, как и Apache, FPM подвержен DoS-атакам путем «длительных запросов». Допустим, у Вас на сервере работает не более 50-ти процессов PHP-FPM, а это значит, что если 50 пользователей одновременно начнут делать upload файла (пусть даже небольшого, но главное, чтобы они делали это медленно) — пятьдесят первый пользователь получит ошибку 504, т.к. FPM не возьмет его запрос на обработку, пока не разберется с теми, что у него уже есть.

NGINX

Nginx — это разработанный Игорем Сысоевым http-proxy-сервер (он сам чаще называет его proxy-сервером, чем web-сервером). Это и есть его основное отличие от Apache (обычно к nginx приходят те, кто испытывает проблемы с Apache). Благодаря тому, что Nginx сам не выполняет никакой тяжелой работы, Игорь смог заложить в него прекрасную асинхронную событийную архитектуру.

Благодаря этой архитектуре nginx на порядки быстрее обрабатывает запросы, чем любой другой сервер и благодаря ей же потребляет при этом сильно меньше ресурсов. Как это происходит?

Один рабочий процесс nginx обрабатывает не один запрос пользователя (как apache), а тысячи этих запросов. Ввиду того, что nginx — это proxy-сервер, для него не составляет никакого труда получить запрос пользователя, отправить его на backend (например php-fpm), а пока бакенд занят трудом — обрабатывать остальные запросы пользователей, когда FPM ответит Nginx-у о том что тот самый первый запрос обработан и отдаст ответ, nginx передаст ответ назад пользователю.

Nginx работает как конвейер — он просто быстро перекладывает запросы и ответы между backend и пользователями.

В эту схему отлично вписалась асинхронная работа со статическими файлами. Благодаря тому, что в современном мире с файлами можно работать почти так же асинхронно, как и с backend, Nginx отлично разделяет работу на две части: статику отдает с диска, динамику обрабатывает в PHP-FPM.

В чем выигрыш?

Возьмем тот же Apache (prefork или itk). Мы выставили у него максимальное количество рабочих процессов, равное 35. Что это значит? Это значит, что мы сможем одновременно обработать только 35 запросов пользователей и это не важно — запрос это за статикой или за динамикой. 35 всего.

У вас на странице 100 картинок+js+css-ок? Значит, большая их часть будет висеть в очереди внутри сервера Apache и ждать, когда пользователь получит предыдущие 35 ответов. 

В случае с Nginx + PHP-FPM важнее всего количество процессов PHP-FPM. Мы можем поставить его таким же равным тридцати пяти. Что это значит? Это значит, что мы можем одновременно обрабатывать 35 запросов к динамике, запросы же к статике nginx разгребет своими силами в количестве 3000+ одновременных почти на любой слабой VPS.

Расход оперативной памяти при использовании Nginx+PHP-FPM меньше, чем на «голом» Apache, при равном количестве процессов (FPM и Apache). Скорость обработки запросов выше.

На расход CPU внутри PHP замена Apache на FPM никак не скажется. CPU в первую очередь кушает Ваш PHP-код, а пока его никто не оптимизирует, работать быстрее и экономичнее он не начнет.

Итог

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

• Появляется возможность перелопачивать тонны запросов за статикой, которой нет в Apache.

• Вы экономите оперативную память, что сказывается на цене оборудования или VPS.

• Появляется море приятного функционала самого Nginx.

• Пропадает возможность использовать htaccess, но честно скажу, конфигурация nginx куда более простая и понятная, чем htaccess.

Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04

Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе 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 -v

Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш 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

Посмотрим на наш созданный симлинк.

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

sudo nginx -t

Если все ок, едем дальше.

Файл hosts

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

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

sudo nano /etc/hosts

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

Не забываем сохранить файл. На этом настройка файла 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
    echo "Hello Habrahabr!";

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

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

PHP-FPM. НАСТРОЙКА И ТЮНИНГ | Evil Inside

; Имя пула (не должно совпадать с именем пользователя в системе)

[www]

; Адрес с портом или сокет, на который будут идти запросы FastCGI запросы

listen = /tmp/php—fpm.sock

; listen.backlog это параметр backlog функции TCP listen того сокета, на котором висит fpm

; параметр backlog отвечает за размер очереди одновременно ожидающих подключений к сокету,

; то есть инициированных (SYN — SYN,ACK — ACK), но еще не принятых сервером (established)

; —1 использует текущий hard limit net.core.somaxconn

listen.backlog = —1

; Список ip клиентов, которым разрешено подключение

listen.allowed_clients = 127.0.0.1

; Владелец Unix—сокета, его группа и права доступа к сокету

listen.owner = nginx

listen.group = nginx

listen.mode = 0660

; Воркеры пула будут работать от имени указанного пользователя и группы

user = nginx

group = nginx

; Метод порождения процессов

; static — строго постоянное количество процессов—обработчиков,

; dynamic — переменное количество обработчиков, для которых

;указываетсяминимальноеимаксимальное

; количество процессов, а также количество процессов—обработчиков

; «на подхвате»,которыедержатся

; готовыми на случай внезапного наплыва нагрузки, чтобы

; не терять время на порождение новых процессов—обработчиков,

; ondemand — режим, при котором обработчики порождаются только

; при поступлении запросов и завершаются спустя указанный период простоя.

pm = dynamic

; Число дочерних процессов, созданных для static, либо

; максимальное число, когда pm установлен в dynamic

pm.max_children = 7

; Число дочерних процессов, содаваемых при запуске (только dynamic)

pm.start_servers = 5

; Желаемое минимальное число неактивных процессов сервера (только dynamic)

pm.min_spare_servers = 5

; Желаемое максимальное число неактивных процессов сервера (только dynamic)

pm.max_spare_servers = 7

; Число запросов дочернего процесса, после которого процесс будет перезапущен

; Тут можно ограничить количество запросов, последовательно обслуживаемых одним процессом

; После этого процесс будет завершён и запущен снова — это может помочь от утечек памяти

pm.max_requests = 300

; Ссылка, по которой можно посмотреть страницу состояния FPM

;pm.status_path = /status

; Ссылка на ping—страницу мониторинга FPM (можно собрать своеобразный health—check)

;ping.path = /ping

; Эта директива может быть использована на настройки ответа на ping—запрос

;ping.response = pong

; Таймаут для обслуживания одного запроса, после чего рабочий

; процесс будет завершен (если не сработает max_execution_time)

;request_terminate_timeout = 0

; Таймаут для обслуживания одного запроса, после чего PHP backtrace

; будет сохранен в файл ‘showlog’

; Доступные единицы измерения: s(секунды), m(минуты), h(часы) или d(дни)

request_slowlog_timeout = 2s

; Лог—файл для медленных запросов

slowlog = /var/log/php—fpm/www—slow.log

; Устанавливает лимит дескрипторов открытых файлов rlimit.

; Значение по умолчанию: определяется значением системы.

;rlimit_files = 1024

; Устанавливает максимальное количество используемых ядер rlimit

;rlimit_core = 0

; Директория chroot окружения при старте

;chroot =

; Chdir изменяет текущую директорию при старте

;chdir = /var/www

; Перенаправление STDOUT и STDERR рабочего процесса в главный лог ошибок.

; Если не установлен, STDOUT и STDERR будут перенаправлены в /dev/null в

; соответствии со спецификацией FastCGI

;catch_workers_output = yes

; ограничение выполнение файлов по расширению имени

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

; Передача переменных окружения и настроек PHP пулу

;env[HOSTNAME] = $HOSTNAME

;env[PATH] = /usr/local/bin:/usr/bin:/bin

;env[TMP] = /tmp

;env[TMPDIR] = /tmp

;env[TEMP] = /tmp

;php_admin_value[sendmail_path] = /usr/sbin/sendmail —t —i —f [email protected]

;php_flag[display_errors] = off

php_admin_value[error_log] = /var/log/php—fpm/www—error.log

php_admin_flag[log_errors] = on

;php_admin_value[memory_limit] = 128M

php_value[session.save_handler] = files

php_value[session.save_path] = /var/lib/php/session

используем pm static для максимальной производительности / Блог компании Southbridge / Хабр

Неотредактированная версия статьи была изначально опубликована на haydenjames.io и публикуется здесь с разрешения ее автора.

Я в двух словах расскажу, как лучше всего настроить PHP-FPM, чтобы увеличить пропускную способность, снизить задержку и более стабильно использовать процессорные ресурсы и память. По умолчанию строка PM (process manager, менеджер процессов) в PHP-FPM имеет значение dynamic, а если у вас не хватает памяти, то лучше установить ondemand. Давайте сравним 2 варианта управления на основе документации php.net и посмотрим, чем от них отличается мой любимый static pm для большого объема трафика:

pm = dynamic — количество дочерних процессов настраивается динамически на основе следующих директив: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — процессы создаются по требованию (в отличие от динамического создания, когда pm.start_servers запускаются при запуске сервиса).
pm = static — количество дочерних процессов фиксировано и указывается параметром pm.max_children.

Подробности см. в полном списке глобальных директив php-fpm.conf.

Сходства менеджера процесса PHP-FPM с регулятором частоты процессора

Это может показаться оффтопом, но я собираюсь связать это с темой настройки PHP-FPM. У кого хоть раз не тормозил процессор — на ноутбуке, виртуальной машине или выделенном сервере. Помните масштабирование частоты процессора? Эти параметры, доступные для nix и Windows, могут повысить производительность и скорость отклика системы, если изменить параметр регулятора процессора с ondemand на performance*. На этот раз давайте сравним описания и посмотрим на сходства:

Governor = ondemand — динамическое масштабирование частоты процессора в зависимости от текущей нагрузки. Резко переходит на максимальную частоту, а затем снижает ее, когда увеличиваются периоды простоя.
Governor = conservative = динамическое масштабирование частоты в зависимости от текущей нагрузки. Увеличивает и уменьшает частоту плавнее, чем ondemand.
Governor = performance — частота всегда максимальная.

Подробности см. в полном списке параметров регулятора частоты процессора.

Видите сходство? Я хотел показать это сравнение, чтобы убедить вас, что лучше всего использовать pm static для PHP-FPM.

Для регулятора процессора параметр performance помогает безопасно увеличить производительность, потому что она почти полностью зависит от лимита процессора сервера. Кроме этого, конечно, есть еще такие факторы, как температура, заряд аккумулятора (в ноутбуке) и другие побочные эффекты постоянной работы процессора на 100%. Настройка performance обеспечивает самую быструю работу процессора. Почитайте, например, о параметре force_turbo в Raspberry Pi, с которым панель RPi будет использовать регулятор performance, где улучшение производительности будет заметнее из-за низкой тактовой частоты ЦП.

Использование pm static для достижения максимальной производительности сервера

Параметр PHP-FPM pm static во многом зависит от свободной памяти на сервере. Если памяти мало, лучше выбрать ondemand или dynamic. С другой стороны, если у вас есть память, можно избежать лишних издержек менеджера процесса PHP, установив pm static на максимальную емкость сервера. Другими словами, если все хорошо подсчитать, нужно установить pm.static на максимальный объем процессов PHP-FPM, которые могут выполняться, не создавая проблем с нехваткой памяти или кэша. Но не так высоко, чтобы перегрузить процессоры и накопить кучу операций PHP-FPM, ожидающих выполнения.

На скриншоте выше у сервера установлено pm = static и pm.max_children = 100, и это занимает примерно 10 ГБ из имеющихся 32. Обратите внимание на выделенные столбцы, тут и так все понятно. На этом скриншоте было примерно 200 активных пользователей (более 60 секунд) в Google Analytics. На этом уровне примерно 70% дочерних процессов PHP-FPM все еще бездействуют. Это значит, что PHP-FPM всегда установлен на максимальный объем ресурсов сервера независимо от текущего трафика. Простаивающий процесс ждет пиков трафика и реагирует моментально. Вам не приходится ждать, пока pm создаст дочерние процессы, а потом завершит их, когда истечет период pm.process_idle_timeout. Я установил очень большое значение для pm.max_requests, потому что это рабочий сервер без утечек памяти в PHP. Вы можете установить pm.max_requests = 0 со static, если полностью уверены в имеющихся и будущих скриптах PHP. Но лучше перезапускать скрипты со временем. Установите большое число запросов, ведь мы хотим избежать лишних издержек pm. Например, хотя бы pm.max_requests = 1000 — в зависимости от количества pm.max_children и числа запросов в секунду.

На скриншоте показана команда Linux top, фильтрованная по u (user) и имени пользователя PHP-FPM. Показано только первые 50 или около того процессов (точно не считал), но, по сути, top показывает топ статистики, которая помещается в окно терминала. В этом случае с сортировкой по % ЦП (%CPU). Чтобы посмотреть все 100 процессов PHP-FPM, выполните команду:

top -bn1 | grep php-fpm

Когда использовать pm ondemand и dynamic

Если использовать pm dynamic, возникают подобные ошибки:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Попробуйте изменить параметр, ошибка никуда не денется, как описывается в этом посте на Serverfault. В этом случае значение pm.min было слишком маленьким, а раз веб-трафик сильно меняется и у него есть высокие пики и глубокие спады, сложно адекватно настроить pm dynamic. Обычно при этом используется pm ondemand, как советуют в том же посте. Но это еще хуже, ведь ondemand завершает бездействующие процессы до нуля, когда трафика мало или нет вообще, и в итоге вы все равно будете мучиться с издержками при изменении трафика. Если, конечно, вы не установили огромное время ожидания. И тогда лучше уж использовать pm.static + высокое число pm.max_requests.

PM dynamic и особенно ondemand могут пригодиться, если у вас несколько пулов PHP-FPM. Например, вы размещаете несколько аккаунтов cPanel или несколько веб-сайтов в разных пулах. У меня есть сервер, где, допустим, 100+ аккаунтов cpanel и примерно 200 доменов, и pm.static или даже dynamic меня бы не спас. Тут нужен только ondemand, ведь больше двух третей веб-сайтов получают мало трафика или вообще никакого, а с ondemand все дочерние процессы отвалятся, что сэкономит нам уйму памяти! К счастью, разработчики cPanel это заметили и установили значение по умолчанию ondemand. Раньше, когда значением по умолчанию был dynamic, PHP-FPM вообще не подходил для нагруженных общих серверов. Многие использовали suPHP, потому что pm dynamic потреблял память даже при бездействующих пулах и аккаунтах cPanel PHP-FPM. Скорее всего, при хорошем трафике вы не будете размещаться на сервере с большим числом пулов PHP-FPM (общий хостинг).

Заключение

Если вы используете PHP-FPM и трафик у вас серьезный, менеджеры процессов ondemand и dynamic для PHP-FPM будут ограничивать пропускную способность из-за присущих им издержек. Изучите свою систему и настройте процессы PHP-FPM в соответствии с максимальной емкостью сервера. Сначала задайте pm.max_children в зависимости от максимального использования pm dynamic или ondemand, а затем увеличьте это значение до уровня, где память и процессор будут работать без чрезмерной перегрузки. Вы заметите, что с pm static, раз у вас все хранится в памяти, пики трафика со временем будут вызывать меньше пиков для процессора, а средние значения нагрузки сервера и процессора выровняются. Средний размер процесса PHP-FPM зависит от веб-сервера и требует настройки вручную, поэтому более автоматизированные менеджеры процессов — dynamic и ondemand — более популярны. Надеюсь, статья была полезной.

UPD Добавлена диаграмма бенчмарка ab. Если процессы PHP-FPM находятся в памяти, производительность увеличивается за счет потребления памяти, где они сидят и ждут. Найдите для себя оптимальный вариант.

PHP: Настройка — Manual

С помощью FPM вы можете запускать несколько пулов процессов с различными настройками.
Эти параметры могут быть переданы пулу.

Можно передать дополнительные переменные окружения и обновить настройки
PHP для определенного пула.
Для этого вам необходимо добавить следующие параметры в файл настройки пула.

перезапишут их предыдущие значения.
Пожалуйста, обратите внимание, что определения

не
будут будут перезаписывать ранее определенные в

значения,
а добавят новые значения.

Настройки, определенные через php_admin_value и php_admin_flag,
не могут быть перезаписаны через ini_set().

Начиная с версии 5.3.3 настройки PHP можно устанавливать через веб-сервер.

Веб-сервер на основе Nginx и PHP-FPM

Существуют различные схемы построения веб-серверов для передачи данных по протоколу HTTP. Среди них достойное место по производительности занимают схемы с использованием «Nginx» в качестве внешнего (кэширующего, front-end) сервера. «Nginx» разработан для отдачи статических данных, при этом, он показывает высокое быстродействие и нагрузочную способность (см. Nginx vs Cherokee vs Apache vs Lighttpd), генерировать же динамическое содержимое он не способен. Поэтому, он часто применяется в связке с внутренним (back-end) сервером для обработки динамических данных которые потом отдаются «Nginx» как статические без участия внутреннего сервера. В качестве внутреннего сервера может применяться «Apache2» или, что и рассматривается в данной статье, «PHP-FPM».

В данной статье рассматривается установка и настройка связки Nginx и PHP-FPM на локальной ЭВМ, если требуется работа на выделенном сервере, то следует обратится к более серьезным инструкциям или/и непосредственной помощи специалистов

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

Сервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале

sudo apt-get install nginx nginx-extras

Установку же «PHP-FPM» можно произвести, например, командой

sudo apt-get install php5-cli php5-common php5-mysql php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt

Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:

1. Должно быть запрещено выполнение PHP-кода из открытых для записи директорий. Например, директории для загрузки аватаров, файлов или директории доступные также FTP-серверу, который позволяет произвести запись в них.

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

3. Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости.

4. Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов).

Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами

sudo service nginx stop
sudo service php5-fpm stop

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

Прежде всего, следует открыть файл «/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

Настройка Nginx

Основные настройки «Nginx» хранятся в файле «/etc/nginx/nginx.conf». Настройки базового сайта хранятся в файле «/etc/nginx/sites-available/default». Базовый конфигурационный файл сайта принято помещать в папку «/etc/nginx/sites-available/» и затем включить его путём добавления символической ссылки на этот файл в папке «/etc/nginx/sites-enabled/». Например, создадим конфигурационный файл для сайта с доменным именем (для примера выбрано «example.com») в названии для удобства

sudo touch /etc/nginx/sites-available/example.com
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

и откроем его для редактирования

sudo nano /etc/nginx/sites-available/example.com

При редактировании данного файла необходимо учитывать синтаксис конфигурации «Nginx» (см. HttpCoreModule), готовые советы по настройке связки «Nginx + PHP-FPM» (см. PHPFcgiExample) и следовать некоторым правилам/рекомендация для достижения эффективной работы сервера (см. Pitfalls).

Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «include» позволяющей указать «Nginx», что следует загрузить другой конфигурационный файл и затем продолжить чтение текущего. Создадим в папке «/etc/nginx/» каталог «common», где будут хранится общие настройки для сайта, которые затем будут подгружаться из основного конфигурационного файла «/etc/nginx/sites-available/example.com» с помощью директивы «include»

sudo mkdir /etc/nginx/common

Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных

sudo touch /etc/nginx/common/upstream

и откроем его для редактирования

sudo nano /etc/nginx/common/upstream

и добавим в него строчки

upstream php-fpm
{
	# PHP5-FPM сервер
	server unix:/var/run/php5-fpm.sock;
}

где «php-fpm» – название для сервера выгрузки данных, для удобства.

Редактируем файл «/etc/nginx/sites-available/example.com». Добавляем строчку

include common/upstream;

для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.

Далее описываем перенаправление от HTTP к HTTPS, если, конечно, это планируется. В таком случае необходимо наличие сертификатов для HTTPS (см. Сертификаты)

server
{
	listen 80;
	server_name example.com www.example.com;
	return 301  https://$server_name$request_uri;
}

иначе, можно опустить эти строчки.

Начинаем описывать конфигурацию сайта

server
{

Сетевой порт для приема соединений: 80 — обычный HTTP; 443 — HTTPS (см. выше)

	# Порты
	listen	80;
	listen	443	ssl;	# использовать шифрование для этого порта

Корневая директория сайта работающего на данном сервере

	root			/var/www;

Возможные имена индексных файлов (их «Nginx» пытается открыть если он получил запрос вида «example.com/», вместо явного «example.com/index.html»)

	index			index.php index.html index.htm;

Имя сервера – обычно доменное имя Вашего сервера

	server_name		example.com www.example.com;

Шифрование

Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout example.com_nginx.key -out example.com_nginx.crt

При этом программа запросит данные, среди них «commmon name» — следует указать доменное имя сервера. Можно использовать шаблон, если необходимо учесть домены нижнего уровня, например, «*example.com». Иначе могут возникнуть проблемы с некоторыми программами, например, «davfs2» (см man davfs2.conf).

Но можно пойти дальше и воспользоваться сервисом «StartSSL» где выдают бесплатные сертификаты для личного пользования (см. startssl.com и Получение и установка бесплатного SSL-сертификата), но сам приватный ключ (который нельзя никому показывать) лучше сгенерировать самому, например, так

openssl genrsa -out example_nginx.com.key 4096

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

 openssl req -new -sha256 -key example.com_nginx.key -out example.com.csr

открыть полученный файл текстовым редактором

 nano example.com.csr

и скопировать его содержимое в текстовое поле на сайте «StartSSL» для запроса сертификата (см. ссылки на подробные инструкции выше). Файл *.csr больше не нужен. Затем загружаем подписанный сертификат (например, файл называется signed.crt) и объединяем его с сертификатом того кто этот сертификат подписал

wget https://www.startssl.com/certs/sub.class1.server.ca.pem
cat signed.crt sub.class1.server.ca.pem > example.com_nginx.crt

Файл «signed.crt» можно удалить.

Копируем секретный ключ в системную папку и выставляем права доступа

sudo cp example.com_nginx.key /etc/ssl/private/
sudo chown www-data:www-data /etc/ssl/private/example.com_nginx.key
sudo chmod 400 /etc/ssl/private/example.com_nginx.key

И в соседнюю папку сам сертификат

sudo cp example.com_nginx.crt /etc/ssl/certs/

Для пущей надежности можно сгенерировать ключ Диффи-Хеллмана (тоже секретный файл который очень долго генерируется)

openssl dhparam -out example.com.dh.key 4096
sudo cp example.com_nginx.dh.key /etc/ssl/private/
chown www-data:www-data example.com_nginx.dh.key
chmod 400 example.com_nginx.dh.key

Продолжаем редактировать конфигурационные файлы.

Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»

sudo touch /etc/nginx/common/ssl

Редактируем файл «/etc/nginx/common/ssl»

sudo nano /etc/nginx/common/ssl

Файлы сертификатов для «HTTPS»

ssl_certificate /etc/ssl/certs/example.com_nginx.crt;		# сертификат (можно свободно распространять)
ssl_certificate_key /etc/ssl/private/example.com_nginx.key;	# приватный ключ (секретный файл - НИКОМУ НЕ ПОКАЗЫВАТЬ)

Дополнительные параметры требуемые для «HTTPS»

ssl_dhparam				/etc/ssl/private/example.com_nginx.dh.key;	# писать эту строчку только если файл есть
ssl_session_timeout			20m;	# время 20 минут
ssl_session_cache			shared:SSL:20m;	# размер кеша 20МБ
ssl_protocols				TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers		on;
ssl_ciphers				ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;

На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл. После завершения описания конфигурации (см. ниже) можно будет проверить надежность сервисом «SSLLabs»

Продолжаем редактировать файл «/etc/nginx/sites-available/example.com». Подгружаем созданный выше конфигурационный файл с описанием настроек SSL

	# Настройка шифрования SSL
	include common/ssl;

Прочие настройки

Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища на основе «ownCloud», эта строчка по сути делает то же что и указанные выше при настройке «PHP-FPM», только теперь для «Nginx»)

	client_max_body_size		200m;	# увеличение максимального объема файла для загрузки до 200МБ

Ещё одна опция

	# Buffers
	fastcgi_buffers 64 4K;

Безопасность

Опишем настройки безопасности в отдельном файле

sudo touch /etc/nginx/common/security
sudo nano /etc/nginx/common/security

И укажем в нём

add_header		X-Frame-Options		"SAMEORIGIN";
add_header		X-Content-Type-Options	"nosniff"; 

Сохраним и закроем файл, а затем подключим его строкой

	include common/security;

Сжатие

Для экономии трафика лучше включить сжатие (иногда со влючённым сжатием могут возникать проблемы, например, у «ownCloud», см. ниже). Опишем настройки сжатия в отдельном файле

sudo touch /etc/nginx/common/gzip
sudo nano /etc/nginx/common/gzip

и введём

gzip		on;
gzip_disable	"msie6";
gzip_comp_level	6;
gzip_min_length	1100;
gzip_buffers	16 8k;
gzip_proxied	any;
gzip_types	text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/javascript application/json application/xml+rss; 

Следует сохранить, закрыть и затем подключить этот файл срочкой

	include common/gzip;

Директории сайта

Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))

Важно учитывать порядок проверки директив «location» (см. location)

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

Корневая директория

	location "/"
		{
		index index.php index.html index.htm;	# варианты индексных файлов если имя файла в запросе не задано
		try_files	$uri $uri/	=404;	# проверить есть ли файл из запроса на диске, иначе - вернуть ошибку 404
		}

К примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так

	location "/"
	{
		index index.php index.html index.htm;
		try_files	$uri $uri/ /wordpress/;	# проверяем существования файла или папки, иначе перенаправляем к example.com/wordpress
		rewrite "^/$" "/wordpress/" redirect;	# перенаправляем запрос example.com/ к example.com/wordpress
	}

Соответственно сам сайт должен размещаться в каталоге «/var/www/wordpress/»

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

	include common/locations/*.inc;

которая укажет «Nginx», что нужно подключить все файлы в директории «/etc/common/locations/» которые соответствуют шаблону «*.inc», таким образом, если один из файлов нужно будет временно отключить, то его можно просто переименовать убрав расширение в имени. Создадим директорию где будут хранится эти файлы

sudo mkdir /etc/nginx/common/locations

Некая директория «/var/www/restricted» доступная только авторизованным пользователям сервера. Создадим для неё файл конфигурации «/etc/nginx/common/locations/restricted.inc»

sudo touch /etc/nginx/common/locations/restricted.inc
sudo nano /etc/nginx/common/locations/restricted.inc

со строчками

location ^~ "/restricted/"
{
	auth_basic		"Access to this folder is restricted";
	auth_basic_user_file	htpasswd;
	autoindex	on;
	allow		all;
	try_files	$uri $uri/ =404;
}

Синтаксис «^~» указывает, что при совпадении здесь директивы «location» ниже проверяться не будут.

Этот конфигурационный файл подключится автоматически, за счёт шаблона (см. выше).

WordPress

Для более полной информации по настройке «Nginx» для «WordPress» следует обратиться к официальной документации (см. codex.wordpress.org/Nginx и wiki.nginx.org/WordPress)

Натройки «Wordpress», который, в данном примере, находится в папке «/var/www/wordpress» будут описаны в файле «/etc/nginx/common/locations/wordpress.inc»

sudo touch /etc/nginx/common/locations/wordpress.inc
sudo nano /etc/nginx/common/locations/wordpress.inc

Указываем виртуальную директорию (используется для удобства и читабельности) в которую будут перенаправляться запросы при необходимости

location @wordpress
{
	rewrite "^/wordpress/(.*)$" "/wordpress/index.php?q=$1" last;
}

Аналогично примеру выше предотвращаем обработку остальных директив «location»

location ^~ "/wordpress/"
{
	root		"/var/www";
	index		index.php;
	try_files	$uri $uri/ @wordpress;	# проверить существует ли файл, иначе направить в виртуальную директорию
	
	# Ограничение доступа к секретному файлу
	location ~* "^/wordpress/wp-config.php(/.*)?$"
	{
		deny all;
		return 404;
	}
	# Ни в коем случае не выполнять файлы php в папках куда их может кто-то загрузить
	# Проще всего просто заблокировать любые операции с такими файлами регулярным выражением
	location ~* "/(uploads|files)/.*\.php.?(/.*)?$"
	{
		deny all;
		return 404;
	}
	# Перенаправление php-файлов к серверу «PHP-FPM» см. ниже по статье
	location ~ "^(/wordpress/.+?\.php)(/.*)?$"
	{
		# Проверяем существование файлов, пробуем исправить если нет, иначе выдаём ошибку
		# $1 указывает на первую скобку в регулярном выражении выше - собственно адрес запрошенного php файла
		try_files	$1 $uri $uri/ $uri/index.php	=404;
		include common/php-fpm;
	}
	# Другие настройки, см. ниже по статье
	include common/deny;
	include common/cache;
}

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

ownCloud

Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».

Создадим файл настроек для «ownCloud» и отредактируем его

sudo touch /etc/nginx/common/locations/owncloud.inc
sudo nano /etc/nginx/common/locations/owncloud.inc

Многое аналогично примеру для «Wordpress»

location ^~ "/owncloud/"
{
	root		"/var/www"; 
	index index.php index.html index.htm;
	try_files	$uri $uri/ =404;
	# ownCloud предоставляет свои красивые страницы для ошибок 404 и 403 - используем их
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
 
	# Отключаем сжатие - оно создаёт проблемы для клиента синхронизации ownCloud
	gzip			off;
	# Переопределяем глобальную настройку описанную в главном файле
	# увеличиваем максимальный размер загружаемых файлов
	client_max_body_size	16G;
	# Запрещаем читать секретные файлы
	location ~* "^/owncloud/(\.user\.ini|data|config|db_structure\.xml|README)(/.*)?$"
	{
		deny all;
		return 404;
	}
	location ~ "^(/owncloud/.+?\.php)(/.*)?$"
	{
		try_files	$1 $uri $uri/ $uri/index.php	=404;
		include common/php-fpm;
	}
	include common/deny;
	include common/cache;
}

Начиная с версии «ownCloud» 8 появился отдельный файл для переопределения некоторых настроек «PHP-FPM» взамен указанных в «/etc/php5/fpm/php.ini». Открыть его можно командой

sudo nano /var/www/owncloud/.user.ini

и в нем найти строчки

upload_max_filesize=513M
post_max_size=513M

и поменять значения на требуемые.

Базовые ограничения

Выше была написана строчка для подключение файла «/etc/nginx/common/deny»

include common/deny;

рассмотрим его содержание. В нём идет запрет доступа к некоторым стандартным файлам. Создадим этот файл

sudo touch /etc/nginx/common/deny
sudo nano /etc/nginx/common/deny

с содержанием

# Запрет доступа к .htaccess и .htpasswd файлам
location ~* "/\.(htaccess|htpasswd)$"
{
	deny all;		# запретить все для всех
	return 404;		# вернуть код ошибки
}

Следует быть бдительным, неверно указанный шаблоны для запрета доступа (не только здесь но и в примерах выше) могут сильно навредить. Например, клиент ownCloud может начать удалять файлы которые не сможет загрузить на сервер из-за неправильного запрета где-то в конфигурационном файле

Следует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой

sudo find /var/www/ -name .htaccess

Вызов PHP-FPM

В примерах выше использовался файл «/etc/nginx/common/php-fpm» — в нём идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

В файле «php.ini» должно быть установлено «cgi.fix_pathinfo = 0;»
Также, в файле «/etc/php5/fpm/pool.d/www.conf» должно присутствовать ограничение на разширение имени
исполняемых скриптов — «security.limit_extensions = .php .php3 .php4 .php5»

Создаём этот файл

sudo touch /etc/nginx/common/php-fpm
sudo nano /etc/nginx/common/php-fpm

с содержанием

# Настройки порта или сокета PHP-FPM производятся в файле "/etc/php5/fpm/pool.d/www.conf"
fastcgi_pass	php-fpm;
# Порядок важен - строчка "include fastcgi_params" должна быть первой
include fastcgi_params;
fastcgi_split_path_info			^(.+?\.php)(/.*)?$;
# Вместо переменной "$document_root" можно указать адрес к корневому каталогу сервера и это желательно (см. http://wiki.nginx.org/Pitfalls)
fastcgi_param	SCRIPT_FILENAME		$document_root$fastcgi_script_name;
fastcgi_param	PATH_TRANSLATED		$document_root$fastcgi_script_name;
# См. http://trac.nginx.org/nginx/ticket/321
set		$path_info		$fastcgi_path_info;
fastcgi_param	PATH_INFO		$path_info;
# Additional variables
fastcgi_param	SERVER_ADMIN		[email protected];
fastcgi_param	SERVER_SIGNATURE	nginx/$nginx_version;
fastcgi_index	index.php;

Кеширование

Выше, в примерах, был упомянут файл «/etc/nginx/common/cache»

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

sudo touch /etc/nginx/common/cache
sudo nano /etc/nginx/common/cache

где укажем

location ~* ".+\.(?:ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|css|swf|js|atom|jpe?g|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$"
	{
		access_log	off;
		log_not_found	off;
		expires		max;
	}

Окончание

Закрываем фигурные скобки директивы «server» в «/etc/nginx/sites-available/example.com»

}

На этом правка файла «/etc/nginx/sites-available/example.com» завершена. Убедитесь в том, что все фигурные скобки «{ }» закрыты корректно и части файла верно вложены друг в друга («location» внутри «server» и т.п.).

Сохраняем все изменённые файлы.

Теперь можно перезапустить демоны

sudo service nginx restart
sudo service php5-fpm restart

Проверить свой сайт можно создав файл «info.php» с содержанием

<?php
phpinfo();
?>

затем скопировав его, например, в «/var/www/wordpress/wp-content/uploads/», затем открыв адрес в браузере «http://example.com/wordpress/wp-content/uploads/info.php», если он выполнится вместо того чтобы просто сохранится — то что-то настроено неправильно, в этой директории php файлы выполняться не должны ни в коем случае (она доступна для загрузки)

Проверить свой сайт на скорость и прочее можно тут:

Установка и настройка nginx php-fpm php7.1 на CentOS 7

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

Если у вас есть желание освоить Linux с нуля, не имея базовых знаний, рекомендую познакомиться с онлайн-курсом Administrator Linux.Basic в OTUS. Курс для новичков, для тех, кто хочет войти в профессию администратора Linux. Подробности по .

Данная статья является частью единого цикла статьей про сервер Centos. Если вы хотите использовать более новую версию системы, то читайте как настроить такой же web сервер на CentOS 8.

Введение

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

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

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

Подопытным сервером будет выступать виртуальная машина от ihor, характеристики следующие:

Это кастомная настройка параметров. Они не оптимальны по цене, но мне были нужны именно такие.

Установка 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 и добавляем в автозагрузку.

# systemctl start nginx
# systemctl enable nginx

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

Если страница не открывается, то скорее всего вы не настроили 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.zeroxzed.ru/log/ssl-access.log main;
    error_log /web/sites/hl.zeroxzed.ru/log/ssl-error.log;

    keepalive_timeout		60;
    ssl_certificate		/etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem;
    ssl_certificate_key		/etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem;
    ssl_protocols 		TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-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 / {
    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.ru/www/;
    fastcgi_param SCRIPT_FILENAME /web/sites/hl.zeroxzed.ru/www$fastcgi_script_name;
    fastcgi_param PATH_TRANSLATED /web/sites/hl.zeroxzed.ru/www$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param CONTENT_TYPE $content_type;
    fastcgi_param CONTENT_LENGTH $content_length;
    fastcgi_param HTTPS on;
    fastcgi_intercept_errors on;
    fastcgi_ignore_client_abort off;
    fastcgi_connect_timeout 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/www/;
    index index.php index.html index.htm;
    access_log /web/sites/p1m2a.zeroxzed.ru/log/ssl-access.log main;
    error_log /web/sites/p1m2a.zeroxzed.ru/log/ssl-error.log;

    keepalive_timeout		60;
    ssl_certificate		/etc/letsencrypt/live/p1m2a.zeroxzed.ru/fullchain.pem;
    ssl_certificate_key		/etc/letsencrypt/live/p1m2a.zeroxzed.ru/privkey.pem;
    ssl_protocols 		TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-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_script_name;
    fastcgi_param PATH_TRANSLATED /web/sites/p1m2a.zeroxzed.ru/www$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param CONTENT_TYPE $content_type;
    fastcgi_param CONTENT_LENGTH $content_length;
    fastcgi_intercept_errors on;
    fastcgi_ignore_client_abort off;
    fastcgi_connect_timeout 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;
    }
}

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 и продолжаем настройку производительного веб сервера. Более подробно о настройке 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-fpm и наиболее популярные модули, которые могут пригодится в процессе эксплуатации веб сервера.

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

Запускаем 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): [email protected]
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 и добавляем в автозагрузку.

# 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 по-умолчанию сконфигурирована для работы с 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 сервера:

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

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

Напоминаю, что данная статья является частью единого цикла статьей про сервер Centos.

Онлайн курс по Linux

Если у вас есть желание освоить операционную систему Linux, не имея подходящего опыта, рекомендую познакомиться с онлайн-курсом Administrator Linux. Basic в OTUS. Курс для новичков, адаптирован для тех, кто только начинает изучение Linux. Обучение длится 4 месяца.

Что даст вам этот курс:

• Вы получите навыки администрирования Linux (структура Linux, основные команды, работа с файлами и ПО).
• Вы рассмотрите следующий стек технологий: Zabbix, Prometheus, TCP/IP, nginx, Apache, MySQL, Bash, Docker, Git, nosql, grfana, ELK.
• Умение настраивать веб-сервера, базы данных (mysql и nosql) и работа с сетью.
• Мониторинг и логирование на базе Zabbix, Prometheus, Grafana и ELK.
• Научитесь командной работе с помощью Git и Docker.

Смотрите подробнее программу по .

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Главная — PHP-FPM

Что такое PHP-FPM?

PHP-FPM (FastCGI Process Manager) — это альтернативная реализация PHP FastCGI с некоторыми дополнительными функциями, полезными для сайтов любого размера, особенно для более загруженных сайтов.

Эти функции включают:

• Адаптивное создание процессов (НОВИНКА!)
• Базовая статистика (аля Apache’s mod_status) (NEW!)
• Расширенное управление процессами с плавной остановкой / запуском
• Возможность запускать воркеры с разными uid / gid / chroot / environment и разными php.ini (заменяет safe_mode)
• Stdout и stderr ведение журнала
• Аварийный перезапуск при случайном разрушении кеша опкодов
• Поддержка ускоренной загрузки
• Поддержка «медленного журнала»
• Улучшения FastCGI, такие как fastcgi_finish_request () — специальная функция для завершения запроса и очистки всех данных, продолжая делать что-то трудоемкое (преобразование видео, обработка статистики и т. Д.)

… и многое другое.

Он не был разработан с учетом виртуального хостинга (большое количество пулов), однако его можно адаптировать для любой модели использования.

Новости

29.11.2011
Официально. PHP-FPM больше не помечается как «экспериментальный» с PHP 5.4.0RC2.

11 января 2011 г.
Патч PHP-FPM выпущен для PHP 5.2.17. Скачать.

16 декабря 2010 г.
Патч PHP-FPM выпущен для PHP 5.2.16. Скачать.

9 декабря 2010 г.
Патч PHP-FPM выпущен для PHP 5.2.15. Скачать.

22 июля 2010 г.
PHP 5.3.3 выпущен и теперь объединяет PHP-FPM со всеми новыми улучшениями — адаптивным порождением процессов, новым форматом файла INI и включает поддержку, основные показатели для отчетности и многое другое.Если ваш код совместим с PHP 5.3, настоятельно рекомендуется выполнить обновление, чтобы воспользоваться преимуществами встроенной поддержки PHP-FPM (не говоря уже о mysqlnd и всех других новых функциях).

Патч PHP-FPM, выпущенный для PHP 5.2.14. Скачать.

26 мая 2010 г.
Энтони Довгаль объявил, что PHP-FPM теперь упаковывается в магистраль ядра PHP. Прочтите здесь. Официальные инструкции по загрузке появятся в ближайшее время.

13 мая 2010 г.
Патч PHP-FPM выпущен для PHP 5.2.13. Скачать, Список изменений.

17 марта 2010 г.
Энтони Довгал сказал, что PHP-FPM ядра PHP не будет выпущен в PHP 5.3.3, но выглядит как PHP 5.4. Прочтите здесь. Обновление: до версии 5.3.3!

4 декабря 2009 г.
Энтони Довгаль объявляет, что PHP-FPM помещен в ветвь SVN в ядре PHP. Это захватывающее событие. Пройдет некоторое время, прежде чем он достигнет статуса производства, но это отличный шаг на будущее.

23 ноября 2009 г.
Я работаю над реструктуризацией вики и тому подобного.Пожалуйста, потерпите меня.

В настоящее время работает старая / устаревшая вики по адресу http://legacy.php-fpm.org/.

Вики, которые скоро будут обновлены, все еще работает, но ее содержание должно кардинально измениться. http://php-fpm.org/wiki/.

.

О компании — PHP-FPM

Почему PHP-FPM?

PHP-FPM не только выполняет настройку пулов FastCGI, но также расширяет некоторые внутренние компоненты FastCGI и увеличивает количество сообщений об ошибках, прерывании скриптов и т. Д.

В этой таблице представлено простое сравнение наиболее популярных методов управления пулами FastCGI.

История

Андрей Нигматулин является оригинальным автором PHP-FPM.С 2004 года он ждал, что кто-то другой сделает PHP FastCGI готовым к работе, но он не мог больше ждать. PHP-FPM — это продукт знаний, опыта и идей, полученных в результате работы с PHP FastCGI SAPI над несколькими проектами.

С тех пор он превратился в стабильное и простое решение досадной проблемы, которая не была решена должным образом. В середине 2009 года Андрей изменил формат PHP-FPM, сделав его более модульным и больше не патчем, который нужно было применять против PHP. Исходный код был разделен с одного большого патча на обычный набор файлов.Майкл Шейдл вызвался взять на себя руководство проектом и работать над его превращением в более надежное решение. Было несколько основных функций, которые Андрей так и не смог завершить, и мы надеемся вскоре решить их — самая важная из них — создание адаптивного процесса.

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

Недавно он был добавлен в ядро ​​PHP, благодаря Энтони Довгалу, при временной поддержке Dreamcat4 и продолжении работы со стороны Жерома Лойе.Первоначальное видение Андрея наконец начинает реализовываться.

Использование в реальных условиях

PHP-FPM обслуживает миллионы PHP-запросов без проблем для сотен веб-сайтов, и с каждым днем ​​их количество растет. В Open Source Bridge в Портленде Расмус упомянул, что теперь он использует nginx + PHP-FPM в wepay.com, компании, в которой он работает. Это не может быть более ратифицировано, чем это!

Лицензия

PHP-FPM доступен для публичного использования и под лицензией GPL. Модифицированная версия libevent, которая идет в комплекте с PHP-FPM, распространяется под лицензией BSD..

fpm (8) — справочная страница Linux

Имя

php-fpm — менеджер процессов PHP FastCGI ‘PHP-FPM’

Сводка

php-fpm [варианты]

Описание

PHP — широко используемый язык сценариев общего назначения, который особенно подходит для веб-разработки и может быть встроен в HTML. Это
вариант PHP, который будет работать в фоновом режиме как демон, прислушиваясь к запросам CGI. Вывод сохраняется в / var / log / php-fpm.журнал.

Большинство опций задаются в файле конфигурации. Файл конфигурации — /etc/php-fpm.conf. По умолчанию php-fpm будет отвечать на запросы CGI, прослушивающие
localhost http-порт 9000. Поэтому php-fpm ожидает, что ваш веб-сервер будет перенаправлять все запросы для файлов ‘.php’ на порт 9000, и вам следует отредактировать свой веб-сервер
файл конфигурации соответствующим образом.

Опции

-C

Не chdir в каталог скрипта

—php-ini путь | файл

-c путь | файл

Найдите php.ini в каталоге путь или использовать указанный файл

—no-php-ini

-н

Не будет использоваться файл php.ini

— определить foo [= бар ]

-d foo [= бар ]

Определите запись INI foo со значением bar

-э

Генерация расширенной информации для отладчика / профилировщика

— справка

-h

Эта помощь

—инфо

-i

Информация и конфигурация PHP

— модули

-м

Показать в модулях

— версия

-в

Номер версии — префикс путь

-п

Укажите альтернативный путь префикса (по умолчанию / usr)

—fpm-config файл

-лет

Укажите альтернативный путь к файлу конфигурации диспетчера процессов FastCGI (по умолчанию / etc / php-fpm.conf)

— тест

-т

Проверить файл конфигурации FPM и выйти При двойном вызове (-tt) конфигурация сбрасывается перед выходом.

— демонизировать

-D

Принудительный запуск в фоновом режиме и игнорирование параметра daemonize из файла конфигурации.

— без демонстрации

-F

Принудительно оставаться на переднем плане и игнорировать параметр daemonize из файла конфигурации.

—zend-extension файл

-z файл

Загрузить расширение Zend файл

Файлы

php-fpm.conf

Файл конфигурации для демона php-fpm.

php.ini

Стандартный файл конфигурации php.

Примеры

Для любых систем unix, которые используют init.d для их главного диспетчера процессов, вы должны использовать предоставленный сценарий инициализации для запуска и остановки демона php-fpm.

sudo /etc/init.d/php-fpm start

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

sudo systemctl start php-fpm.service

Если в вашей установке нет подходящего сценария инициализации, запустите php-fpm без аргументов. По умолчанию он запускается как демон (фоновый процесс).Файл
/var/run/php-fpm.pid определяет, запущен ли уже php-fpm. После запуска php-fpm отвечает на несколько сигналов POSIX:

SIGINT, SIGTERM

немедленное прекращение

SIGQUIT

плавный останов

СИГУСР1

повторно открыть файл журнала

SIGUSR2

плавная перезагрузка всех рабочих + перезагрузка fpm conf / binary

Подсказки

Демон CGI PHP-FPM будет хорошо работать с большинством популярных веб-серверов, включая Apache2, lighttpd и nginx.

См. Также

Веб-сайт PHP-FPM:
http://php-fpm.org

Более или менее полное описание PHP смотрите здесь:
http://www.php.net/manual/

Хорошее введение в PHP от Стига Баккена можно найти здесь:
http://www.zend.com/zend/art/intro.php

Ошибки

Вы можете просмотреть список известных ошибок или сообщить о любых обнаруженных вами новых ошибках по адресу:
http://bugs.php.net

Авторы

PHP-FPM SAPI был написан Андреем Нигматулиным.Списки рассылки: highload-php-en (английский) и highload-php-ru (русский).

Группа PHP: Тис К. Арнцен, Стиг Баккен, Энди Гутманс, Расмус Лердорф, Сэм Руби, Саша Шуман, Зеев Сураски, Джим Уинстед, Андрей Змиевский.

Список активных разработчиков можно найти здесь:
http://www.php.net/credits.php

И, наконец, что не менее важно, PHP был разработан с помощью огромного количества участников со всего мира.

Информация о версии

Эта страница руководства описывает php-fpm , версия 5.3.3.

Авторские права

Copyright © 1997-2009 The PHP Group
Copyright © 2007-2009, Андрей Нигматулин

Этот исходный файл является предметом лицензии PHP версии 3.01, которая входит в состав этого пакета в файле LICENSE и доступна через
в Интернете по следующему адресу:
http://www.php.net/license/3_01.txt

Если вы не получили копию лицензии PHP и не можете получить ее в Интернете, отправьте сообщение по адресу license @ php.net , поэтому мы
могу отправить вам копию немедленно.

.