Переменные окружения в PHP. Windows и Denwer
Переменные окружения, используемые в конфигурации, являются на сегодняшний день основным методом установки в приложении таких настроек, как учетные данные базы, API ключи, секретные ключи и всего, что является различным в зависимости от того, где развертывается приложение . Сейчас такие настройки попадают в код через окружение, вместо прямого прописывания в файлах конфигурации или, того хуже, хардкода прямо в коде.
Давайте подробнее взглянем на то:
- как это работает?
- действительно ли это хорошая идея?
- как с ними работать в PHP?
- и в заключение на некоторые рекомендации и распространенные ошибки, которых следует избегать - на те ловушки, на которые мы наткнулись в реальном мире!
Мы не будем рассматривать как настроить переменные окружения в вашем веб-сервере / Docker-е / crontab-ах... т. к. это зависит от системы, программного обеспечения, а мы хотим сосредоточиться на самих переменных окружения.
Если ваш хостинг использует Docker Swarm или AWS , все будет немного по-другому, например, т. к. они решили подсовывать файлы на файловую систему вашего контейнера, чтобы внедрить ваши секретные ключи, а не использовать переменные окружения. Это очень специфично для этих платформ и не является распространённым вариантом для всех.
Env vars 101
При запуске программы, она наследует все переменные окружения от своих родителей. Так что если вы установите переменную YOLO в значение covfefe в bash, а затем выполните команду, вы сможете прочитать YOLO в любом дочернем процессе.
$ YOLO=covfefe php -r "echo getenv("YOLO");" covfefe
Поскольку эта переменная определена только локально, мы не можем прочитать её из другого терминала (другого родителя). Идея в том, чтобы убедиться, что ваше приложение всегда наследует нужные переменные.
Вы можете посмотреть все переменные окружения в командной строке, выполнив следующую команду, но вы не увидите переменной YOLO , т. к. она была передана только в команду php "на лету", а не установлена в текущем процессе:
Вы можете установить переменную окружения с помощью export <имя>=<значение> :
$ export YOLO=covfefe
Имена переменных чувствительны к регистру и соглашение заключается в использовании имён только на английском, в верхнем регистре, с _ в качестве разделителя (т. н. "змеиный" стиль в верхнем регистре). Вы уже наверняка знаете некоторые переменные - такие как PATH , DISPLAY , HTTP_PROXY …
Лучшие практики на сегодня
josegonzalez/dotenv , ориентирована на безопасность:
Эта библиотека не заполнит суперглобальные переменные по умолчанию:
$Loader = new josegonzalez\Dotenv\Loader("path/to/.env"); // Парсим файл.env: $Loader->parse(); // Отправляем результат парсинга.env в переменную $_ENV: $Loader->toEnv();
Она поддерживает обязательные переменные, фильтрацию, и может выбрасывать исключения, когда переменная перезаписывается.
symfony/dotenv , новый малыш на этом поприще:
Доступен начиная с Symfony 3.3. Этот компонент заботится о.env -файле, как остальные, и тоже заполняет суперглобальные массивы:
$dotenv = new Symfony\Component\Dotenv\Dotenv(); $dotenv->load(__DIR__."/.env"); $dbUser = getenv("DB_USER"); $dbUser = $_ENV["DB_USER"]; $dbUser = $_SERVER["DB_USER"];
Вы не должны использовать её для получения ваших значений, поэтому я предлагаю вам вместо этого обращаться к $_SERVER - к тому же есть небольшая разница в производительности между обращением к массиву и вызовом функции в пользу массивов.
Переменные окружения - всегда строки
Одной из главных проблем является то, что сейчас в PHP есть указание типов, а наши настройки не всегда правильно набраны.
Class Db { public function connect(string hostname, int port) { } } // Это не будет работать: $db->connect($_SERVER["DATABASE_HOSTNAME"], $_SERVER["DATABASE_PORT"]);
В Symfony теперь можно преобразовывать variables , а даже больше - чтение файла, декодирование json...…
Переменные окружения везде или нет
На данный момент существует много споров между использованием переменных окружения, файлов, или их смеси: переменная окружения ссылается на файл конфигурации. Дело в том, что несмотря на то, что это считается лучшей практикой, переменные окружения не представляют больших преимуществ...
Но если правильно использовать, в приложении на Symfony, например, переменные окружения могут быть изменены "на лету" - без очистки какого-либо кеша, без обращения к файловой системе, без развертывания кода: просто перезапустив процесс, например.
Тенденция иметь только одну переменную, как APP_CONFIG_PATH , и читать её через "%env(json:file:APP_CONFIG_PATH)%" для меня выглядит как заново изобретать старый добрый parameters.yml , если файл не управляется автоматически с помощью надежного инструмента (как AWS Secret Store). И также есть envkey.com , который позволяет управлять вашими переменными окружения из одного места, не возясь с файлами самостоятельно, мне нравится такой подход, т. к. это гораздо проще!
Внимание! Статья написана под Windows 7, но принципиальных отличий в добавлении PHP в переменные среды в другие версии (Window XP, Windows Vista, Windows 8, ...) нет.
Информация! Все пути в настройках будут указаны исходя из того, что Denwer установлен в папку D:/web . При использовании данных из статьи не забудьте поменять этот путь на свой.
Для удобного использования PHP в консоле Windows необходимо настроить переменные среды. Иначе при работе с PHP через консоль вместо команды php Вам будет необходимо писать полный путь к файлу php.exe .
Предположим, что Denwer у нас установлен в папку D:/web .
Кликаем правой кнопкой мыши по иконке "Компьютер" Свойства:
Дополнительные параметры системы:
Вкладка "Дополнительно", кнопка "Параметры среды...":
Группа "Системные параметры", выделите переменную Path и нажмите кнопку изменить:
Добавьте строку D:\web\usr\local\php5; и нажмите кнопку "Ок":
Перезапустите Denwer. Теперь Вы можете открыть консоль (Win + R и введите cmd) и проверить работу PHP , введите команду:
Для исправления этих ошибок откройте файл D:/web/usr/local/php5/php.ini . Найдите переменные extension_dir , zend_extension , session.save_path и установите для них следующие значения.
Это короткий how-to для реализации конфигурации php-сервиса, зависимого от окружения, в котором он запущен. Я буду рад, если кто-то подскажет более изящное решение или поправит в мелочах.
Основная идея
Запускать сервис, микросервисы и зависимые приложения в рамках одной экосистемы, конфигурируемой с помощью переменных окружения .Проблема
В этой статье слишком много раз повторяется «переменные окружения».Из коробки php-fpm игнорирует глобальные переменные окружения (getenv function), в то время как php cli их может получать.
Предыстория
Этот раздел можно пропустить, если вы уже работали с.env
В данный момент я работаю над проектом, написанном на ZF2. Для конфигурации проекта использовались конфиг-файлы для разных окружений . Это порождает большое количество дубликатов конфигурации в репозитории проекта примерно такого вида:
- session.global.php
- session.local.php.dist
- session.unittest.php.dist
- db.global.php
- db.local.php.dist
- db.unittest.php.dist
Итак, проект теперь учитывает окружение, но...
Пока разработка велась на рабочих машинках, проект читал.env файл и всё работало. Но когда я развернул тестовую среду, оказалось, что если задать взаправдашние системные переменные окружения, php-fpm их игнорирует. Различные рецепты из гугла и StackOverflow сводились к той или иной автоматизации использования двух известных способов:1. Передача переменных через nginx параметром fastcgi_param SOMEENV test;
2. Установкой переменных в формате env в конфигурации пула рабочих процессов php-fpm .
И первый, и второй вариант, удобны для каких-то особых ситуаций. Но если мыслить в парадигме «конфигурировать среду, а не приложение», то подобные способы оказываются куда труднее, чем например просто положить.env файл в папку с проектом. Но ведь оркестратор, CI-система или просто системный администратор не должен знать детали реализации проекта, это не изящно.
Предлагаемый способ решения
Скомбинировав различные рецепты из сети, я нащупал следующее рабочее решение.Тестировалось под Centos 7, PHP 5.6.14.
1. Открыть /etc/php.ini - Заменить variables_order = "GPCS" на variables_order = "EGPCS" # После этого PHP добавит в глобальное пространство переменные окружения # http://php.net/manual/ru/ini.core.php#ini.variables-order 2. Открыть /etc/php-fpm.d/www.conf, не путать с /etc/php-fpm.conf (в разных системах может быть в разном месте, это конфиг www-пула процессов для php-fpm. - Добавить (или заменить, если вдруг есть): clear_env = no # выключить очистку глобальных переменных для запускаемых воркеров 3. Установить необходимые переменные окружения в /etc/environment (стандартный синтаксис A=B) 4. ln -fs /etc/environment /etc/sysconfig/php-fpm # теперь конфиг переменных окружения сервиса php-fpm будет просто ссылкой на глобальный конфиг 5. systemctl daemon-reload && service php-fpm restart
Этот же подход с симлинком, в теории, применим и к другим сервисам.
Плюсы предложенного решения:
- Переменные, хранящиеся в /etc/environment, доступны разным приложениям. Можно вызвать echo $MYSQL_HOST в shell или getenv("MYSQL_HOST") в php.
- Переменные окружения, которые явно не заданы в /etc/environment, не попадут в php-fpm. Это позволяет с помощью оркестратора контролировать окружение извне изолированной системы, в которой запущен сервис.
Минусы:
- К сожалению, у php-fpm я не нашел работающей команды для reload по аналогии с nginx, так что в случае изменения /etc/environment, обязательно нужно делать systemctl daemon-reload && service php-fpm restart
.
Важно : если ваше приложение работает не в изолированной среде (сервер, виртуалка, контейнер), определение переменных окружения может непредсказуемо повлиять на соседние сервисы в системе из-за совпадений имён в глобальном пространстве.
Когда браузер запрашивает от веб-сервера документ, он также пересылает на сервер техническую информацию об определённых параметрах браузера и операционной системы. Веб-сервер в свою очередь одновременно с документом возвращает некоторые свои характеристики. Таким образом, браузер и веб-сервер обмениваются данными, которые называются переменные окружения. Эти переменные можно применять в своих целях и отображать их на веб-странице.
При использовании SSI общий синтаксис вывода определенной переменной окружения будет следующий.
Некоторые переменные с их описанием перечислены в табл. 1. Заметьте, что все имена пишутся заглавными символами. Хотя это условие и необязательно, именно такая форма записи является традиционной и устоявшейся.
| Переменная | Описание |
|---|---|
| DOCUMENT_ROOT | Путь к корневой папке сайта. Для локального веб-сервера значение может принимать вид z:/home/сайт/www, а в других случаях зависит от операционной системы сервера и используемого программного обеспечения. |
| GATEWAY_INTERFACE | Версия CGI (Common Gateway Interface, общий шлюзовый интерфейс). Значение обычно равно CGI/1.1 . |
| HTTP_ACCEPT | Типы файлов, которые способен принять браузер. В качестве значения возвращается список поддерживаемых MIME-типов разделенных между собой запятой, например: text/html, application/xhtml+xml . |
| HTTP_CONNECTION | Тип соединения браузера с веб-сервером. Так, значение keep-alive означает, что браузер поддерживает постоянное соединение с сервером. При этом в течение одного сеанса соединения разрешено делать несколько запросов. Повторного соединения в таком случае уже не происходит. |
| HTTP_HOST | Доменное имя сайта. Обычно различают имена с префиксом www (www..ru). Переменная вернёт тот адрес сайта, который указан в адресной строке браузера. |
| HTTP_REFERER | Адрес страницы, с которой пользователь перешел на данный сайт, он еще называется реферер. |
| HTTP_USER_AGENT | Идентификатор используемого браузера и операционной системы. В качестве значения возвращается строка, содержащая ключевые слова. Например, следующая строка Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 говорит, что пользователь использует браузер Firefox 6.0.2 под операционной системой Windows 7. |
| QUERY_STRING | Запрос, который указан в адресной строке после вопросительного знака (?). Обычно пишется в форме «переменная=значение», где переменные разделяются между собой амперсандом (&).?id=5&slv=34 будет возвращено значение id=5&slv=34 . |
| REMOTE_ADDR | IP-адрес посетителя сайта. |
| REQUEST_METHOD | Метод отправки данных на сервер. По умолчанию применяется метод GET. |
| REQUEST_URI | Адрес запрашиваемого документа. Отсчёт ведётся от корня сайта, т.е..html вернется значение 1.html . |
| SERVER_ADDR | IP-адрес компьютера, на котором размещается сайт. |
| SERVER_ADMIN | Адрес электронной почты администратора сайта. |
| SERVER_NAME | Имя сервера. |
| SERVER_PORT | Порт, по которому ожидается получение данных. |
| SERVER_PROTOCOL | Протокол для получения и отправки данных. Значение обычно равно HTTP/1.1 . |
| SERVER_SOFTWARE | Программное обеспечение установленное на сервере. Для веб-сервера Apache возвращается номер версии (Apache/2.2.4 ), а также версия PHP (PHP/5.3.3 ). |
В примере 1 показано использование переменных окружения для отображения на веб-странице требуемой информации.
Пример 1. Вывод значения переменной DOCUMENT_ROOT
Путь к корневой папке сайта:
В результате выполнения примера будет выведена следующая строка: Путь к корневой папке сайта: /home/сайт/www .
Значения переменных окружения можно посмотреть с помощью программы на PHP, используя функцию phpinfo(), как показано в примере 2.
Пример 2. Использование phpinfo()
В результате выполнения программы будет выведена таблица с разными параметрами, в том числе и переменными окружения в разделе «Apache Environment» (рис. 1).
Рис. 1. Apache Environment
Также можно написать программу на PHP, которая будет выводить все переменные окружения в виде таблицы (пример 3)..
Пример 3. Вывод переменных окружения
\n\n
| $a | $b |
