PHP настройки в production и development

Мы знаем, что на официальной странице https://hub.docker.com/_/php рекомендуется использовать php.ini для продакшена:

FROM php:8.2-fpm-alpine

# Use the default production configuration
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

И тут возникает сразу 2 вопроса:

1. почему php.ini сразу не готов к проду
2. почему сам php сразу не готов к проду

Ответ: из-за совместимости!

В самом исходном коде PHP (на языке C) значение по умолчанию часто оставляется пустым или минимальным. Это делается для того, чтобы PHP мог запуститься вообще без файла php.ini. В таком «голом» состоянии он должен вести себя максимально предсказуемо и просто, копируя логику старых версий (совместимость).

Кроме прод-файла, есть и дев-файл:

• php.ini-production (настроен на безопасность)
• php.ini-development (настроен на удобство отладки)

Фактически мы имеем три версии PHP:

1. php максимально совместимый со старым кодом
2. php рекомендуемый сообществом для development
3. php рекомендуемый сообществом для production

Давайте на примере параметра request_order

Голый (максимально совместимый со старым кодом) PHP имеет request_order = no value

Это означает, что PHP не заполняет массив $_REQUEST значениями из GET, POST или COOKIE на основе этого параметра. В этом случае PHP "откатывается" к поведению, заданному параметром variables_order, значит $_REQUEST будет просто копией того, что попало в массивы, разрешенные в variables_order (обычно это EGPCS). Но, это считается небезопасным, так как по умолчанию в $_REQUEST могут попасть Cookies, что открывает возможность для атак с подменой параметров. Поэтому, в php.ini файлах прописано request_order = "GP".

Так все же, почему не прописать "GP" прямо в код навсегда?

1. Принцип разделения интересов (Separation of Concerns): движок PHP отвечает за исполнение кода, а файлы .ini — за политику безопасности. Разработчики PHP Foundation считают, что исключение Cookies из $_REQUEST — это вопрос настройки безопасности, а не базовой логики работы языка.
2. Обратная совместимость: существует старый легаси-код, который до сих пор ожидает наличия Cookies в $_REQUEST. Если жестко зашить "GP" в код, такой код сломается при потере файла конфигурации. Оставляя no value, PHP дает администратору выбор.
3. Производительность: request_order — это дополнительный цикл обработки данных при каждом запросе. Если пользователю не нужен этот массив в специфических окружениях (например, микросервисы на CLI), он может оставить его пустым для микро-оптимизации.

Итог: no value — это "чистый лист" самого движка. GP — это стандарт индустрии и безопасности, который навязывается через конфигурационные файлы, поставляемые вместе с дистрибутивом.

Как указывать свои настройки

Известно, что в:

• /usr/local/etc/php/conf.d/ располагаются расширенные настройки php
• /usr/local/etc/php-fpm.d/ располагаются расширенные настройки php-fpm

Известно, что файлы в директориях подключаются в алфавитном порядке. Например сейчас в /usr/local/etc/php-fpm.d/ есть следующие файлы и порядок загрузки будет таким:

1. docker.conf
2. www.conf
3. zz-docker.conf

Следовательно, чтобы переопределить настройки указанные во всех файлах, нужно создать свой файл, например zzz-custom.conf