@topuserman

Конфигурация проекта: где и как лучше хранить?

Меня интересует как лучше хранить конфигурационные данные проекта.

Как мы это делаем сейчас:
- создаем в корне проекта файл config.php, где объявляем десятки констант для проекта.

В чем проблема такого подхода:
- В проекте бывают действительно константы, которые меняются очень редко, и объявлять их в таком виде - не вижу проблем.
- Но также бывают кучу других констант, которые могут меняться в зависимости от окружения.
Например в prod-среде используются одна сервисы, а в dev - другие (заглушки). Или параметры подключения в БД и прочие конфигурационные параметры.

Для такого типа параметров я решил использовать .env файл, и добавлять их туда.
Первое время вроде все было прекрасно, но столкнулся с двумя проблемами:
1. говорят, что использовать .env файл на продакшене - плохо, т.к. переменные окружения нужно там заводить нативно. Это не то, чтобы проблема, просто теперь нужно в двух местах добавлять новые переменные.
2. самое неприятное: некоторые переменные могут иметь различные скалярные типа. Например true/false, и при использовании .env файла - все является строкой. это достаточно неудобно для разработки.

Сейчас замечаю, что на других проектах некоторые коллеги используют ini-файлы, но чаще всего встречаю конфигурации в .yaml файлах.

Подскажите пожалуйста, где все-таки лучше хранить конфигурационные параметры, как зависимые от окружения, так и независимые, какие есть минусы и плюсы у них.
  • Вопрос задан
  • 790 просмотров
Пригласить эксперта
Ответы на вопрос 2
nokimaro
@nokimaro
Меня невозможно остановить, если я смогу начать.
Использовать .env - нормальный вариант
В репозитории как-правило ложится .env.example из которого каждый разработчик может сделать себе .env и настроить переменные окружения под свою среду разработки
И дальше в PHP конфигах используете тот же getenv()
Естественно часть переменных для конфигурации можно не выносить в .env если это какие-то константы, и оставить их просто в PHP

По поводу деплоя prod/dev то как-раз переменные окружения можно задать извне, если используется ci/cd и тот же docker.

Касательно кастинга типов: bool, null, empty string то легко можно написать свой хэлпер или подсмотреть у других
https://github.com/laravel/framework/blob/8.x/src/...
Ответ написан
Комментировать
ipatiev
@ipatiev Куратор тега PHP
Потомок старинного рода Ипатьевых-Колотитьевых
Самый простой, надёжный и удобный способ хранить настройки - это пхп файл.

Как правильно было выше замечено, многие форматы не поддерживают никакие типы кроме строк. Кроме того, любая иде сразу подхватит все настройки в автокомплит, без лишних плагинов и плясок с бубном.

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

return [
      'db' => [
          'host' => '127.0.0.1',
          'username' => '',
          'password' => '',
          'dbname' => '',
          'port' => 3306,
      ],
  ];


И в коде что-то вроде такого
if (!file_exists('config.php'))
  {
      throw new \Exception('Create config.php based on config.sample.php');
  }
  $config = require 'config.php';


Если говорить про .env, и не обращать внимание на вышеуказанные недостатки, то у него есть одно достоинство - множество способов задания переменных. В конфиге веб-сервера, в конфиге юзера, вручную, через файл, и.т.д.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы