Rails: Quale approccio usate per gestire le configurazioni di una applicazione?

Community IT
1

Mi riferisco a ad API KEY, mail server e altri valori che non
appartengono direttamente all’applicazione, ma che possono cambiare da
un’istanza a un’altra.

L’approccio che va per la maggiore è mettere tutto dentro gli
initializers, ma non mi sembra troppo furbo perché dovrebbe essere un
file che non viene tracciato in Git e viene caricato prima di tutti gli
initializers.
Inoltre sarebbe carino che una variabile es. item_per_page abbia un
default in file yaml, ma che sia anche sovrascrivibile (e quindi a
questo punto salvata in un db).

Qui ci sono alcuni spunti

e sicuramente ce ne saranno altri… ma qual’é il più furbo?

Ciao
Luigi

2

Noi abbiamo messo quelle info in un file tipo:
.nomeprogetto

che non versionato ma ognuno ha sulla propria macchina.
nei file di configurazione usiamo dei placeholders (es. $S3_API_KEY$)
con un bash script andiamo a sostituire i placeholders con i valori
corretti in fase di deploy.

La stessa tecnica la puoi implementare un po’ come ti pare, noi
l’abbiamo
fatto con bash tu lo puoi fare con il tool che preferisci.

Ciao,
A

2011/11/16 Luigi M. - grigio.org [email protected]

3

2011/11/16 Luigi M. - grigio.org [email protected]:

Mi riferisco a ad API KEY, mail server e altri valori che non
appartengono direttamente all’applicazione, ma che possono cambiare da
un’istanza a un’altra.

io di solito li metto in un file .yml in /config e lo faccio caricare
da un inizializer.
lo script di deploy, sul server di produzione/staging crea un symlink
alla directory
shared di capistrano, et voill.

m.

4

+1

anche io seguo questo approccio. in particolare, adotto un paio di
accorgimenti:

  • creo anche un nomeconfig_sample.yml da usare come template, e lo
    aggiungo in git
  • nell’initializer, genero un’eccezione se il file config/nomeconfig.yml
    non esiste

in questo modo, quando vado in produzione/staging, crearne uno e
linkarlo
questione di poco. faccio la stessa cosa anche con config/database.yml
:wink:

A.

Il 16/11/2011 14:29, Michele F. ha scritto:

5

Mi piace l’idea che un file yaml sia mappato a una costante che assumerà
valori diversi a seconda dell’ambie\nte test, dev o prod, per ora ho
testato questo sistema e sembra fare quello che volevo.

#initializers/00_load_conf.rb
raw_config = File.read("#{Rails.root}/config/app_config.yml")
config = YAML.load(raw_config)[Rails.env].symbolize_keys

def config.at(m)
self[m.to_sym]
end

def config.method_missing(m)
self.send :at, m
end

AppConfig = config

in view o console

AppConfig.twitter_key # => ghhjgty675765

6

se pu darti qualche spunto, il mio initializer questo:

config/initializers/app_config.rb

path = File.read(“#{Rails.root}/config/app_config.yml”)

APP_CONFIG = ActiveSupport::HashWithIndifferentAccess.new(
YAML.load(ERB.new(path).result)[Rails.env]
)

quindi lo uso con

APP_CONFIG[:twitter_key] # la chiave pu anche essere Symbol o String

altra cosa utile l’uso di ERB nel file yaml, che mi permette di fare
cose di
questo tipo:

products: <%= File.join(Rails.root,‘vendor/data/products.csv’) %>

ciao,
A.

Il 16/11/2011 17:20, Luigi M. - grigio.org ha scritto:

7

On Wed, Nov 16, 2011 at 5:20 PM, Luigi M. - grigio.org <
[email protected]> wrote:

Mi piace l’idea che un file yaml sia mappato a una costante che assumer
valori diversi a seconda dell’ambie\nte test, dev o prod, per ora ho
testato questo sistema e sembra fare quello che volevo.

Con rails 3 trovo comodo usare una gemma che fa questo:

poi, se nella configurazione ci sono elementi che non devono finire in
svn/git, come per database.yml evito di mettere il file production.yml e
lo
creo direttamente sui server (e se vuoi evitare di doverlo fare
‘manualmente’ per ogni server che installi puoi seguire i consigli di
weppos:

)

ciao,
Luca

8

@Luca, bella gemma! Per ora non ho bisogno di attributi annidati, ma se
dovessi aver bisogno di qualcosa di più serio la userei sicuramente.

Luigi

Luca M. wrote in post #1032253:

On Wed, Nov 16, 2011 at 5:20 PM, Luigi M. - grigio.org <
[email protected]> wrote:

Mi piace l’idea che un file yaml sia mappato a una costante che assumer
valori diversi a seconda dell’ambie\nte test, dev o prod, per ora ho
testato questo sistema e sembra fare quello che volevo.

Con rails 3 trovo comodo usare una gemma che fa questo:
GitHub - rubyconfig/config: Easiest way to add multi-environment yaml settings to Rails, Sinatra, Pandrino and other Ruby projects.

poi, se nella configurazione ci sono elementi che non devono finire in
svn/git, come per database.yml evito di mettere il file production.yml e
lo
creo direttamente sui server (e se vuoi evitare di doverlo fare
‘manualmente’ per ogni server che installi puoi seguire i consigli di
weppos:
Capistrano and database.yml — Simone Carletti
)

ciao,
Luca