Come devo memorizzare le mie variabili di ambiente?

Questa è una domanda molto ampia su metodi e consigli relativi alle variabili / struttura dell'ambiente. Ma alla fine cerco risposte per la domanda molto specifica di "Come devo memorizzare le variabili di ambiente?"

Innanzitutto alcuni chiarimenti:

• Un ambiente per me può essere da 3 a 10 server ed è un modo per contenere l'infrastruttura di un cliente specifico.
• All'interno di ogni ambiente ci sono alcune variabili che sono per lo più generate automaticamente da alcuni input chiave (nome, dimensione ecc.).

Allo stato attuale, stiamo memorizzando tutte le variabili di ambiente in una struttura del genere:

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

In questo momento la configurazione è inizializzata come sottomodulo nel repository git sopra. Poiché il file delle variabili cambia piuttosto frequentemente, ciò ha causato problemi con la modifica dei dati, una volta, due o addirittura tre volte tra i commit rendendo le modifiche sempre più difficili da rintracciare.

Dal momento che personalmente lo vedo in futuro, dovremmo cercare di memorizzare tutte le variabili dei nostri clienti in modo centralizzato / scalabile e quindi agganciarci con un inventario dinamico con ansible .

Capisco che ci sono alcune tecnologie che sembrano fare una parte di ciò che potrebbe essere richiesto come Console, ma sembrano funzionare meglio in un ambiente che serve una grande applicazione piuttosto che molte più piccole leggermente diverse.

Fondamentalmente vedo che dobbiamo scrivere uno script di inventario e poi semplicemente inserire tutti i nostri dati in un database costruito per scopi diversi e continuare quindi come se nulla fosse cambiato. Vedo questo concepibilmente come un modo per ridurre potenzialmente molti dei dati che archiviamo attualmente e forse esaminare diversi modi di archiviare i dati piuttosto che ridimensionare ciò che li serve di nuovo.

Spero che qualcuno abbia qualche tipo di esperienza nell'implementazione di infrastrutture come codice quando deve affrontare molti ambienti più piccoli rispetto a uno, due o tre enormi.

Eventuali suggerimenti?

Ho avuto due prove nel fare variabili d'ambiente in modo scalabile e nessuna delle due è stata perfetta perché, come ho scoperto, è una cosa molto complicata da ottenere. Di seguito fornirò un riepilogo di entrambe le mie esperienze:

Fattori comuni

• Le variabili di ambiente sono memorizzate in un repository separato dal codice sorgente originale (sono sottomodificate insieme ma sono ancora basate su repository separati)
• Esiste un processo "build" separato per l'artefatto e le sue variabili.
• C'è non è un processo di rilascio separato per le variabili di ambiente. Se si desidera modificare le variabili di ambiente, è necessario passare attraverso le stesse schede di revisione delle modifiche e al solito

Utilizzo delle coppie console KV

Le variabili di ambiente vengono caricate da un repository di artefatti (mai il repository git originale) e caricate in un albero di coppie KV con spazio dei nomi, ad esempio

/env/dev1/my/application/v1.1.1

Dove dev1 precedente è il nome dell'ambiente, my / application è lo spazio dei nomi dell'applicazione e v1.1.1 è la versione delle variabili di ambiente da utilizzare.

Per gli sviluppatori tutte queste cose sono invisibili. In fase di runtime la piattaforma verifica che l'ambiente esista nell'attuale cluster di console (se non c'è un problema ed è fuori errore), quindi controlla la sottostruttura per lo spazio dei nomi delle applicazioni (in questo modo non può esserci contaminazione incrociata in cui un'app fa riferimento ad altre app diverse) quindi il numero di versione della configurazione viene preso dall'etichetta connessa al manufatto distribuibile. L'aggiornamento di questa etichetta è la cosa chiave perché significa che se perdessimo entrambi i data center di produzione potremmo rialzare l'ambiente leggendo semplicemente i metadati dai nostri artefatti distribuibili e caricando tutte le variabili di ambiente nell'archivio KV.

Problemi con questo approccio Gli sviluppatori, e intendo ogni volta, hanno trovato il modo di inserire nell'ambiente le modifiche alla configurazione che avevano un impatto significativo sul modo in cui l'applicazione sarebbe stata eseguita. Perché è sempre stato più facile ottenere l'approvazione delle modifiche alla configurazione rispetto alle modifiche al codice.

Memorizzare un artefatto "Deployment" con variabili incorporate

Questo accoppia strettamente la versione esatta del manufatto con la versione di configurazione. Se hai modificato la configurazione, hai dovuto ricostruire questo artefatto di distribuzione.

Lo stesso artefatto di distribuzione era essenzialmente un file yaml che conteneva l'URL del file binario rilasciabile e tutta la configurazione ad esso collegata.

La piattaforma contiene componenti per leggere le variabili e quindi espanderle nella struttura dei processi dell'applicazione all'avvio.

Finora questo ha avuto molto più successo perché c'è un artefatto di cui possiamo tracciare la storia e di cui possiamo tenere testa a qualsiasi commissione di revisione e dire "questo è l'unico artefatto a cui teniamo, non abbiamo bisogno di guardare qualsiasi altra modifica, cambia solo questa cosa "(es. versione dell'applicazione da distribuire, variabili d'ambiente incluse ecc.

Questo rende un po 'più difficile per gli sviluppatori provare a costruire la logica nella loro applicazione che cambierà il suo comportamento in base alle variabili in modo da poter scivolare nelle modifiche senza passare attraverso cicli di test appropriati.

Punti bonus

Considera i segreti dell'applicazione. Finora la nostra soluzione è stata quella di fornire una chiave RSA pubblica che i team di sviluppo utilizzano per crittografare un archivio chiavi Java esteso (quasi ogni lingua ha una libreria da qualche parte in grado di leggere archivi chiavi Java) che viene quindi trattata come un terzo tipo di artefatto e viene trasferito sul server, decrittografato con la nostra chiave privata della piattaforma e fornito all'applicazione in fase di esecuzione.

La gestione dei segreti è certamente la sua lattina di worm. Ma probabilmente vale la pena considerare.

Se i tuoi ambienti sono per cliente, suggerirei nel tuo caso specifico di avere un repository per cliente . (In generale si tratta di un repository per ambiente.) Questo repository avrebbe una struttura di directory standard per variabili di ambiente, variabili e inventari rispondibili, segreti fortemente crittografati (token di accesso all'account, chiavi private, ecc.). Dovresti inserire il codice in questi repository. Probabilmente lo farei in più repository. Uno per ruoli e moduli rispondibili, uno per gli script di manutenzione e distribuzione, uno per ogni applicazione principale in esecuzione negli ambienti.

Ora puoi opzionalmente effettivamente forzare il codice o bloccare il sottomodulo in un tag specifico per il rilascio , assicurandoti che il codice che gestisce l'ambiente del cliente non cambierebbe se non testato e rilasciato.

Se si utilizza un repository di artefatti , accertarsi che gli artefatti siano correttamente aggiornati e che tali versioni siano specificate correttamente nelle variabili di ambiente.

L'automazione è importante perché le variabili di ambiente non dovrebbero essere aggiornate dagli esseri umani ove possibile, ma generate da script. Assicurati che non ci siano quasi aggiornamenti manuali nell'inventario per cliente e che gli sviluppatori aggiornino solo i repository di codice. Se vogliono apportare modifiche alla configurazione, dovrebbero essere eseguite su uno degli script di generazione, che viene quindi eseguito per generare le variabili e il diff viene inserito nel repository del cliente. Vale la pena di impostare l'integrazione continua per questo processo. Senza questo ad un certo punto ci saranno troppi repository da mantenere .