Как настроить различные базы данных для каждой среды в Play 2.0?

Я бы хотел, чтобы мое приложение Play использовало разные базы данных для тестовых, локальных и производственных (производство Heroku) сред.

В application.conf у меня есть:

db.default.driver=org.postgresql.Driver 

%dev.db.default.url="jdbc:postgresql://localhost/foobar" 
%test.db.default.url="jdbc:postgresql://localhost/foobar-test" 
%prod.db.default.url=${DATABASE_URL}

Это не работает. Когда я запускаю play test или play run, все сбой доступа к БД происходит с:

 Configuration error [Missing configuration [db.default.url]] (Configuration.scala:258)

У меня есть несколько вопросов об этом:

В общем, я немного смущен тем, как настроены базы данных в Play: похоже, что есть простые db, db.[DBNAME] и db. [DBNAME].url, а различные учебники делают разные варианты среди те. Некоторые выражения, которые кажутся им, должны работать (например, db.default.url = "jdbc:..." сбой при ошибке, когда строка была предоставлена там, где ожидался объект).
Я видел, как другие люди предлагают создать отдельные файлы prod.conf, dev.conf и test.conf, каждая из которых включает application.conf, а затем содержит конфигурацию, специфичную для БД. Но в этом случае, как я могу указать, какую базу данных использовать при запуске test с консоли Play?
Предполагается, что синтаксис %env должен работать в Play 2?
Какой правильный способ указать среду для play test для использования?

Ответ 1

В Play 2 нет разных конфигурационных сред. Вместо этого вы просто устанавливаете или переопределяете параметры конфигурации в файле conf/application.conf. Один из способов сделать это - в командной строке play, например:

play -Ddb.default.driver=org.postgresql.Driver -Ddb.default.url=$DATABASE_URL ~run

Вы также можете сказать Play использовать другой файл конфигурации:

play -Dconfig.file=conf/prod.conf ~run

Пример файла Procfile для Heroku см.:
https://github.com/jamesward/play2bars/blob/scala-anorm/Procfile

Подробнее в Play Docs:
http://www.playframework.org/documentation/2.0/Configuration

Ответ 2

По крайней мере, в Play 2.1.1 возможно переопределение значений конфигурации с переменными среды, если они установлены. (Подробнее см. http://www.playframework.com/documentation/2.1.1/ProductionConfiguration)

Итак, вы можете установить следующее в conf/application.conf:

db.default.url="jdbc:mysql://localhost:3306/my-db-name"
db.default.url=${?DATABASE_URL_DB}

по умолчанию он будет использовать URL-адрес JDBC, если только переменная среды DATABASE_URL_DB не определяет значение для нее. Таким образом, вы просто устанавливаете свою базу данных разработки в конфигурации, а для производства или этапов вы определяете переменную среды.

Но будьте осторожны, эта подстановка НЕ РАБОТАЕТ, если вы поместите ссылку на переменную внутри строк с кавычками:

db.default.url="jdbc:${?DATABASE_URL_DB}"

Вместо этого просто выделите раздел, который нужно заменить, например.

database_host = "localhost"
database_host = ${?ENV_DATABASE_HOST}
db.default.url="jdbc:mysql://"${?database_host}":3306/my-db-name"

В этом примере localhost будет использоваться по умолчанию, если переменная среды ENV_DATABASE_HOST не установлена. (Подробнее см.: https://www.playframework.com/documentation/2.5.x/ConfigFile#substitutions)

Ответ 3

Фактически вы все равно можете использовать метод именования значений версии 1.0 версии 1.0 в Play 2, если вы загружаете значения конфигурации, проверьте, есть ли Play.isTest, а затем префикс свойств, которые вы загружаете с помощью "теста". Здесь отрезано:

def configPrefix = if (play.api.Play.isTest) "test." else ""

def configStr(path: String) =
  Play.configuration.getString(configPrefix + path) getOrElse
     die(s"Config value missing: $configPrefix$path")

new RelDb(
  server = configStr("pgsql.server"),
  port = configStr("pgsql.port"),
  database = configStr("pgsql.database"),
  user = ...,
  password = ...)

И связанный фрагмент конфигурации:

pgsql.server="192.168.0.123"
pgsql.port="5432"
pgsql.database="prod"
...

test.pgsql.server="192.168.0.123"
test.pgsql.port="5432"
test.pgsql.database="test"
...

Теперь вам не нужно запоминать настройки каких-либо системных свойств при запуске тестового набора e2e, и вы случайно не подключаетесь к базе данных prod.

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

Ответ 4

Существует другой подход, который заключается в переопределении метода Global/GlobalSettings onLoadConfig, и оттуда вы можете настроить конфигурацию приложения с общей конфигурацией и конкретной конфигурацией среды, как показано ниже...

conf/application.conf --> configurations common for all environment
conf/dev/application.conf --> configurations for development environment
conf/test/application.conf --> configurations for testing environment

conf/prod/application.conf --> configurations for production environment

Вы можете проверить http://bit.ly/1AiZvX5 для моей реализации образца.

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

Ответ 5

Вне темы, но если вы следуете за 12-факторным приложением, тогда наличие отдельных конфигураций, названных в честь сред, неэффективно:

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called "environments") named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle

источник: http://12factor.net/config