Variabili d'ambiente o file di configurazione YAML

Question

Lo sfondo:
Fase 1 -> Abbiamo una scatola che corre test unitari e funzionali di un'applicazione mediante l'esecuzione in modalità di prova con una configurazione specifica.
Passaggio 2 -> Al termine del passaggio 1, eseguiamo i test di integrazione di un'applicazione eseguendola in modalità di test con un set di configurazione diverso, in un'altra casella.
Passo 3 -> Al termine del passaggio 2, eseguiamo i test delle prestazioni di un'applicazione eseguendola in modalità di produzione, nella casella del test delle prestazioni.
Passaggio 4 -> Al termine del passaggio 3, la build viene considerata stabile e la casella UAT viene aggiornata con quel codice base e l'applicazione viene eseguita in modalità di produzione, per la revisione e il feedback dei clienti. Passaggio 5 -> Con GO dal cliente, la casella di produzione viene aggiornata con il codice base.

Ora, dai passaggi precedenti osserviamo che nei passaggi 1 e 2, mentre l'applicazione viene eseguita in modalità test, ha una configurazione diversa. Simile è il caso con i passaggi 3,4 e 5.

In tali situazioni, qual è la pratica consigliata? Avevamo i file di configurazione YAML, ma personalmente sentivo che il mantenimento di numerosi file di configurazione non aveva senso. E così, ho cambiato dalla pratica di
"File di configurazione per l'ambiente"
a
"del file di configurazione per ogni modalità di rotaie, esternalizzando le variabili di ambiente Linux".

Sono sulla buona strada? La mia azione non semplifica le cose?

Quali sono i pro e i contro di questi due approcci?

Answer 1

Nella mia esperienza, le variabili di ambiente sono l'opzione di configurazione dell'ultimo resort.Hanno assolutamente il loro posto, ma le applicazioni dovrebbero in genere controllare prima altre opzioni di configurazione più affidabili ed esplicitamente intenzionali. Consiglio vivamente di caricare la configurazione da un file YAML e utilizzare solo una variabile di ambiente come fallback. Assumi sempre che la tua variabile d'ambiente si applicherà a tutto il sistema e supponi che, a un certo punto, si accidentalmente rimanga disinserita o impostata sul valore sbagliato. Ad esempio, la tua app non dovrebbe commettere seppuku perché la directory di configurazione è stata impostata su / e non dispone di autorizzazioni (o peggio si pulisce l'unità perché l'app viene eseguita come root). O più probabilmente, qualcosa come il tuo RAILS_ENV è stato impostato su test quando avrebbe dovuto essere production e nessuno ha realizzato e ora gli utenti stanno scrivendo i dati nel posto sbagliato o su /dev/null per tutti i 500.

Personalmente, mi piace rilasciare i messaggi logger.warn ogni volta che ritorno a una variabile di ambiente per un valore di configurazione.

Con il problema preciso, onestamente, probabilmente passerei il valore di configurazione per il quale ambiente deve essere avviato sulla riga di comando.

Answer 2

Nella mia azienda, in realtà abbiamo entrambi, in un certo senso.

Abbiamo un'app Rails che può indicare una delle numerose installazioni di un altro software e utilizzare l'API da tale installazione. Per specificare un'installazione, è necessario impostare circa 5 variabili.

Abbiamo avuto ognuna di queste variabili come variabili d'ambiente separate, ma impostandole tutte sono diventate molto veloci e ne abbiamo inevitabilmente dimenticato una.

Quindi ora abbiamo una variabile d'ambiente che chiamiamo ENV_TOKEN e abbiamo file yaml che contengono voci corrispondenti alle variabili ENV_TOKEN valide e codice in config/inizializzatori che imposta ENV [chiave] = valore.

Quindi diciamo che ho le variabili "FOO" e "BAR" che voglio impostare su "uno" e "due", rispettivamente. Potrei creare un file YAML che contiene:

carolclarinet: 
    FOO: one 
    BAR: two 

e quindi vorrei impostare il mio ambiente ENV_TOKEN variabile carolclarinet e FOO e BAR vengono impostati su uno e due.

Non ho idea se questo è il modo migliore per farlo, ma funziona per noi.

ETA: Nota che questo è solo per lo sviluppo e il test, l'installatore del nostro software si occupa di impostare tutto questo in modo che i nostri clienti non cambino mai alcuna variabile di ambiente.

Answer 3

Dopo un sacco di ricerche su google, discussioni con alcuni membri della rete e alcuni cervelli, ho apportato modifiche al codice in modo da avere "Un file di configurazione per modalità rails, esternalizzando le configurazioni dell'applicazione in un file yml, che nel mio caso rimane al di fuori dell'ambiente rotaie"

Maggiori dettagli si possono trovare nel mio post sul blog a http://bit.ly/hpChwl

Grazie a tutti per condividere i tuoi pensieri. Spero che la mia soluzione interessi tutti voi :)