Archivio parametri AWS vs variabili d'ambiente

In questo articolo esaminerò se e quando l'archivio parametri AWS dovrebbe essere utilizzato per sostituire le variabili di ambiente all'interno dell'infrastruttura AWS. Non vedrò cosa sono questi o come configurarli in modo approfondito, ma piuttosto un confronto tra i due.

Un caso per le variabili di ambiente

Facile da configurare

È abbastanza semplice ottenere l'installazione con le variabili di ambiente. Node, ad esempio, ha un modulo dotenv che può essere installato tramite npm con un singolo comando:

npm installa dotenv

Dobbiamo assicurarci che dotenv abbia un punto di ingresso da qualche parte nel nostro script, di solito tramite un'istruzione obbligatoria -

require ( 'dotenv'). config ()

Da qui, tutto ciò che dobbiamo fare è aggiungere le nostre variabili di ambiente a un file .env inserito nella cartella principale del progetto.

Puoi trovare maggiori informazioni sul modulo dotenv qui:

Va notato che il Parameter Store inizialmente non condivide gli stessi aspetti in termini di facilità di installazione - se non hai mai lavorato con il Parameter Store prima, il processo di configurazione può sembrare abbastanza laborioso con alcune cose da considerare:

  • È necessario accedere a un account AWS
  • Devi sapere come navigare nella dashboard di AWS, in particolare nella sezione SSM.
  • I parametri sensibili / sicuri devono essere crittografati con KMS, che di per sé richiede alcune impostazioni aggiuntive (https://aws.amazon.com/kms/)
  • A seconda delle esigenze, potrebbe essere necessario conoscere la configurazione di altri servizi AWS come l'ordine IAM e SSM per far funzionare correttamente l'archivio parametri.
  • Tutti i parametri sono ospitati sul cloud che richiedono l'accesso programmatico IAM, il che significa che è necessaria una connessione ininterrotta (va notato che è possibile creare configurazioni locali su misura con variabili locali che possono essere utilizzate al posto delle variabili dell'archivio parametri in base alla situazione— I incoraggerebbe in effetti questo tipo di approccio).

Facile da aggiornare durante lo sviluppo, l'implementazione e i test

Le variabili d'ambiente possono essere facilmente aggiornate tramite il file .env e il modulo dotenv sopra menzionati. Variazioni di questo file possono anche essere create e utilizzate per adattarsi a ciascun ambiente rilevante. L'importazione delle variabili di ambiente in uno scenario di test funziona più o meno allo stesso modo (importazione di variabili env dal relativo file dotenv).

Per la distribuzione su un server di gestione temporanea o di produzione, tutto ciò che dovremmo fare è utilizzare una versione alternativa del file .env. Questo può essere fatto facilmente ignorando il file .env esistente nel sistema di controllo della versione localmente (di solito git) e creando una nuova copia su ogni istanza dello stage / server.

Le variabili d'ambiente si integrano perfettamente anche con i sistemi di integrazione continua (CI). Circle CI, ad esempio, ha una sezione dedicata per la gestione delle variabili di ambiente in cui possono essere aggiunte a livello di build del progetto e aggiornate in un unico posto quando sono pronte per la distribuzione -

Dal punto di vista di Parameter Store, è indipendente dal linguaggio / framework, il che significa che tutte le impostazioni dovranno essere eseguite manualmente utilizzando un SDK AWS con accesso programmatico al servizio Parameter Store o in modo simile tramite un fornitore di terze parti (come un modulo npm) . Mentre AWS e i suoi servizi sono il punto di riferimento per gli standard di sicurezza nel dominio del cloud computing, i moduli personalizzati che potresti voler sviluppare o utilizzare potrebbero avere vulnerabilità di sicurezza a causa di malizia o svista, tenendo presente che esistono moduli accettati dal settore per questo gestito e approvato da entità affidabili come AWS stessi.

Dal punto di vista dell'implementazione / test, il Parameter Store presenta anche una serie unica di sfide, come se ci siano approcci suggeriti, come e quando si sceglie di interagire con il Parameter Store dipende interamente da te.

Le variabili di ambiente sono gratuite

Sebbene AWS Parameter Store non includa costi aggiuntivi (https://aws.amazon.com/systems-manager/pricing), la struttura dei prezzi di Amazon per servizi correlati come KMS (https://aws.amazon.com/kms/pricing ) inizierà a sostenere costi aggiuntivi in ​​base all'uso. D'altra parte, l'uso delle variabili di ambiente è gratuito.

Quindi perché sostituire le variabili d'ambiente? : un caso per l'archivio parametri

Fino a questo punto la soluzione variabile d'ambiente vaniglia sembra orlare il Parameter Store nella corsa per il dominio nell'arena variabile stage / secure. Mentre l'archivio parametri sembra creare più sfide di quante non risolva a questo punto, ci sono alcune cose, tuttavia, che l'archivio parametri fa indiscutibilmente meglio delle variabili di ambiente:

Le variabili dell'archivio parametri possono essere condivise tra più progetti

La migliore configurazione che ho trovato per la condivisione delle variabili di ambiente tra i progetti è quella di utilizzare un processo di distribuzione automatizzato che recupera le variabili di ambiente da un file contenuto in un'entità condivisa, come un bucket S3 che si collega alla configurazione del progetto in base alle esigenze (di solito eseguito tramite un script eseguito da un servizio CI). Dall'esperienza precedente, questa è l'opzione più semanticamente praticabile (per favore fatemi sapere se avete esperienza con eventuali opzioni migliori). Purtroppo questo è un esercizio noioso inizialmente e alla fine non è qualcosa che vorresti mantenere manualmente a lungo termine, principalmente perché eventuali errori o sviste lungo il percorso durante l'installazione o la manutenzione potrebbero causare problemi.

Tutto ciò che possiamo consegnare a un servizio AWS per automatizzare, dovremmo ed è qui che brilla l'archivio parametri. La condivisione delle chiavi KMS e delle variabili dell'archivio parametri tra i progetti è pronta all'uso.

Voglio fare un passo indietro e guardare AWS da una prospettiva olistica. Amazon ha fatto un ottimo lavoro nella gestione di ogni aspetto del cloud computing e ha una moltitudine di team di sviluppo dedicati a servizi specifici che tu e io non saremo mai in grado di replicare. Ciò significa in definitiva che, una volta acquisita l '"esperienza" di Amazon, dovresti avvalerti di tutti i servizi progettati per collaborare con il banner dell'infrastruttura cloud AWS. Sebbene abbia i suoi problemi (come tu e io ora siamo completamente bloccati in AWS come fornitore di servizi), alla fine è più facile scaricare tutto ciò che puoi su di loro, in quanto è una cosa in meno di cui devi preoccuparti, anche se costa un piccolo extra.

L'archivio parametri può utilizzare il controllo di accesso

Avere un controllo specifico sull'accesso degli utenti rende il servizio IAM uno dei più grandi attributi di AWS, specialmente quando si tratta di trattare informazioni potenzialmente sensibili come chiavi API o password. Il concetto di controllo dell'accesso alle variabili di ambiente nel senso vanigliato (ad es. Utilizzando l'approccio dotenv) non è un'opzione (a meno che non si sia disposti a sviluppare la propria soluzione su misura o a spostarsi al di fuori del regno delle "migliori pratiche").

I valori dell'archivio parametri sono facilmente aggiornabili

Per aggiornare qualsiasi valore nel vostro archivio parametri, è sufficiente un accesso appropriato alla dashboard AWS (o alla CLI), il che significa che anche i membri del team non tecnici possono aggiornare i valori con un po 'di esperienza nella dashboard AWS.

Sul lato delle variabili di ambiente dell'argomento l'aggiornamento delle variabili di ambiente diventa problematico in quanto di solito solo i membri del team qualificati che hanno accesso alle autorizzazioni di aggiornamento del server saranno in grado di accedervi e aggiornarle. Inoltre, questo apre il tuo progetto a un livello di vulnerabilità, in quanto l'accesso a un server e l'aggiornamento immediato dei file di progetto principali (anche su una configurazione automatizzata) possono causare problemi.

KMS può crittografare facilmente i valori dell'archivio parametri

Sebbene l'impostazione iniziale dei valori di crittografia nell'archivio parametri possa sembrare un po 'scoraggiante, una volta che ci si abitua, è abbastanza semplice e ha molto senso, anche da una prospettiva non tecnica. Questo è anche un grande livello di sicurezza che viene aggiunto, pronto all'uso.

È possibile utilizzare la crittografia per le variabili di ambiente che non si desidera memorizzare in testo normale, ma può essere difficile da configurare e gestire manualmente.

Le variabili dell'archivio parametri possono essere organizzate

I parametri di produzione e gestione temporanea vengono gestiti in un'unica posizione quando si utilizza l'archivio parametri, che include i parametri di ordinamento e filtro e persino l'aggiunta di descrizioni per chiarire il loro scopo.

Dal punto di vista delle variabili d'ambiente, non si ottiene un'organizzazione variabile pronta all'uso. Avere alcune variabili d'ambiente potrebbe essere abbastanza facile da gestire, ma questo diventa problematico quando ci sono troppe variabili da gestire manualmente. Potrebbe essere possibile organizzare le variabili di ambiente in diversi file e cartelle, ma in realtà non esiste una soluzione pronta all'uso per questo che non sembra complicare inutilmente le cose.

In definitiva, la decisione su quale delle due soluzioni da utilizzare dovrebbe essere determinata dalla complessità e dalla portata del progetto, tenendo conto dei fattori sopra menzionati.

Conclusione

Ci sono altri fattori da prendere in considerazione quando si sceglie se utilizzare il Parameter Store o le variabili di ambiente per gestire i propri parametri stage / sicuri, ma speriamo che in questo articolo abbiamo trattato di quelli importanti.

Se hai altri fattori che ritieni siano degni di considerazione, vorrei sentire i tuoi pensieri.