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

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

Primo: chi deve avere il controllo sui server?

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

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

Secondo: hai davvero bisogno di tonnellate di opzioni di configurazione, o puoi tenere il numero a pochi? Invece di fare tutto e tutto configurabile "nel caso", meglio auto-limitarti alle opzioni che conosci davvero il tuo sistema ha bisogno. Questo può essere fatto, per esempio, da

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

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

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

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

Personalmente non mi è mai piaciuto l'ereditarietà dei file di configurazione. Hai menzionato una sequenza di caricamento, non sei sicuro di come sia definito o derivato. Forse aiuta a rendere evidente la sequenza specchiandola in una struttura di directory in cui inserisci i file o includendola nei nomi dei file.

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

Ciò funzionerà in qualche modo fino al punto in cui si dispone di 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 gli aggregati dei valori di configurazione nei propri file e avere un file di configurazione (foglia) puntato su uno.

Un esempio:

bigcity.searchsettings.properties
regional.searchsettings.properties

All'interno londonsettings.properties potresti avere un valore come:

searchsettings:bigcity.searchsettings.properties

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

Ho avuto lo stesso problema e ho aperto la mia soluzione. Puoi trovare il codice sorgente qui link

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

Puoi contattarmi direttamente se hai bisogno di aiuto per decollare.

La soluzione che ho implementato è basata su regole. In genere, si inizia con una regola valida per tutte le configurazioni, quindi è possibile 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 sostituire i valori specificati nelle regole precedenti. Ciò significa, ad esempio, che è possibile creare una regola che si applica a una particolare applicazione, quindi sostituirla 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 sono un incubo da gestire. È meglio provare a ridurli il più possibile facendo in modo che i componenti del software gestiscano tutti i casi.

Ad esempio, anziché impostare un server API per una regione, passare la regione con la chiamata api e lasciare che una singola configurazione server gestisca tutte le regioni.

Tuttavia, dato che ci si trova nello stato in cui ci si trova. Vorrei sconsigliare l'impostazione di un sistema per la generazione di impostazioni di configurazione. Aggiunge solo complessità a un problema già complesso.

Invece, avere le impostazioni memorizzate nello strumento di distribuzione per tipo di server. (impostazioni di implementazione di octopus, riscrittura di teamcity, ecc.) Ciò ti consente di essere sicuro di implementare le stesse impostazioni di configurazione che hai utilizzato l'ultima volta quando esegui l'upgrade del software e ti offre un controllo accurato sulle modifiche.

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

Nessuna ricerca; tutta l'opinione personale, 30+ esperienza IT. Sembra una complicata struttura dati, che può essere modificata / modificata rapidamente, con un gran numero di utenti.

Considerare un repository di database (eg.SQL) per strutturare i dati, con processi di estrazione personalizzati che producono singoli file di configurazione 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 registri delle modifiche e supporto per il ripristino / ricostruzione. Con il controllo del database, potresti essere in grado di eliminare il problema dell'ereditarietà della configurazione. Quel tipo di soluzione richiederà ulteriore struttura del database. La corretta struttura della chiave composita è molto importante.

Questo è il mio suggerimento.

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