Scalabilità dell'utilizzo di variabili d'ambiente

5

Mi sono appena trasferito nel mondo di Ruby on Rails e con ciò sono stato introdotto a un uso molto più liberale delle variabili di ambiente rispetto a quello a cui sono stato esposto in passato. In particolare, sembra che ci sia una convenzione accettata per memorizzare chiavi API e token segreti di terze parti come variabili di ambiente.

NOTA: questa non è una domanda specifica per la RoR. Lo menziono solo per illustrare un punto di vista.

Certamente vedo il beneficio di questo approccio; il più grande dei quali è che una base di codice può essere distribuita in modo identico su più server senza modificare il codice o temere che l'app userà la risorsa sbagliata. Tuttavia, sono diffidente nel saltare sul carro del gruppo.

Innanzitutto, l'approccio non sembra scalabile sulla mia postazione di lavoro di sviluppo (laptop) o sui server. Se sto lavorando su 10 siti Web diversi e ognuno utilizza Amazon S3 (ad esempio), ho bisogno di 10 EV diversi. La gestione sarà difficile:

  • le collisioni di nomi sono una possibilità distinta (specialmente se sto lavorando su progetti legacy di cui non ho il controllo completo);
  • la visibilità è torbida (quali veicoli elettrici esistono sul computer di destinazione? che sono stati o possono essere dismessi?);
  • nessun controllo di versione (chi ha cambiato l'EV? quando? perché?)

In secondo luogo, uno dei principali punti di vendita, a quanto ho capito, è che l'uso di EV elimina i dati sensibili dal deposito in cui gli occhi indiscreti possono vederli. Sembra solo che dovrebbe essere un problema per i repository pubblici, che non ne ho. Tutti i miei repository sono privati, spesso a causa di problemi contrattuali come NDA o diritti di proprietà.

Come si svolge tutto questo in scenari di vita reale? Questo approccio è migliore per alcune situazioni rispetto ad altri? Ci sono altri professionisti che superano le mie preoccupazioni qui?

    
posta Jeff 05.10.2013 - 18:49
fonte

2 risposte

3

Le variabili di ambiente sono un insieme di coppie chiave / valore per configurare ... l'ambiente (ovvero le cose che riguardano direttamente il sistema operativo, come ad esempio i percorsi di cartelle condivise, ad esempio).

Come strumento di configurazione dell'applicazione, non sono mai stato un grande fan delle variabili di ambiente o delle impostazioni del registro, preferendo i file di configurazione per tutti gli stessi motivi che hai già affermato.

I file di configurazione ti danno:

  1. Controllo completo del formato utilizzato per memorizzare le impostazioni
  2. La capacità di memorizzare oggetti, con l'aiuto della serializzazione
  3. La capacità di memorizzare strutture complesse come alberi, ecc.
risposta data 05.10.2013 - 19:32
fonte
2

Le variabili di ambiente dovrebbero essere memorizzate nel controllo di versione e gestite con un sistema stesso. burattino, cuoco, ecc. sono tutti progettati per gestire questo ed eviteranno molti dei problemi che hai menzionato.

    
risposta data 05.10.2013 - 19:46
fonte