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

**URL:** <https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926>\
**Category:** IT\
**Created:** [November 16, 2011, 1:38pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926 "2011-11-16T13:38:44Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [November 16, 2011, 1:38pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/1 "2011-11-16T13:38:44Z")

</div>

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

> <https://stackoverflow.com/questions/4143638/accessing-config-from-application-rb-in-controller-rails-3>

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

Ciao  
Luigi

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 16, 2011, 2:20pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/2 "2011-11-16T14:20:15Z")

</div>

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](http://grigio.org) [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 16, 2011, 2:30pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/3 "2011-11-16T14:30:11Z")

</div>

2011/11/16 Luigi M. - [grigio.org](http://grigio.org) [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> 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.

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 16, 2011, 2:51pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/4 "2011-11-16T14:51:12Z")

</div>

+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  
😉

A.

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

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 16, 2011, 5:20pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/5 "2011-11-16T17:20:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 16, 2011, 5:34pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/6 "2011-11-16T17:34:12Z")

</div>

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](http://grigio.org) ha scritto:

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 17, 2011, 8:27am UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/7 "2011-11-17T08:27:54Z")

</div>

On Wed, Nov 16, 2011 at 5:20 PM, Luigi M. - [grigio.org](http://grigio.org) \<  
removed\_email\_address@domain.invalid\> 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...](https://github.com/rubyconfig/config)**
>
> Easiest way to add multi-environment yaml settings to Rails, Sinatra, Pandrino and other Ruby projects. - GitHub - rubyconfig/config: Easiest way to add multi-environment yaml settings to Rails, Si...

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](https://simonecarletti.com/blog/2009/06/capistrano-and-database-yml/)**
>
> How to create the database.yml file with Capistrano to prevent sensitive data to be stored in the application repository.

)

ciao,  
Luca

---

<div class="post-metadata">

**Author:** ![Luigi\_MaselliSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ebca7d/32.png) [@Luigi\_MaselliSS](https://www.ruby-forum.com/u/Luigi_MaselliSS)\
**Post date:** [November 17, 2011, 3:32pm UTC](https://www.ruby-forum.com/t/rails-quale-approccio-usate-per-gestire-le-configurazioni-di-una-applicazione/213926/8 "2011-11-17T15:32:22Z")

</div>

@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](http://grigio.org) \<  
> removed\_email\_address@domain.invalid\> 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.](https://github.com/railsjedi/rails_config)
> 
> 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](http://www.simonecarletti.com/blog/2009/06/capistrano-and-database-yml/)  
> )
> 
> ciao,  
> Luca