Стратегии переопределения базы данных .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