metodi per la gestione dei file di configurazione tra più ambienti

Question

Problema

Usiamo file WAR java e mantenere i file di configurazione in secchi s3. I nostri ambienti: DEV, QA, Stage e PROD hanno ciascuno i propri file di configurazione e bucket s3. Se aggiungo un nuovo campo, come "Polling_RATE = 5000", , deve essere aggiunto manualmente a ogni env perché questi file di configurazione memorizzano anche le password in modo che non possano essere legate all'applicazione o mantenute all'interno di Github. Non tutti gli ingegneri hanno accesso a ogni ambiente, quindi è necessario ricordare di informare gli ingegneri di livello superiore (DEVOPS) prima della data di implementazione del pungolo per aggiungere il nuovo campo per far funzionare l'applicazione. È un processo davvero complicato al momento.

Domanda

C'è un programma di utilità o un modello di progettazione architettonica destinata a far fronte a questo? Come fai a "controllare la versione" i campi sensibili di configurazione che non puoi memorizzare all'interno di github?

Answer 1

Problema riconoscibile.

In genere i campi di configurazione con informazioni sensibili come le password cambiano molto meno spesso dei campi di configurazione non sensibili. Una possibile soluzione è dividere la configurazione in due parti:

1. Config che è specifico dell'ambiente ma non contiene informazioni sensibili. Ti consiglio di conservare questi file insieme al tuo codice sorgente e, se possibile, di generare i file e di caricarli automaticamente nel tuo archivio di configurazione (S3 nel tuo caso) al momento della compilazione. Devono essere versionati e legati alla versione dell'applicazione.
2. Config che contiene informazioni riservate. Osservando la domanda, non tutti i membri del team possono leggere/scrivere queste informazioni. È possibile memorizzarli in S3 con diritti di accesso specifici in modo che solo i membri autorizzati possano accedervi. Avresti bisogno di un meccanismo per unire i file di nuovo insieme alla distribuzione, o cambiare l'app per leggere da diversi file di configurazione.
   Tuttavia, questo risolverà solo parte del tuo problema. I ragazzi delle operazioni dovranno comunque eseguire le modifiche quando cambiano le chiavi di configurazione sensibili. Se questo è accettabile dipende da quanto spesso cambiano le chiavi di configurazione sensibili.

Un'alternativa a S3 potrebbe essere quella di eseguire un repository Git privato (ad esempio, l'AWS CodecCommit). Avresti un controllo della versione migliore e un accesso più semplice per gli sviluppatori per eseguire le modifiche, dal momento che stai già utilizzando Git. Dovrai comunque correggere i diritti di accesso diviso tra dev e ops, o lasciar perdere (dato che DevOps riguarda la fiducia e la cooperazione, potrebbe essere una buona idea). È possibile applicare un modello simile qui come ho descritto sopra.

Un'altra soluzione potrebbe essere quella di spostare la configurazione dei valori sensibili dai file di proprietà alla configurazione di sistema. Quando usi già un sistema di provisioning come Puppet o Chef, questo sarà naturale per i ragazzi ops. Oppure imposta tutti i valori sensibili come le password come variabili di ambiente e chiedi all'app di leggerla come proprietà di sistema.

Spero che questo aiuti!

Answer 2

Abbiamo utilizzato dynamodb per mantenere i valori di configurazione. Il vantaggio di questo approccio è che i valori sono facilmente leggibili dalla console e convalidati. Un altro vantaggio è che controlliamo periodicamente i valori da dynamodb, quindi se qualsiasi valore deve essere cambiato, lo cambiamo e l'app sceglie automaticamente il nuovo valore anziché ricominciare. I valori sensibili vengono archiviati crittografati utilizzando le chiavi KMS e solo il ruolo ec2 che sta eseguendo l'applicazione ha diritto di decrittografare utilizzando tale chiave. Abbiamo migliorato il progetto Archiaus di Netflix in base alle nostre esigenze. Potrebbe essere tu puoi verificarlo.