Qual è il modo preferito per archiviare le configurazioni dell'applicazione?

Forse non c'è una buona risposta a questo. Sembra che sia necessario memorizzare questi dati in un luogo sicuro, in quanto sarà necessario per scopi di disaster recovery un giorno. Questo vale anche per i file di proprietà e gli script che impostano le variabili di ambiente.

• Il codice sorgente (in SVN / GIT ecc.) è una pessima idea, dato che questi dati conterranno password di database di produzione e simili.
• Il backup notturno aziendale può essere sufficiente, ma è improbabile che mantenga una cronologia dei cambiamenti facilmente accessibile.
• I dati devono essere sottoposti a una versione separata del software che consuma. Nel nostro sistema attuale, un cambiamento di configurazione porta a una nuova build dell'applicazione, e questo è semplicemente sbagliato.

Attualmente stiamo esaminando soluzioni a questo problema e ci stiamo orientando verso un repository di codice con accesso limitato. Questo repository conterrebbe solo i dati di cofigurazione. Gli altri hanno esperienze da condividere?

Nell'esaminare problemi e possibili soluzioni, mi aiuta a usare un metodo reso popolare da Jeff Atwood : If Dio avrebbe dovuto creare un modo per archiviare informazioni sensibili sulla configurazione, come avrebbe fatto?

Bene, saprebbe chi ha bisogno di informazioni di configurazione e lo darà a quelle persone, e le informazioni non potranno mai essere accessibili da nessun altro.

La prima parte dovrebbe già essere curata: il tuo sistema di controllo del codice sorgente dovrebbe autenticare gli utenti. E questo approccio è anche dato la validità secondo il # 10 in 10 comandamenti di Troy Hunt del controllo del codice sorgente , "le dipendenze devono essere nel controllo del codice sorgente".

Ma come tenerlo sicuro se è trapelato? Beh, non ha bisogno di essere memorizzato lì in testo normale! Usa crittografia. In .NET, ci sono i passaggi che puoi eseguire per crittografare i dati della stringa di connessione nei tuoi file di configurazione . Dovresti trovare i metodi equivalenti per farlo con la tua particolare tecnologia di scelta.

Molte persone criticano l'archiviazione della configurazione nei normali file insieme al codice sorgente ma, secondo la mia esperienza, questa è in realtà una soluzione piuttosto buona:

• Semplice da implementare in qualsiasi lingua. In molti, si ottiene il supporto per i file di configurazione complessi pronti per l'uso. Per esempio. nel caso di Java con Spring Boot, si ottiene il supporto YAML che può esprimere qualsiasi struttura ad albero, ed è facile avere file di configurazione separati per ambienti diversi così come una configurazione di base da cui i file specifici dell'ambiente possono ereditare.
• La configurazione è necessaria per eseguire il tuo software e le modifiche al codice spesso richiedono l'aggiunta o la modifica delle impostazioni di configurazione, quindi è naturale mantenere la configurazione e il codice insieme.
• Memorizzare la configurazione con la sorgente offre tutti i vantaggi del controllo del codice sorgente, come sapere chi ha modificato quale impostazione e quando o essere in grado di controllare le configurazioni durante una normale revisione del codice.
• A meno che tu non lavori per la CIA, l'argomento della sicurezza mi sembra esagerato. Pertanto, la password del database è memorizzata in un file sulla macchina su cui viene eseguita l'app. Bene, se qualcuno ottiene l'accesso alla macchina con la tua app, probabilmente sei già in un sacco di problemi - possono ad es. rimuovere la tua app e avviare la propria app al suo posto sulla stessa porta. In tale scenario, l'accesso alla password del DB potrebbe non essere un problema così grande. A meno che tutte le tue connessioni siano completamente criptate, avendo accesso alla tua macchina, possono comunque intercettare la maggior parte dei dati interessanti dalle interfacce di rete.
• Puoi utilizzare uno strumento come Hiera per avere un file di configurazione testuale ma non memorizzare password o altri dati sensibili al suo interno.

Quindi, per molti casi, la configurazione testuale memorizzata nel controllo sorgente insieme al codice è un buon inizio.

Se ci si trova in sistemi distribuiti o si desidera poter eseguire l'hot-swap della configurazione senza ridistribuire le applicazioni, è possibile trovare una soluzione basata su un server di configurazione. Spring Cloud ha supporto per tali meccanismi e le configurazioni di servizio back-end possono essere un repository git o Eureka . Puoi anche eseguire il rollover utilizzando ad es. Zookeeper . Ognuno di questi approcci semplifica la gestione di configurazioni coerenti su molti server per aggiornare le configurazioni senza dover ricostruire e ridistribuire il software. Ovviamente questo ha un costo, che sta imparando il server di configurazione e come usarlo dalle tue applicazioni e anche da un altro sistema da distribuire e mantenere.

Stiamo combattendo lo stesso problema su cui lavoro. Al momento tutte le nostre configurazioni sono basate su file e controllate da fonti con le singole applicazioni che le utilizzano. Questo porta alla duplicazione e agli sviluppatori che hanno accesso alle password di produzione / qa invece che allo sviluppo.

Detto questo, penso che abbiamo trovato una buona soluzione in futuro. Stiamo spostando i nostri file di configurazione su un repository git separato (etichettato come repo di configurazione). Quindi impostiamo un server spring-cloud-config (java) che serve semplicemente i file dal repository di configurazione in base ai profili passati ad esso. Questo è ottimo per le applicazioni Java che possono utilizzare il client e scaricarle all'avvio. Per le nostre app PHP / non-java verrà estratto direttamente il file. (Non ideale). In futuro potremmo scrivere qualcosa che permetta all'applicazione PHP di scaricare le configurazioni da solo e memorizzarle in cache da qualche parte, ma non è una priorità elevata per la prima esecuzione. Penso a questa soluzione come config-as-a-service che non viola esplicitamente le raccomandazioni delle app di 12 fattori.

Credo che lo zookeeper possa essere usato per la stessa cosa (ho visto un setup con kubernetes + zookeeper) quindi non sono del tutto sicuro del motivo per cui la risposta ha ottenuto un -1 sopra.

Link:

link

link

Penso che le tue opzioni siano in qualche modo definite dal sistema operativo che stai implementando in

Suggerirei di sì, inserire i valori nel controllo del codice sorgente. MA solo le versioni 'dev'. Vuoi che il tuo codice sorgente compili E lavori! non includere passaggi extra segreti

Il processo di compilazione e distribuzione dovrebbe quindi scambiare questi valori per ambiente durante la distribuzione. (il polpo ha questo tipo di modello)

Invece di archiviare l'intera configurazione in un unico file, memorizzalo in diversi file.

• Avere una directory di configurazione. Tutti i file sono interpretati come file di configurazione, tranne forse README* .
• Tutti i nomi dei file sono ordinati alfabeticamente e i file vengono caricati in questo ordine. Questo è il motivo per cui i file in questi casi iniziano spesso con una o due cifre: 01-logging.json . 02-database.json , ecc.
• I dati di tutti i file vengono caricati nella struttura di configurazione stessa disponibile per l'applicazione. Questo è il modo in cui diversi file possono integrare le impostazioni degli altri e persino sovrascriverli in modo prevedibile.
• Archivia solo nel VCS i file di configurazione con valori attendibili o valori predefiniti. Aggiungi i file di configurazione con i segreti durante la distribuzione o, meglio ancora, utilizza un servizio di memorizzazione dei segreti autenticato.

Nella casella Linux più vicina, dai un'occhiata a /etc/sudoers.d o /etc/nginx/conf.d . Mostra lo stesso modello.

La gestione dei segreti è una bestia diversa. Puoi gestirli come un passo manuale mentre sei piccolo. Puoi usare cose come Zookeeper. Puoi anche controllare i segreti in un VCS in forma crittografata e decrittografarli come fase di implementazione. Esistono numerose altre opzioni.

(Inoltre, un pezzo di opinione: JSON non è un buon formato di file di configurazione, perché non consente commenti, i commenti sono cruciali.TOML, YAML e persino i formati INI sono migliori nell'uso pratico.)

Apache zookeeper offre meravigliose opzioni per archiviare le configurazioni dell'applicazione per i sistemi distribuiti. Le modifiche apportate a Zookeeper possono essere catturate ed elaborate avendo un curatore o un ascoltatore di guardiani allo stesso fine dell'applicazione.