Непосредственно перед запуском сценария сервер передает ему некие переменные окружения с информацией. В определенных переменных содержатся некоторые заголовки, но, как уже говорилось, не все (получить все заголовки нельзя). Переменные окружения в языке PHP можно использовать как самые обыкновенные переменные. Переменные окружения делятся на четыре большие группы:
- Формируемые сервером переменные;
- Специальные переменные сервера Apache;
- Переменные HTTP-полей запроса;
- Переменные SSL-соединения (защищенного соединения).
Рассмотрим первые три группы переменных окружения:
Формируемые сервером переменные:
Переменная окружения |
|
| AUTH_TYPE | Используется схема аутентификации. Обычно "BASIC" |
| CONTENT_LENGTH | Длина содержимого, например, text/html |
| CONTENT_TYPE | MIME-тип содержимого, например, text/html |
| GETAWAY_INTERFACE | Версия CGI, например CGI/1.1 |
| PATH_INFO | HTTP-путь к сценарию |
| PATH_TRANSLATED | Полный путь к сценарию |
| REMOTE_ADDR | IP-адрес запрашиваемого компьютера-клиента |
| REMOTE_HOST | Доменное имя запрашивающего компьютера (если доступно). Доменное имя определяется web-сервером с помощью службы DNS. Директива HostNameLookups сервера Apache разрешает (или запрещает) преобразование IP-адреса в доменное имя. |
| REMOTE_PORT | Порт, закрепленный за браузером для получения ответа от сервера |
| REMOTE_USER | Имя пользователя, прошедшего аутентификацию |
| QUERY_STRING | Строка переданных серверу параметров |
| SERVER_ADDR | IP-адрес сервера |
| SERVER_NAME | Доменное имя сервера. Определяется директивой ServerName файла конфигурации |
| SERVER_PORT | TCP-порт Web-сервера. Обычно 80 |
| SERVER_PROTOCOL | Версия протокола HTTP. Например, HTTP/1.1 |
| SERVER_SOFTWARE | Программное обеспечение сервера |
| SCRIPT_NAME | HTTP-путь к сценарию |
| SCRIPT_FILENAME | Имя файла сценария в файловой системе сервера (физический путь). Например, /var/www/cgi-bin/script.cgi |
Специальные переменные сервера Apache:
Переменные HTTP-полей запроса:
Переменная окружения |
Описание переменной окружения |
| HTTP_HOST | Имя виртуального хоста, которому адресован запрос |
| HTTP_USER_AGENT | Программное обеспечение удаленного пользователя. Обычно данная переменная окружения содержит название и версию браузера |
| HTTP_ACCEPT | Список поддерживаемых клиентов типов содержимого. В последнее время вместо списка браузеры возвращают значение *.*, что означает "все типы" |
| HTTP_ACCEPT_LANGUAGE | Список поддерживаемых языков в порядке предпочтения, например, ru, en |
| HTTP_ACCEPT_ENCODING | Список поддерживаемых методов сжатия |
| HTTP_ACCEPT_CHARSET | Список поддерживаемых кодировок |
| HTTP_CONNECTION | Тип соединения. Возможны два варианта:
|
| HTTP_REFERER | Значение поля REFERER. В этом поле браузер передает URL ресурса, который ссылается на наш сервер. Например, если пользователь перешел на сайт со страницы http://www.somehost.com/page.php, то значение поля REFERER будет http://www.somehost.com/page.php. |
| HTTP_X_FORWARDED_FOR | Если пользователь работает через прокси-сервер, то в этом поле будет IP-адрес компьютера, обратившегося к прокси-серверу. Если данное поле уже содержит значение, то новое значение будет добавлено через запятую. |
Это короткий 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
.
Важно : если ваше приложение работает не в изолированной среде (сервер, виртуалка, контейнер), определение переменных окружения может непредсказуемо повлиять на соседние сервисы в системе из-за совпадений имён в глобальном пространстве.
Переменные
В РНР переменные начинаются со знака доллара ($ ). За этим знаком может следовать любое количество буквенно-цифровых символов и символов подчеркивания, но первый символ не может быть цифрой или подчеркиванием. Следует также помнить, что имена переменных в РНР чувствительны к регистру, в отличие от ключевых слов.
При объявлении переменных в РНР не требуется явно указывать тип переменной, при этом одна и та же переменная может иметь на протяжении программы разные типы.
Переменная инициализируется в момент присваивания ей значения и существует до тех пор, пока выполняется программа. Т.е., в случае web-страницы это означает, что до тех пор, пока не завершен запрос.
Внешние переменные
После того, как запрос клиента проанализирован веб-сервером и передан РНР машине, последняя устанавливает ряд переменных, которые содержат данные, относящиеся к запросу и доступны все время его выполнения. Сначала РНР берет переменные окружения Вашей системы и создает переменные с теми же именами и значениями в окружении сценария РНР для того чтобы сценариям, расположенным на сервере были доступны особенности системы клиента. Эти переменные помещаются в ассоциативный массив $HTTP_ENV_VARS (подробнее о массивах можно узнать в главе 4).
Естественно, что переменные массива $HTTP_ENV_VARS являются системно зависимыми (поскольку это фактически переменные окружения ). Посмотреть значения переменных окружения для Вашей машины Вы можете при помощи команды env (Unix) или set (Windows).
Затем РНР создает группу GET-переменных, которые создаются при анализе строки запроса. Строка запроса хранится в переменной $QUERY_STRING и представляет собой информацию, следующую за символом "? " в запрошенном URL. РНР разбивает строку запроса по символам & на отдельные элементы, а затем ищет в каждом из этих элементов знак "=". Если знак "=" найден, то создается переменная с именем из символов, стоящих слева от знака равенства. Рассмотрим следующую форму:
Если Вы в этой форме в строке HDD наберете, к примеру, "Maxtor", а в строке CDROM "Nec", то она сгенерирует следующую форму запроса:
http://localhost/PHP/test.php?HDD=Maxtor&CDROM=NecВ нашем случае РНР создаст следующие переменные: $HDD = "Maxtor" и $CDROM = "Nec".
Вы можете работать с этими переменными из Вашего скрипта (у нас – test.php) как с обычными переменными. В нашем случае они просто выводятся на экран:
echo ("HDD is $HDD
"); echo ("CDROM is $CDROM
"); ?>
Если запрос страницы выполняется при помощи метода POST, то появляется группа POST-переменных, которые интерпретируются также и помещаются в массив $HTTP_POST_VARS .
Переменные окружения, используемые в конфигурации, являются на сегодняшний день основным методом установки в приложении таких настроек, как учетные данные базы, 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 , который позволяет управлять вашими переменными окружения из одного места, не возясь с файлами самостоятельно, мне нравится такой подход, т. к. это гораздо проще!
Инструкции
