Стратегии переопределения базы данных .yml?
В моей среде на серверах развертывания имеется большая часть информации о соединении, которая находится в базе данных .yml. То есть они знают, являются ли они серверами разработки, тестирования или производства, и они знают свою соответствующую информацию о подключении к базе данных.
Я могу инкапсулировать эту информацию в класс сервера, например, чтобы получить информацию:
Server["environment"] #=> production
Server["db_host"] #=> db5.example.com
Server["db_password"] #=> [a decrypted password]
и т.д. Я хотел бы развернуть приложение Rails и настроить его автоконфигурирование на основе настроек сервера. Каков наилучший способ сделать это?
Один из способов сделать это - Erb в моей базе данных .yml:
<%= Server["environment"] %>:
adapter: oracle_enhanced
host: <%= Server["db_host"] %>
username: db_user
password: <%= Server["password"] %>
Я не слишком взволнован делать это так, но это сработает. В этом случае, где я бы поставил 'server.rb', который определяет класс Server, - это нужно здесь в yml? app/initializers загружается после того, как ActiveRecord загружает database.yml.
Еще одно возможное решение - как-то переопределить инициализатор базы данных railties:
# File railties/lib/initializer.rb, line 903
def database_configuration
require 'erb'
YAML::load(ERB.new(IO.read(database_configuration_file)).result)
end
Вышеупомянутое вызывается только в том случае, если: active_record определен в config.frameworks. Я не уверен, как бы я решил переопределить это достаточно рано в последовательности запуска Rails.
Может быть, третий вариант - удалить: active_record из config.frameworks, а затем создать соединение позже, скажем, в инициализаторах приложения? Я боюсь, что это может иметь много непредвиденных побочных эффектов.
Я надеюсь, что там что-то простое и очевидное, чего я не нашел, например, функцию ActiveRecord, которая позволяет мне отказаться от database.yml и предоставлять альтернативный конфиг программным способом.
Ответы
Ответ 1
Вот два трюка, которые могут помочь здесь. Один из них - это то, что вы затронули, это попытка обезглавливать подпрограмму, загружаемую в конфигурацию базы данных, и, конечно же, что-то стоит изучить. Самое приятное в Ruby - вы можете в значительной степени исправить все, что вам не нравится, и заменить его чем-то лучше. Ответ здесь заключается в том, что более новая версия Rails может использовать другой механизм для настройки, и ваш патч приведет к разрыву. Возможно, это стоит того, чтобы заплатить.
Другой подход заключается в том, чтобы сохранить файл database.yml
на сервере вместо вашего репозитория и иметь какое-то развертывание script, которое связывает его с соответствующим местом. Преимущество такого подхода заключается в том, что в вашей системе контроля версий нет важных паролей, и вы можете обновить конфигурацию сервера без необходимости исправления приложения.
Ответ 2
Вы можете предоставить свои собственные настройки базы данных непосредственно в приложении application.rb:
Кажется, что это хорошие рельсы. 3.2. (Будьте осторожны, хотя, это своего рода перехват обезьян)
module MyApp
class Application < Rails::Application
# ... config
config.encoding = "utf-8"
def config.database_configuration
parsed = super
raise parsed.to_yaml # Replace this line to add custom connections to the hash from database.yml
end
end
end
Ответ 3
Это, похоже, работает в Rails 3.2.2
module MyApp
class Application < Rails::Application
self.paths['config/database'] = 'config/another_db.yml'
end
end
Ответ 4
Это старый вопрос, но в Rails 4 вы можете просто использовать переменную окружения и иметь пустой или отсутствующий database.yml(DATABASE_URL
будет переопределять любую базу данных .yml)
DATABASE_URL=postgres://myuser:[email protected]:5432/my-database-name
здесь: http://edgeguides.rubyonrails.org/configuring.html#connection-preference