К сожалению в предыдущем выпуске html-версия была опубликована без статьи, которая должна была там быть. В связи с этим я повторяю выпуск.
PHP FastCGI
Вступление
Данная заметка лишь для того, чтобы все стали обращать внимание на пакеты, которые есть в Сизифе (или обратили внимание на их необычные свойства). Итак, кажется я уже жаловался в Сизифе на притеснение cgi версии php и о том, что это вполне себе engine для рендеринга. К частью, скоро в Сизиф будет залит новый php с починенным fcgi и все станет намного лучше.
Итак, что мы будем делать. Мы будем делать web сервер без apache. Почему? Ну во-первых, он не всегда нужен, а во-вторых он плохо работает с fcgi приложениями (да да, все хаки в sapi/cgi именно для mod_fcgi ;) Кроме того, в Сизифе уже давно есть альтернатива - это nginx. Это просто радость для параноидальных и рукастых hostmaster'ов. Кроме того, оно умеет работать с FastCGI (например с php-cgi c поддержкой fastcgi) или как frontend proxy для медленного backend'а (например httpd-perl).
Поехали. Наша цель - nginx + php-cgi + imp (типа будем им читать почту вместо thunderbird ;)
Подготовка
Ждем нового php-cgi или исправляем существующий. Что нужно поправить в существующем:
1) заменить старые CFLAGS на новые вида export CFLAGS="%optflags -DPHP_FASTCGI -DDEBUG_FASTCGI"
2) добавить в configure параметры --enable-discard-path и --enable-force-cgi-redirect. Все это превратит php-cgi в полноценный FastCGI сервер, а не в жалкую перделку для apache.
3) Добавить в php.ini.cgi.alt строку cgi.fix_pathinfo=1. Для чего - см. 2)
Ставим nginx
Теперь самое веселое - нам нужно самостоятельно чем-то запускать собранный php-cgi. Для этих целей все рекомендуют использовать spawn-fcgi из пакета lighttpd, фиг с ним, будем использовать его. Но тут есть одна трабла - конечно, можно spawn'ить его руками (через .sh обвязку вида spawn-php.sh из того же lighttpd), но это некошерно. Поэтому я маленько подхачил spawn-fcgi, чтобы он умел делать pidfile. Патчик есть тут - http://lakostis.elektrostal.ru/patches/spawn-fcgi.c-pidfile.diff Далее уже дело техники,
и вот, у нас есть init.d запускалка fcgi приложений - http://lakostis.elektrostal.ru/src/spawn-fcgi и ее конфигурационный файл http://lakostis.elektrostal.ru/src/spawn-fcgi.sysconfig (кладется в /etc/sysconfig под именем spawn-fcgi).
Настройка
- Редактируем php.ini по-вкусу.
- Редактируем /etc/sysconfig/spawn-fcgi по-вкусу
- Создаем /var/run/spawn-fcgi && service spawn-fcgi start и смотрим, что php-cgi у нас теперь болтается в памяти
- Редактируем файл nginx.ini. У меня секция про FastCGI такого вида:
.....
location ~* ^.+\.php$ {
fastcgi_pass <fcgi host>:<fcgi port>;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/html/forum$fastcgi_script_name;
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 REMOTE_ADDR $remote_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param REDIRECT_STATUS 200;
# специально для php-cgi без этого PHP_SELF пустая
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
- Запускаем nginx, проверяем что FastCGI работает (например, через тествую страницу с phpinfo()
- Ставим imp, рисуем там ящики и работаем ;) Для него с nginx есть несколько хаков в конфиге:
Собвственно оно работает. Даже неплохо. Можно поставить phpa и даже немного ускорить процесс. Из замеченных неприятностей - теперь php лучше лишний раз не дергать (ибо слишком много запросов на порт залипает). workaround - использовать сокет, но это не совсем удобно. т.к придется тогда и nginx под пользвателем fcgi запускать, что несекурно. Зато теперь можно мониторить fcgi через monit или запускать его как все взрослые сервисы через rc.d
(C) Konstantin A. Lepikhov, lakostis at altlinux.org