Symfony 4, файлы .env и производство

Файлы .env очень удобны с докером, kubernetes и т. д.

Но что, если у меня есть простой сервер nginx без какой-либо оркестровки, пакет рабочих процессов cron и пакет демонов (systemd/supervisord/etc)?
Я могу записать эти переменные env в раздел сервера nginx, но мне нужно настроить сотни переменных env для каждого рабочего процесса или демона cron.

Я нашел быстрое решение: использовать компонент symfony/dotenv в продакшене.
Но мне это кажется грязным. Кто может предложить лучшее решение?


nginx php symfony environment-variables symfony4
person Dmitry    schedule 09.03.2018    source источник
comment
Это очень хороший вопрос, так как не у всех есть доступ к конфигурации сервера, поэтому Symfony 4 довольно сложно развернуть, например, через FTP. Я вижу, что многие люди используют dotenv в продакшене прямо сейчас.   -  person Thomas Decaux    schedule 18.03.2018
comment
У меня есть доступ, но на сервере есть разные приложения (в пределах 1 пользователя), и я не могу использовать глобальную или пользовательскую среду. переменные.   -  person Dmitry    schedule 18.03.2018
comment
на самом деле в Symfony отсутствует кое-что, как в Docker: параметр --env-file! Вы можете экспортировать переменные env из файла, выполнив export $$(grep -v '^#' .env | xargs) перед выполнением консоли sf.   -  person Thomas Decaux    schedule 18.03.2018

Ответы (2)


arrow_upward
11
arrow_downward

Во-первых, не все переменные нужно указывать с помощью переменных окружения. Храните переменные, которые не отличаются для каждой системы, в отдельном файле yaml.

Если у вас есть только одна среда на сервер, вы можете указать переменные среды глобально в /etc/environment. (Может отличаться в зависимости от вашего варианта Linux)

Лично я считаю, что использование DotEnv создает больше трудностей, чем решений, когда вы запускаете несколько сред на одном сервере. Указание переменных в глобальной конфигурации, например /etc/environment, в этом случае не работает.

Задавать переменные окружения в nginx тоже не выход, так как, как вы упомянули, они не будут подхватываться cron, супервизором, консолью и т.д. Для меня это было причиной полного удаления DotEnv и работы с старый добрый parameters.yaml файл снова. Ничто не помешает вам это сделать.

Другое решение, однако, состоит в том, чтобы продолжать использовать DotEnv в вашей среде разработки и включать отдельный parameters.yaml в производство. Затем вы можете определить переменные среды следующим образом:

parameters:
  env(APP_ENV): prod
  env(APP_SECRET): 3d05afda019ed4e3faaf936e3ce393ba
  ...

Чтобы включить этот файл, поместите в файл services.yaml следующее:

imports:
    - { resource: parameters.yaml, ignore_errors: true }

Таким образом, импорт будет проигнорирован, если файл parameters.yaml не существует. Другое решение — добавить строку в configureContainer() в вашем классе ядра:

$loader->load($confDir.'/parameters'.self::CONFIG_EXTS, 'glob');
person Xatoo    schedule 09.03.2018
comment
Спасибо за ваш ответ. Да, мой список env содержит только переменные, которые отличаются на серверах. Также у нас есть 6 проектов (из одной системы) на каждом сервере, и у них будут разные учетные данные, поэтому мы не можем использовать /etc/environment. У нас есть тесты в докере, поэтому yaml-файлы для него неудобны. - person Dmitry; 09.03.2018
comment
С приведенным выше решением вам понадобится только файл parameters.yaml в производстве. Вы можете продолжать использовать .env в своей тестовой среде. - person Xatoo; 09.03.2018

arrow_upward
2
arrow_downward

если вы хотите централизовать переменные среды для cli и fpm, вы можете определить их один раз в своей системе. А затем укажите их все в своем php-fpm.conf:

....
[www]
env[APP_VAR1] = $APP_VAR1
env[APP_VAR2] = $APP_VAR2
...

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

Надеюсь это поможет.

person Webnet.fr    schedule 09.03.2018
comment
Вы говорите о веб-сервере, тогда как вопрос был о Linux CLI (например, CRON). - person Thomas Decaux; 18.03.2018