Какие конфигурации Apache / PHP вы знаете и насколько они хороши?

8

Я хотел спросить вас о методах настройки PHP / Apache, которые вы знаете, их плюсах и минусах. Я начну сам

---------------- PHP как модуль Apache ----------------

Плюсы : хорошая скорость, так как вам не нужно каждый раз запускать exe, особенно в режиме mpm-worker . В этом режиме вы также можете использовать различные ускорители PHP, такие как APC или eAccelerator.

Минусы : если вы запускаете apache в режиме mpm-worker, вы можете столкнуться с проблемами стабильности, потому что каждый сбой в любом php-скрипте приведет к нестабильности всего пула потоков этого процесса apache. Также в этом режиме все скрипты выполняются от имени пользователя apache. Это плохо для безопасности. Для конфигурации mpm-worker требуется PHP, скомпилированный в поточно-безопасном режиме. По крайней мере, репозитории CentOS и RedHat по умолчанию не имеют поточно-ориентированной версии PHP, поэтому в этих ОС вам необходимо самостоятельно скомпилировать хотя бы PHP (есть способ активировать рабочий mpm на Apache). Использование потоковых бинарных файлов PHP считается экспериментальным и нестабильным. Кроме того, многие расширения PHP не поддерживают многопоточный режим или не были хорошо протестированы в поточно-безопасном режиме.

---------------- PHP как CGI ----------------

Похоже, что это самая медленная конфигурация по умолчанию, которая сама по себе является "против";)

---------------- PHP как CGI через mod_suphp ----------------

Плюсы : suphp позволяет выполнять php scipts от имени владельца файла скрипта. Таким образом, вы можете безопасно разделять разные сайты на одном компьютере. Также suphp позволяет использовать разные файлы php.ini для каждого виртуального хоста.

Минусы : PHP в режиме CGI означает меньшую производительность. В этом режиме вы не можете использовать php-ускорители, такие как APC, потому что каждый раз, когда новый процесс создается для обработки скрипта, делает кэш предыдущего процесса бесполезным. Кстати, вы знаете способ применения ускорителя в этой конфигурации? Я слышал кое-что об использовании shm для кэширования байт-кода php. Кроме того, вы не можете настроить PHP через .htaccess файлы в этом режиме. Для этого вам нужно будет установить P ECL htscanner, если вам нужно установить различные параметры для каждого скрипта через .htaccess (директивы php_value / php_flag)

---------------- PHP как CGI через suexec ----------------

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

---------------- PHP как FastCGI ----------------

Плюсы : стандарт FastCGI позволяет одному php-процессу обрабатывать несколько сценариев до того, как php-процесс будет убит. Таким образом вы получаете производительность, так как нет необходимости ускорять новый процесс php для каждого скрипта. Вы также можете использовать PHP-ускорители в этой конфигурации (см. Раздел «Минусы» для комментариев). Кроме того, FCGI, почти как suphp, также позволяет выполнять процессы php от имени какого-либо пользователя. mod_fcgid, похоже, имеет наиболее полную поддержку fcgi и гибкость для apache.

Минусы : использование php-ускорителя в режиме fastcgi приведет к высокому потреблению памяти, поскольку каждый процесс PHP будет иметь свой собственный кэш байт-кода (если только не существует какого-либо ускорителя, который может использовать разделяемую память для кеширования байт-кода. Есть ли такой?). FastCGI также немного сложен в настройке. Вам необходимо создать различные файлы конфигурации и внести некоторые изменения в конфигурацию.

Кажется, что fastcgi - это самая стабильная, безопасная, быстрая и гибкая конфигурация PHP, однако ее немного сложно настроить. Но, может быть, я что-то пропустил?

Комментарии приветствуются!

Владислав Раструсный
источник

Ответы:

3

Запуск PHP через FastCGI, безусловно, даст вам наибольшую гибкость. Вы можете не только безопасно использовать Apache mpm-worker, но и вообще использовать другой веб-сервер (например, nginx).

Но даже в случае с Apache «PHP через FastCGI» на данный момент не один вариант, а как минимум два: mod_fastcgi, mod_fcgid. Кроме того, вы можете использовать динамические, статические или внешние процессы FastCGI; с или без suexec. Кроме того, есть встроенный в PHP менеджер процессов FastCGI, который теперь заменен очень хорошим PHP-FPM в PHP 5.3. Все эти варианты имеют разные плюсы и минусы и могут привести к различным проблемам.

Если бы у меня был выбор, я бы выбрал mod_fastcgi с PHP-FPM на данный момент, в основном потому, что он обеспечивает чрезвычайно универсальные и стабильные настройки.

граф
источник
1
> Я бы выбрал mod_fcgid с PHP-FPM. Это помешает вам использовать APC. Только mod_fastcgi позволяет использовать внешние серверы FCGI (это PHP-FPM). Если вы используете mod_fcgid, все преимущества, предоставляемые php-fpm, будут обнулены.
Владислав Раструсный
Это была, конечно, глупая опечатка. Извините за путаницу, я исправил это.
граф
2

Не совсем отвечаю на ваш вопрос, но я не понимаю, что FastCGI сложно настроить. Разница заключается в том, что другие методы, которые он должен заменить (mod_php, mod_python, ...), могут потребовать переписывания части кода. Это может быть трудной частью, но для настройки Apache, по крайней мере, я считаю, что это просто. В качестве примера я тестировал приложение WSGI на python и хотел посмотреть, как оно работает со всеми протоколами, которые поддерживает WSGI. Вот файл виртуального хоста с конфигурациями для всех протоколов (с mod_fastcgi):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host 127.0.0.1:3333
#SCGIMount / 127.0.0.1:3333
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py
</Directory>
</VirtualHost>

Это не кажется мне сложным. Конечно, FastCGI поддерживает множество опций, и его можно настроить до смерти, но это уже другой вопрос.

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

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
</Directory>
</VirtualHost>

И посмотрите эту ссылку для пользовательского php.ini, но вы должны быть в состоянии указать его с помощью -initial-envопции, т.е.

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/
Дэн Андреатта
источник
Да, добавить конфиг в apache просто. Но ваша конфигурация не позволяет выполнять скрипты от имени их владельца или хотя бы конкретного пользователя. Кроме того, пользовательский php.ini не может использоваться в вашем случае (я предпочитаю ограничивать open_basedir для каждого виртуального хоста только для его каталога)
Владислав Раструсный
Я не очень хорошо знаю PHP, но это те же проблемы, с которыми вы сталкиваетесь при работе с CGI. И вы можете легко запускать fastcgi как внешний сервер как любой пользователь, который вам нравится.
Дэн Андреатта
Добавил дополнительную информацию к ответу.
Дэн Андреатта
1

Хороший кандидат: Apache 2 ITK MPM

apache2-mpm-itk (просто сокращенно mpm-itk) - это MPM (Multi-Processing Module) для веб-сервера Apache. mpm-itk позволяет вам запускать каждый ваш vhost под отдельным uid и gid - короче говоря, скрипты и файлы конфигурации для одного vhost больше не должны быть доступны для чтения всем остальным vhosts.

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

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

rkthkr
источник
Да, но последний раз обновлялся годом ранее. И что еще более важно открывает потенциальное целое безопасности. «Поскольку mpm-itk должен быть в состоянии setuid (), он запускается от имени пользователя root (хотя по возможности ограничен возможностями POSIX), пока запрос не будет проанализирован и не определен vhost. Это означает, что любая дыра в безопасности перед анализом запроса будет корневая дыра в безопасности. (Наиболее вероятное место, вероятно, в mod_ssl.) "
Владислав Раструсный
Код работает, очень стабилен и, вероятно, нет причин его обновлять. Модуль получил активного разработчика Debian (не знаю о первоначальном разработчике). И это FOSS и не очень сложно.
rkthkr
0

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

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

Джастин Хиггинс
источник
Я просто спрашиваю о возможных вариантах. Не о выборе лучшего. Я сам выберу.
Владислав Раструсный