В рамках заметки разбираемся с сервером приложений Nginx Unit и запускаем на нём простой сайт на WordPress.
Готовое окружение.
Оговоримся сразу — допустим, у нас уже есть сервер на CentOS 7, где установлены Nginx, PHP 5.4 (и это печально, да) и MariaDB. Установка этого ПО описана в тысячах разных заметок в сети, а админы и вовсе имеют уже либо свои инструменты для сетапа такого стека, либо ставят его почти с закрытыми глазами. Так что, для данной заметки, будем считать, что сервисы у нас уже стоят.
Кроме того, на сервере создан пользователь wp, с домашней директорией /usr/share/nginx/html/wp и загруженной в неё CMS WordPress. В данный момент, при обращении к адресу http://159.69.11.239/wp/index.php браузер предлагает скачать файл. Попробуем сделать так, что бы PHP на сайте заработал с помощью Nginx Unit.
Установка Nginx Unit.
Для установки сервера приложений, добавим в систему соответствующий репозиторий:
# cat /etc/yum.repos.d/unit.repo [unit] name=unit repo baseurl=https://packages.nginx.org/unit/centos/$releasever/$basearch/ gpgcheck=1 enabled=1
Установим нужные нам пакеты:
# yum install unit unit-php
И убедимся что PHP для юнита установился и работает корректно. Для этого запустим сервис и загрузим в него пример конфига:
# service unit restart # service unit loadconfig /usr/share/doc/unit-php/examples/unit.config
Теперь «постучим» curl’ом на http://localhost:8300/ И если всё настроено верно, получим выхлоп phpinfo();
# curl http://localhost:8300/
Убедившись что всё в порядке, попробуем запустить наш сайт.
Настройка Nginx Unit.
Для запуска ресурса, в первую очередь, нам нужно создать конфигурационный файл, в котором, в json формате обязательно должны быть описаны две директивы — listeners и applications.
В рамках applications, мы описываем наше приложение — его название, язык на котором оно написано, директория, в которой оно работает, лимиты на количество его копий, пользователь и группу, от имени которого будет выполняться работа. Простейшее описание для wordpress будет таким:
"applications": { "index_php_script": { "type": "php", "processes": { "max": 20, "spare": 5 }, "user": "wp", "group": "wp", "root": "/usr/share/nginx/html/wp", "script": "index.php" }
В listeners мы описываем способ связи с нашим приложением. В нашем случае, конфиг будет выглядеть примерно так:
"listeners": { "127.0.0.1:8380": { "application": "index_php_script" }
Собираем конфиг в одно целое и получаем:
{ "listeners": { "127.0.0.1:8380": { "application": "index_php_script" }, "127.0.0.1:8381": { "application": "direct_php" } }, "applications": { "index_php_script": { "type": "php", "processes": { "max": 20, "spare": 5 }, "user": "wp", "group": "wp", "root": "/usr/share/nginx/html/wp", "script": "index.php" }, "direct_php": { "type": "php", "processes": { "max": 5, "spare": 0 }, "user": "wp", "group": "wp", "root": "/usr/share/nginx/html/wp", "index": "index.php" } } }
Сюда было добавлено ещё одно приложение direct_php и listener для него. Они так же будут использованы при подключении юнита в nginx далее.
Сохраняем полученный конфиг в файл /usr/share/nginx/unit/wp.conf, а затем, с помощью curl запроса отправляем конфигурацию в сокет юнита:
# curl -X PUT -d @/usr/share/nginx/unit/wp.conf --unix-socket /run/control.unit.sock http://localhost/config { "success": "Reconfiguration done." }
Убедимся, что конфигурация загружена. Для этого, выведем всю конфигурацию командой:
# curl --unix-socket /run/control.unit.sock http://localhost/config/applications/index_php_script
Либо конфигурацию конкретного приложения:
# curl --unix-socket /run/control.unit.sock http://localhost/config/applications/index_php_script { "type": "php", "processes": { "max": 20, "spare": 5 }, "user": "wp", "group": "wp", "root": "/usr/share/nginx/html/wp", "script": "index.php" }
Если мы захотим удалить конфигурацию, это можно сделать командой:
# curl -X DELETE --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/127.0.0.1:8380'
Нам остаётся подключить созданный unit в конфиге nginx и протестировать работу сайта.
Настраиваем Nginx.
Так как я делаю всё на тестовом сервере, я просто переименую дефолтный конфиг и буду работать с ним.
# mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.disabled
# cat /etc/nginx/conf.d/default.conf upstream index_php_upstream { server 127.0.0.1:8380; } upstream direct_php_upstream { server 127.0.0.1:8381; } server { listen 80; server_name localhost; root /usr/share/nginx/html/wp; location / { try_files $uri @index_php; } location @index_php { proxy_pass http://index_php_upstream; proxy_set_header Host $host; } location /wp-admin { index index.php; } location ~* \.php$ { try_files $uri =404; proxy_pass http://direct_php_upstream; proxy_set_header Host $host; } }
Два upstream, указывающие на запущенные нами юниты, и несколько базовых location, которые нужны для запуска WP сайта. Сохраняем конфиг, проверяем что ошибок не допустили и перезапускаем nginx:
# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
# systemctl restart nginx
В браузере переходим по адресу http://159.69.11.239/ и видим приглашение к установке CMS. Ставим, настраиваем и проверяем работу нашего тестового сайта. Если всё было сделано верно — постинг, добавление тем, плагинов, управление настройками сайта и т. п. должны работать без проблем.
Промежуточный итог.
Здорово, но остаюсь на PHP-FPM. Во всяком случае пока что. Причин тому несколько — в основном мне приходится работать с написанным на PHP, а для этого fpm на сегодняшний день, в сравнении с unit куда более гибкий инструмент. Кроме того, смущает невозможность использования PHP выше версии 5.4 на CentOS при установке ПО из пакетов.
Очень надеюсь что в будущем, по мере развития юнита, будут добавлены и новые возможности, и поддержка других версий PHP, а пока что, в проде у меня продолжает свою работу PHP-FPM.
Gpg check зачем отключать в конфиге репозиттрия?!
Справедливое замечание. Поправил.
Не хватает даты публикации статьи, чтобы понимать актуальность информации.
Согласен. Доработаю на обновлённой версии ресурса.
Отдельное приложение добавляется без проблем…
curl -X PUT -d @filename.json —unix-socket /var/run/control.unit.sock http://localhost/config/applications/name_application
да только вот слушатель порта (listeners) не добавляется-(
Пробовал отдельным файлом добавить новое Application и Listeners в конфигурацию — не получается. Как быть в таких случаях, кто знает?
Из описания не совсем понятно в чём проблема. Правильно ли я понимаю что хочется добавить новый порт в listeners? Я взял конфиг, в нём было указано два порта:
{
"listeners": {
"127.0.0.1:8382": {
"application": "index_php_script"
},
"127.0.0.1:8381": {
"application": "index_php_script"
}
},
Загрузил его:
curl -X PUT -d @unit.conf --unix-socket /run/control.unit.sock http://localhost/config
Проверил, оба порта появились:
netstat -nlp | grep 838
tcp 0 0 127.0.0.1:8381 0.0.0.0:* LISTEN 32713/unit: router
tcp 0 0 127.0.0.1:8382 0.0.0.0:* LISTEN 32713/unit: router
Затем, в этот же конфиг прописал ещё один listener:
{
"listeners": {
"127.0.0.1:8382": {
"application": "index_php_script"
},
"127.0.0.1:8385": {
"application": "index_php_script"
},
"127.0.0.1:8381": {
"application": "direct_php"
}
},
И загрузил его заново:
curl -X PUT -d @unit.conf --unix-socket /run/control.unit.sock http://localhost/config
Третий порт так же появился после этого:
netstat -nlp | grep 838
tcp 0 0 127.0.0.1:8381 0.0.0.0:* LISTEN 32713/unit: router
tcp 0 0 127.0.0.1:8382 0.0.0.0:* LISTEN 32713/unit: router
tcp 0 0 127.0.0.1:8385 0.0.0.0:* LISTEN 32713/unit: router
Т. е. ещё один listener добавился без проблем.
В remi-repo добавили пакеты unit-php для разных версий php 5.6, 7.0, 7.1, 7.2
Попробовал развернуть WP для теста на Nginx-Unit и Php-FPM под управлением VestaCP. Результаты примерно одиннаковы, только Nginx-unit имеет иногда больший тайминг по обработке запроса на главную страницу (его только и проверял)