Dove devo mettere la mia configurazione dell'applicazione?

Recentemente ho letto un dibattito su " Dove dovrebbero essere archiviate le proprietà che dipendono dall'ambiente? ".

Il modo classico è disporre di più file di proprietà, uno per ambiente e in base a una variabile di ambiente (DEV, PROD ...), si sceglie dove leggerli all'avvio dell'applicazione (come con i profili Spring).

D'altra parte, se si utilizza un contenitore per distribuire l'applicazione, si dice che questo tipo di configurazione dovrebbe provenire dall'ambiente stesso (usando le variabili di ambiente che l'applicazione legge), quindi l'immagine non cambia tra gli ambienti.

Quali sono i pro e i contro di ogni approccio? Esiste un approccio "migliore" per lo scenario container?

Chi ha detto che i file delle proprietà e le variabili di ambiente si escludono a vicenda?

C'è una distinzione da fare tra "dove posso archiviare la configurazione della mia app?" E "da dove viene la mia app fonte la sua configurazione?"

Il risultato più probabile è che probabilmente tutti dovrebbero continuare a fare ciò che stanno facendo con i file di configurazione come meccanismo di archiviazione (si pensi a uno stato persistente a lungo termine finché esiste l'ambiente).

Tuttavia, anziché rilasciare quel file di configurazione nel contesto dell'applicazione e lasciarlo in esecuzione, l'applicazione dovrebbe essere in grado di aspettarsi che tali variabili siano già disponibili nell'ambiente all'avvio.

Ciò significa che è necessario disporre di due flussi di lavoro di distribuzione:

1. Distribuisco un'applicazione in un ambiente passando attraverso il processo di controllo delle modifiche X e facendo Y recensioni con lo strumento Z, qualunque cosa.
2. Distribuisco la mia configurazione di ambiente in un ambiente attraverso un processo di controllo delle modifiche e facendo revisioni B con lo strumento C, stesso processo, risultati diversi.

Per usare un esempio di gestione delle variabili d'ambiente come coppie chiave-valore in uno strumento come console, se stai memorizzando i file di configurazione in git, strumenti come git2consul con handle ottengono tale configurazione nell'ambiente quando viene aggiornato.

Se hai un'app che si aspetta che ci sia una configurazione disponibile come file di configurazione, puoi evitare di spedire più copie del file di configurazione con l'app creando un processo di distribuzione con qualcosa come console-template che ha la capacità di trasformare il tuo valori console in un file.

 Il modo in cui lo facciamo è che abbiamo 3 pezzi (o artefatti) per ogni applicazione in esecuzione.

1. L'applicazione che stiamo sviluppando. Questo è lo stesso indipendentemente dall'ambiente. Per abbinare il tuo esempio, questa sarà l'applicazione Spring come jar / war.
2. Il contenitore che eseguirà l'applicazione. Questo è lo stesso indipendentemente dall'ambiente. Se si utilizza Spring Boot, non è più necessario Tomcat e solo il runtime Java. Quindi usa il contenitore Docker openjdk.
3. La configurazione richiesta dall'applicazione. Questa è l'unica cosa diversa negli ambienti. In un'app Spring, probabilmente utilizzerai un file delle proprietà.

Il file di configurazione risiede in un controllo del codice sorgente separato. Questo era Git, ma ora stiamo usando un SaaS che abbiamo creato chiamato Config, su http://www.configapp.com . La caratteristica principale di Config è la facile gestione della configurazione specifica dell'ambiente. Per eseguire la nostra applicazione su un nuovo server, estraiamo il contenitore Docker, l'artefatto dell'applicazione e il file di configurazione per quell'ambiente. Nel contenitore, montiamo la directory in cui sono memorizzati l'applicazione e il file di configurazione, come parte dell'esecuzione del contenitore. La nostra applicazione è la stessa. Il nostro contenitore / immagine è lo stesso. Solo il file di configurazione è diverso.

Per quanto riguarda il file di configurazione e le variabili di ambiente. Per molto tempo abbiamo usato i file di configurazione. Quando abbiamo usato PaaS / cloud, abbiamo usato le variabili di ambiente. È stato un lavoro extra se hai molta configurazione, quindi abbiamo finito per usare le variabili di ambiente per determinare il file di configurazione corretto. Abbiamo un'applicazione che ha trasformato le proprietà in variabili d'ambiente, ma è atipico. Se disponiamo di un server di configurazione centralizzato sanzionato da un'azienda, lo utilizziamo, altrimenti ci piace la semplicità dei file di configurazione.

Quindi per riassumere, estraiamo app.jar, app.properties, openjdk Docker. Quindi eseguiamo openjdk Docker montando la posizione di app.jar e app.properties. L'unica cosa specifica per l'ambiente è app.properties. Per gestire facilmente app.properties, indipendentemente dal numero di chiavi di proprietà, ambienti, istanze di cluster / regioni, utilizziamo Config.