Как работать в symfony env в продакшне?

Question

[galliard]

Собственно в симфони есть файл .env (как образец, под контролем версий) и всякие .env.local для конкретного окружения.

Но, как я понял, в продакшне он не должен быть задействован и переменные окружения должны прописываться в конфигах nginx или fpm. Однако переопределить конфигом nginx удалось только переменную APP_ENV, установив ее в значение "prod". Однако все мои кастомные переменные по прежнему читаются из файлов .env.

Что нужно сделать, чтобы эти переменные брались именно из настроек окружения, а не из файлов .env? Или оно так и должно быть и ничего выносить в конфиги nginx / fpm не нужно?

Comments

[sts]

Плохо понял о чем речь, но может тебя вот это интересует?
https://www.php.net/manual/en/ini.core.php#ini.var...

[galliard]

Станислав, нет, речь не об этом.

Answer 1

[Daria Motorina]

В самой документации написано, что нет преимущества проброса env через сервер по сравнению с .env файликом на проде

Most Symfony applications read their configuration from environment variables. While developing locally, you'll usually store these in .env and .env.local (for local overrides). On production, you have two options:

Create "real" environment variables. How you set environment variables, depends on your setup: they can be set at the command line, in your Nginx configuration, or via other methods provided by your hosting service.
Or, create a .env.local file just like your local development (see note below)
There is no significant advantage to either of the two options: use whatever is most natural in your hosting environment.

https://symfony.com/doc/current/deployment.html#b-...

Comments

[galliard]

Ок, это ответ на второй вопрос, но что с первым? Почему переменные, прописанные в .env имеют приоритет над реальными? И как это изменить?

[Daria Motorina]

galliard, даже не знаю, всегда .env и .env.local файлы переопределяли предыдущие env (env сервера), а не наоборот

[Daria Motorina]

galliard, добавлю - полистала код DotEnv пакета, так и есть https://github.com/symfony/dotenv/blob/master/Dote...

[Flying]

Daria Motorina, здесь дело не в модуле Dotenv как таковом, то что он переписывает $_ENV - это в принципе суть его работы :) Дело в том как это используется в Symfony framework. В 5.1, кстати, по-другому, но принцип тот же.

galliard, Ответ на вопрос "почему переменные, прописанные в .env имеют приоритет над реальными?" очень прост - потому что именно ради этого они и создавались, чтобы можно было прописать всё в локальных файлах и не завязываться на системные переменные окружения. Ответ на вопрос "как это изменить?" также очевиден - убрать код, отвечающий за запуск модуля Dotenv, ссылки на конкретные места см. выше в этом комментарии.

[Daria Motorina]

Flying, спасибо, не знала о таких деталях :)

[galliard]

Мне почему-то казалось, что его назначение - переписывать переменные окружения для разработки, а не вообще всегда. Но видимо я ошибался.

[BoShurik]

Flying, не использую DotEnv компонент, но откуда информация, что переменные в .env имеют приоритет над реальными? На сколько помню, разработчики везде всегда писали, что реальные переменные имеют приоритет. К примеру тут

[Flying]

BoShurik, признаю свою ошибку, спасибо за внимательность. Не увидел значения по-умолчанию у $overrideExistingVars

galliard, извиняюсь за то что ввёл в заблуждение.

[BoShurik]

Flying, и тут вылезает вопрос, как так получилось, что у galliard они перезаписываются...

[Flying]

BoShurik, да, хороший вопрос... я бы отладчиком посмотрел. Ещё один возможный (хотя и странный) вариант: возможно используется Dotenv с версией ниже 4.2 т.к. именно тогда было изменено поведение.

[BoShurik]

Flying, но там изначально они не перезаписывались, они просто добавили возможность перезаписывать

[Flying]

BoShurik, тогда видимо остаётся только отладчик... :)

Answer 2

[Flying]

Ответ на ваш вопрос есть в документации Symfony:

Начиная Symfony Flex 1.2 появилась команда composer dump-env prod которая создает обычный PHP файл из имеющихся у вас в .env файлах переменных, тем самым устраняя необходимость их разбора.

Сам загрузчик Symfony Framework поддерживает загрузку переменных окружения из этого PHP файла.

Comments

[galliard]

Flying и смысл менять шило на мыло? Вопрос был совсем не про это.

Answer 3

[Quber]

Подозреваю, что связано это с тем, что по-умолчанию php не видит системных переменных окружения. Необходимо изменить настройку в php.ini с
variables_order = "GPCS"
на
variables_order = "EGPCS"
Буква E как раз означает environments. После этого перезапустите php-fmp и php будет видеть переменные окружения. По-умолчанию, отдается приоритет переменной $_ENV, в которой хранятся переменные окружения. После включения настройки, переменные окружения будут у вас приоритетными.