Использование встроенного сервера PHP в производстве

Мне недавно понравился встроенный веб-сервер PHP 5.4. На первый взгляд кажется, что, хотя и довольно barebones, при достаточной работе можно было бы распространять PHP-приложения, которые традиционно зависят от отдельного веб-сервера, такого как WordPress, как автономные скрипты, которые вы могли бы просто запустить с php -S localhost:80 app.php (или, более вероятно, './wordpress.sh' ). Они могут даже поставлять свой собственный PHP-интерпретатор, который обладает всеми функциями, необходимыми для приложения, что избавит вас от необходимости ориентировать различные версии языка.

Это немного изобретает колесо, но это, безусловно, увеличит переносимость и уменьшит сложность для конечного пользователя.

Однако на странице документации я увидел следующее:

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

Это, очевидно, касается таких проблем, как правильная безопасность файловой системы и обслуживание правильных заголовков HTTP, с которыми можно работать. Однако есть ли еще больше? Существуют ли неотъемлемые проблемы безопасности и / или технические ограничения при использовании встроенного веб-сервера PHP в рабочей среде, с которой невозможно работать? Если так, то кто они?

Solutions Collecting From Web of "Использование встроенного сервера PHP в производстве"

Я могу думать о множестве операционных вопросов, почему вы не хотели бы этого делать:

  • логирование
  • Перезапись
  • Дроссельный
  • Эффективность (не тестировалась, но я предполагаю, что Nginx намного быстрее, чем встроенный неоптимизированный сервер PHP)
  • Интеграция с чем-то еще, что у вас есть, которое расширяет Nginx, Apache и IIS (такие вещи, как New Relic)

Тем не менее, есть решение, в котором вы получаете большую часть преимуществ запуска PHP со встроенным веб-сервером, получая большую выгоду от запуска веб-сервера. То есть вы можете использовать такой сервер, как Nginx, как обратный прокси-сервер для встроенного веб-сервера PHP. В этой ситуации HTTP становится заменой FastCGI, аналогичной обычным обычаям встроенного HTTP-сервера в приложениях Node.js.

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

Встроенный в PHP сервер поддерживает только HTTP / 1.0, что означает, что клиентам необходимо создать новое TCP / IP-соединение для каждого запроса. Это очень медленно.

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

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

http://php.net/manual/en/features.commandline.webserver.php