Symfony 4 - Лучшие практики / переменные среды

Я использовал parameters.yml в течение многих лет, но теперь пришло время переключиться на Symfony 4 с переменными окружения :-)

У меня есть несколько вопросов о развертывании этого на моем сервере. Я использую Nginx + PHP-FPM. В документации сказано, что мы можем установить переменные среды в Сторона конфигурации Nginx. Некоторые другие блоги советуют устанавливать переменные среды на на стороне конфигурации пула PHP-FPM. А как же тогда консоль? Как bin/console узнает об этих переменных среды?

Цель состоит в том, чтобы централизовать настройки и иметь единую точку редактирования. Возможно, мы могли бы установить их на стороне ОС, но что, если я запускаю несколько приложений на одном сервере?

В моем случае у меня есть удаленный сервер (FreeBSD или Ubuntu 16.04 для другого приложения), предоставляющий производственную среду в /var/www/myapp/prod и предварительную версию (с ограниченным доступом в конфигурации nginx) в /var/www/myapp/qualif. Они имеют одни и те же ключи переменных среды, но разные значения (например, разные базы данных DSN). Я не использую докер.

Каковы ваши рекомендации?


person Ben    schedule 25.01.2018    source источник
comment
Что ж, это совершенно ясно описано в документах. Начиная с версии 3.3 был представлен новый компонент Dotenv, который будет хранить переменные среды в файле .env для использования в локальной среде.   -  person VisioN    schedule 25.01.2018
comment
Да, но в документации сказано, что Symfony Dotenv следует использовать только в средах разработки/тестирования/постановки. Для производственных сред используйте реальные переменные среды. symfony.com/doc/current/components/dotenv.html — возможно, в В моем случае безопаснее использовать компонент DotEnv в любом случае?   -  person Ben    schedule 25.01.2018
comment
Документация подсказывает правильно. Хранить в коде важные константы (например, пароли, ключи API и т. д.) — плохая практика. Вот почему вам нужно будет установить переменные среды, которые 1) легко настроить для разных сред с единой кодовой базой; 2) трудно украсть, если кто-то получит доступ к хранилищу кода.   -  person VisioN    schedule 25.01.2018
comment
Я видел этот вопрос раньше, но ответа пока нет. В настоящее время я просто принимаю накладные расходы на синтаксический анализ файла .env даже в производстве. Действительно кажется, что должна быть утилита fastcgi, которая будет считывать параметры из файла .env. Но я еще не нашел ни одного. Попробуйте задать вопрос на Slack сайте Symfony или, возможно, обратитесь к сообществу nginx.   -  person Cerad    schedule 25.01.2018
comment
Другое дело, что я не уверен, что вам вообще нужно добавить что-либо, кроме fastcgi_param APP_ENV prod; для производства. Похоже, что значения всех других переменных env в конечном итоге будут скомпилированы в производственный контейнер. Я еще не пробовал это, но, возможно, стоит попробовать.   -  person Cerad    schedule 25.01.2018
comment
Опять же, установка переменных среды в Nginx fastcgi_param предотвратит наследование ваших bin/console команд от них, поэтому я против этой практики. На самом деле я разбираю файл .env в производстве, который работает как для http, так и для cli, и я не понимаю, почему это плохая практика, поскольку файл .env все равно игнорируется .git. В моей настройке этот файл существует только в разных целях развертывания, а не в системе контроля версий.   -  person Ben    schedule 25.01.2018
comment
похоже, что без «копировать-вставить» на данный момент никак: serverfault.com/questions/844088/   -  person freshp    schedule 02.03.2018


Ответы (1)


Обычно я устанавливаю переменные конфигурации во время выполнения. Может быть в команде запуска docker с параметром -e или в файле docker-compose.yml.

Я бы запускал отдельные контейнеры для разных сред.

person Carlos    schedule 25.01.2018