non può caricare 'rails.application.database_configuration' metodo undefined '[]' per nil: NilClass

Question

Ho cambiato il mio database.yml per utilizzare il database sqlite3 in test e sviluppo e postgresql in produzione. La mia applicazione di funzionare con la produzione, ma quando lancio di prova o di sviluppo environements ho questo errore:

Cannot load 'Rails.application.database_configuration': 
undefined method'[]' for nil:NilClass (NoMethoError) 

mia database.yml:

# SQLite version 3.x 
# gem install sqlite3 
# 
# Ensure the SQLite 3 gem is defined in your Gemfile 
# gem 'sqlite3' 
# 
default: &default 
    adapter: sqlite3 
    pool: 5 
    timeout: 5000 

development: 
    <<: *default 
    database: db/development.sqlite3 

# Warning: The database defined as "test" will be erased and 
# re-generated from your development database when you run "rake". 
# Do not set this db to the same as development or production. 
test: 
    <<: *default 
    database: db/test.sqlite3 

production: 
    pool: 5 
    timeout: 5000 
    encoding: utf8 
    adapter: postgresql 
    host: <%= Rails.application.secrets[:database][:host]%> 
    database: <%= Rails.application.secrets[:database][:name]%> 
    username: <%= Rails.application.secrets[:database][:username]%> 
    password: <%= Rails.application.secrets[:database][:password]%> 

Answer 1

host: <%= Rails.application.secrets[:database][:host]%> 
database: <%= Rails.application.secrets[:database][:name]%> 
username: <%= Rails.application.secrets[:database][:username]%> 
password: <%= Rails.application.secrets[:database][:password]%> 

O Signore, non farlo. Non farlo per molte ragioni.

Usa ENV vars sul server di produzione, invece:

host: <%= ENV['DB_HOST'] %> 
database: <%= ENV['DB_NAME'] %> 
username: <%= ENV['DB_USER'] %> 
password: <%= ENV['DB_PASSEWORD'] %> 

poi si vuole andare sul vostro server prod e impostare quelle variabili nel file di configurazione della shell (.bashrc, .zshrc, .profile) come segue :

export DB_HOST=your_host 
export DB_NAME=your_name 
export DB_USER=your_user 
export DB_PASSWORD=your_password 

Il tuo problema è 1 di 2 cose possibili:

a. Una condizione di competizione in cui vengono caricate le configurazioni del database prima del file dei segreti.

b. Avete i vostri ambienti segmentati secrets.yml e non avete quei nodi per ambienti di sviluppo/test.

Answer 2

da parte circa la sicurezza

Se avete intenzione di seguire questa strada, che va bene, è necessario assicurarsi di una cosa molto importante:

Il file secrets.yml provisioning in modo sicuro , non controllato in controllo del codice sorgente, e non leggibili da chiunque che non dovrebbero avere accesso

In questo caso non è meno sicuro che avere un *key/*crt file del certificato bloccato-down fo r il tuo server web, tranne per il fatto che stai potenzialmente memorizzando più segreti. Fare questo correttamente è preferibile mettere segreti in ENV, ma ci sono ancora opzioni migliori.

Qualche ulteriore lettura:

• http://movingfast.io/articles/environment-variables-considered-harmful/
• http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/ (obvs ignorano roba Docker-specifico)

tuo problema reale

Il tuo problema è @ seconda idea di tagCincy ("b "), e stranamente, questo è super facile da risolvere. Fai solo ciò che ha suggerito @ Nik-Olai.Dichiarare (anche se vuota) valori degli stessi parametri nei vostri ambienti dev/test come questo:

development: 
    ... 
    database: 
    :name: 
    :username: 
    :password: 

test: 
    # same thing here 

La ragione è che, mentre la configurazione del database production non venga utilizzato in development o test ambienti, parsing di quella configurazione si verificherà ancora.

In un modo diverso, le impostazioni del database di produzione verranno ancora analizzate (e interpretate da ERB) anche in modalità test/dev.

Rails.application.secrets dipende dall'ambiente, quindi in modalità dev e test Rails.application.secrets[:database] non esisterà, il che significa che il successivo [] chiamata colpire un bersaglio nullo, e voilà!

Answer 3

Utilizzato con il nuovo Rails 5.1.0 aggiungendo le mie variabili con il nuovo file crittografato dei segreti.

Il tuo nil sta accadendo perché anche se è in via di sviluppo, tenta comunque di caricare tutto e tu stai chiamando le cose da zero -> qualcosa [: nil] [: cant_grab_from_nil]. La soluzione rapida è un'istruzione if. Suggeriscilo solo quando usi il file crittografato dei segreti nel nuovo Rails 5.1.

production: 
    pool: 5 
    timeout: 5000 
    encoding: utf8 
    adapter: postgresql 
    <% if Rails.application.secrets[:database].present? %> 
    host: <%= Rails.application.secrets[:database][:host]%> 
    database: <%= Rails.application.secrets[:database][:name]%> 
    username: <%= Rails.application.secrets[:database][:username]%> 
    password: <%= Rails.application.secrets[:database][:password]%> 
    <% end %>