Best practice per la gestione di un gran numero di file di configurazione / proprietà strutturati

Immagina un sistema che ha un gran numero di server. Ognuno di loro ha una serie di impostazioni:

• Alcuni specifici per il server
• Alcuni specifici per la regione
• Alcuni comuni a tutti loro
• Forse puoi avere alcuni raggruppamenti personalizzati, come questo gruppo di server è di sola lettura
• eccetera.

La pratica corrente che ho in mente è una struttura di proprietà semplice con abilità prevalenti.

Prendiamo i server di Google ai fini dell'esempio. Ognuno di essi ha un elenco di impostazioni da caricare.

Ad esempio, il server di Londra potrebbe avere:

rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.properties, Etc.

Laddove ogni file contiene un set di proprietà e la sequenza di caricamento consente di sovrascrivere le proprietà, più si procede.

Ad esempio: rootsettings.propertiespuò avere accessible=falsecome impostazione predefinita, ma viene sostituito searchengine.propertiesconaccessible=true

Il problema che sto riscontrando con questa struttura è che è molto facile sfuggire al controllo. Non è affatto strutturato, il che significa che puoi definire qualsiasi proprietà a qualsiasi livello e molti articoli possono diventare obsoleti.

Inoltre, la modifica di un livello intermedio diventa impossibile man mano che la rete cresce, poiché ora si influenza un numero molto elevato di server.

Ultimo ma non meno importante, ogni singola istanza potrebbe aver bisogno di 1 proprietà speciale, il che significa che il tuo albero finisce comunque con una configurazione per ciascun server, rendendola una soluzione non molto ottimale.

Gradirei molto se avessi suggerimenti / idee per una migliore architettura di gestione della configurazione.

Penso che devi prima porsi alcune domande e chiarire alcuni punti, quindi puoi decidere meglio come risolvere il tuo problema.

Primo: chi avrà il controllo sui server?

• È un singolo amministratore che controllerà centinaia di server? Quindi è necessario centralizzare il più possibile la configurazione.

• O ogni server è potenzialmente sotto il controllo di un singolo amministratore, che non desidera che le sue impostazioni vengano sovrascritte o controllate da una configurazione centralizzata? Quindi dovresti concentrarti sulla configurazione decentralizzata. Se ogni amministratore ha una manciata di server da gestire al massimo, è comunque gestibile manualmente.

Secondo: hai davvero bisogno di tonnellate di opzioni di configurazione o puoi mantenere il numero fino a pochi? Invece di rendere tutto ciò che è configurabile "per ogni evenienza", meglio auto-limitarsi alle opzioni di cui il proprio sistema ha veramente bisogno. Questo può essere fatto, ad esempio, con

• rendere il tuo software un po 'più intelligente (ad esempio, cosa può determinare automaticamente il programma chiedendo all'ambiente)?

• seguire rigidamente la "convenzione sulla configurazione", ad esempio stabilendo determinate convenzioni di denominazione o derivando alcune opzioni come predefinite da altre opzioni

Terzo: vuoi davvero un livello gerarchico di configurazione hardcoded nel software? Immagina di non sapere in anticipo quanti server ci saranno, se una gerarchia simile ad un albero è davvero la struttura migliore per loro o di quanti livelli deve avere l'albero. La soluzione più semplice che mi viene in mente è quella di non fornire alcuna configurazione centralizzata, solo un file di configurazione per server e lasciare che gli amministratori di server responsabili decidano da soli come risolvere il problema di gestione delle configurazioni di più server.

Ad esempio, gli amministratori potrebbero scrivere script del generatore che distribuiscono un file di configurazione centrale a un gruppo di server diversi e apportano alcune modifiche minori a ciascuna copia. In questo modo, non è necessario fare ipotesi sulla "topologia di distribuzione del server" in anticipo, la topologia può essere adattata in qualsiasi momento ai requisiti del mondo reale. Lo svantaggio è che hai bisogno di amministratori con una certa conoscenza di come scrivere script in una lingua come Perl, Python, Bash o Powershell.

Personalmente non mi è mai piaciuta l'ereditarietà dei file di configurazione. Hai detto di avere una sequenza di caricamento, non sei sicuro di come sia definito o derivato. Forse aiuta a rendere ovvia la sequenza eseguendo il mirroring in una struttura di directory in cui vengono inseriti i file o includendoli nei nomi dei file.

rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties

Questo funzionerà in qualche modo fino a un punto in cui hai un aggregato di valori di configurazione che non si allineano a una regione. Quindi devi essere attento all'asse organizzativo che scegli.

Quello che mi piace di più è isolare aggregati di valori di configurazione nei propri file e avere un file di configurazione (foglia) puntare a uno.

Un esempio:

bigcity.searchsettings.properties
regional.searchsettings.properties

Al londonsettings.propertiessuo interno potresti avere un valore come:

searchsettings:bigcity.searchsettings.properties

Ciò consente più gradi di libertà o uno aggiuntivo.

Ho avuto lo stesso problema e open source la mia soluzione. Puoi trovare il codice sorgente qui https://github.com/Bikeman868/Urchin

Lo uso per un sistema di grandi dimensioni con molti server, con diverse applicazioni su ciascun server e ambienti multipli. Include un'interfaccia utente scritta in Dart per la gestione della configurazione.

Puoi contattarmi direttamente se hai bisogno di aiuto per scendere da terra.

La soluzione che ho implementato è basata su regole. In genere inizi con una regola che si applica a tutte le configurazioni, quindi aggiungi puoi aggiungere regole come "tutte le macchine in questo ambiente creano file di registro in questo percorso UNC". Le regole possono essere specifiche per un ambiente, un'applicazione, una macchina o un'istanza di un'applicazione. Le regole possono anche essere più specifiche, come solo in questa specifica istanza di questa applicazione in esecuzione su questo server specifico.

Le regole vengono applicate nell'ordine dal meno specifico al più specifico e le regole successive possono sovrascrivere i valori specificati nelle regole precedenti. Questo significa ad esempio che è possibile creare una regola che si applica a una particolare applicazione, quindi sovrascriverla con un valore diverso per una macchina specifica o un'istanza specifica dell'applicazione ecc.

Il server ha un'interfaccia REST + JSON quindi funziona con la maggior parte dei sistemi di sviluppo e ha anche una comoda libreria client per le applicazioni .Net.

Questo tipo di impostazioni è un incubo da gestire. È meglio cercare di ridurli il più possibile facendo in modo che i componenti del software gestiscano tutti i casi.

vale a dire invece di impostare un server API per una regione, passare la regione con la chiamata API e lasciare che una configurazione a server singolo gestisca tutte le regioni.

Tuttavia, dato che siete nello stato in cui vi trovate. Vorrei sconsigliare la creazione di un sistema per la generazione delle impostazioni di configurazione. Aggiunge solo complessità a un problema già complesso.

Invece, è necessario memorizzare le impostazioni nello strumento di distribuzione per tipo di server. (impostazioni di distribuzione di polpo, riscritture di file di teamcity, ecc.) Ciò consente di essere sicuri di distribuire le stesse impostazioni di configurazione effettuate l'ultima volta durante l'aggiornamento del software e offre un controllo accurato delle modifiche.

Non vuoi trovarti nella situazione in cui apporti una modifica ai tuoi file meta-config e quindi devi testare quale file di configurazione produce nelle varie regioni / server / raggruppamenti personalizzati

Nessuna ricerca; tutta l'opinione personale, oltre 30 esperienze IT. Sembra una struttura di dati complicata, che può cambiare / modificare rapidamente, con un gran numero di utenti.

Considerare un repository di database (ad esempio SQL) per strutturare i dati, con processi di estrazione personalizzati che producono file di configurazione individuali per ciascun utente. È possibile utilizzare una query del database per determinare l'impatto di una modifica prima che venga implementata; trova occorrenze duplicate, ecc. I singoli file flat fanno parte del problema. Inoltre è possibile ottenere i registri delle modifiche e il supporto per il ripristino / ricostruzione. Con il controllo del database, potresti essere in grado di eliminare il problema di ereditarietà della configurazione. Questo tipo di soluzione richiederà una struttura di database aggiuntiva. La corretta struttura della chiave composita è molto importante.

Questo è il mio suggerimento.

Potresti esaminare alcuni costosi sistemi di sicurezza e controllo dei sistemi che implementano questo tipo di servizio. Considerali. In generale saranno dipendenti dall'ambiente.