Mejores prácticas para manejar un gran número de archivos de configuración / propiedad estructurados

Creo que primero debes hacerte algunas preguntas y aclarar algunos puntos, para que puedas decidir cómo resolver tu problema.

Primero: ¿quién tendrá control sobre los servidores?

• ¿Es un administrador único el que controlará cientos de servidores? Entonces necesitas centralizar la configuración tanto como sea posible.

• ¿O es posible que cada servidor esté bajo el control de un administrador individual, que no quiere que sus configuraciones sean anuladas o controladas por una configuración centralizada? Entonces deberías enfocarte en la configuración descentralizada. Si cada administrador tiene un puñado de servidores para administrar al máximo, esto todavía es manejable manualmente.

Segundo: ¿realmente necesitas toneladas de opciones de configuración, o puedes mantener el número en unos pocos? En lugar de hacer todo y todo configurable "por si acaso", mejor auto-restringiéndote a las opciones que tu sistema realmente necesita. Esto se puede hacer, por ejemplo, por

• haciendo que su software sea un poco más inteligente (por ejemplo, ¿qué puede determinar el programa automáticamente preguntando al medio ambiente)?

• siguiendo rígidamente la "convención sobre la configuración", por ejemplo, al establecer ciertas convenciones de nomenclatura o al derivar algunas opciones como un valor predeterminado de otras opciones

Tercero: ¿realmente desea un nivel jerárquico de configuración codificado en el software? Imagine que no sabe de antemano cuántos servidores habrá, si una jerarquía en forma de árbol es realmente la mejor Estructura para ellos, o cuántos niveles necesita tener el árbol. La solución más simple que se me ocurre es no proporcionar ninguna configuración centralizada, solo un archivo de configuración por servidor, y dejar que los administradores responsables del servidor se decidan cómo resuelven el problema de administrar las configuraciones de múltiples servidores.

Por ejemplo, los administradores pueden escribir secuencias de comandos generadoras que distribuyen un archivo de configuración central a un grupo de servidores diferentes y hacen algunas modificaciones menores a cada copia. De esa manera, no tiene que hacer suposiciones sobre la "topología de distribución del servidor" de antemano, la topología se puede ajustar en cualquier momento a los requisitos del mundo real. El inconveniente es que necesita administradores con algún conocimiento sobre cómo escribir scripts en un lenguaje como Perl, Python, Bash o Powershell.

Personalmente nunca me ha gustado la herencia de archivos de configuración. Usted menciona tener una secuencia de carga, no está seguro de cómo se define o se deriva. Tal vez ayude a que la secuencia sea obvia al reflejarla en una estructura de directorio en la que coloca los archivos o incluyéndola en los nombres de los archivos.

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

Esto funcionará de alguna manera hasta un punto donde tenga un conjunto de valores de configuración que no se alineen con una región. Por lo tanto, debe ser considerado con el eje organizativo que elija.

Lo que más me gusta es aislar agregados de valores de configuración en sus propios archivos y tener un punto de archivo de configuración (hoja) a uno.

Un ejemplo:

bigcity.searchsettings.properties
regional.searchsettings.properties

Dentro de londonsettings.properties podría tener un valor como:

searchsettings:bigcity.searchsettings.properties

Esto permite más grados de libertad o uno adicional.

Tuve el mismo problema y de código abierto mi solución. Puede encontrar el código fuente aquí enlace

Lo uso para un sistema grande con muchos servidores, con varias aplicaciones en cada servidor y múltiples entornos. Incluye una interfaz de usuario escrita en Dart para administrar la configuración.

Puede contactarme directamente si necesita ayuda para despegar.

La solución que implementé está basada en reglas. Por lo general, comienza con una regla que se aplica a todas las configuraciones, luego agrega que puede agregar reglas como "todas las máquinas en este entorno crean archivos de registro a esta ruta UNC". Las reglas pueden ser específicas de un entorno, una aplicación, una máquina o una instancia de una aplicación. Las reglas también pueden ser más específicas, ya que solo esta instancia específica de esta aplicación se ejecuta en este servidor específico.

Las reglas se aplican en el orden de las menos específicas a las más específicas, y las reglas posteriores pueden anular los valores especificados en reglas anteriores. Esto significa que, por ejemplo, puede crear una regla que se aplique a una aplicación en particular y luego anularla con un valor diferente para una máquina específica o una instancia específica de la aplicación, etc.

El servidor tiene una interfaz REST + JSON, por lo que funciona con la mayoría de los sistemas de desarrollo, y también tiene una conveniente biblioteca de clientes para aplicaciones .Net.

Este tipo de configuración es una pesadilla para administrar. Es mejor tratar de reducirlos tanto como sea posible haciendo que los componentes de su software manejen todos los casos.

es decir, en lugar de configurar un servidor de API para una región, pase la región con la llamada de API y deje que la configuración de un solo servidor maneje todas las regiones.

Sin embargo, dado que se encuentra en el estado en el que se encuentra. Recomendaría no configurar un sistema para generar ajustes de configuración. Solo agrega complejidad a un problema ya complejo.

En cambio, tenga las configuraciones almacenadas en su herramienta de implementación por tipo de servidor. (configuración de despliegue de pulpo, reescritura de archivos de teamcity, etc.) Esto le permite asegurarse de que está implementando la misma configuración que hizo la última vez cuando actualizó el software y le brinda un control detallado sobre los cambios.

No desea estar en la situación en la que realiza un cambio en sus archivos meta-config y luego tiene que probar qué archivo de configuración produce en sus diversas regiones / servidores / agrupaciones personalizadas

No hay investigación; toda opinión personal, más de 30 experiencia en TI. Suena como una estructura de datos complicada, que puede cambiar / modificar Rápidamente, con un gran número de usuarios.

Considere un repositorio de base de datos (por ejemplo, SQL) para estructurar los datos, con Procesos de extracción personalizados que producen archivos de configuración individuales para cada usuario. Puede usar una consulta de la base de datos para determinar el impacto de un cambio antes de que se implemente; encuentre ocurrencias duplicadas, etc. Los archivos planos individuales son parte del problema. Además, puede obtener registros de cambios y soporte de recuperación / reconstrucción. Con el control de la base de datos, es posible que pueda eliminar el problema de herencia de configuración. Ese tipo de solución requerirá adicional estructura de la base de datos. La correcta estructura de clave compuesta es muy importante.

Esa es mi sugerencia.

Es posible que analice algunos sistemas de control y seguridad de sistemas de proveedores muy costosos que implementan este tipo de servicio. Considerarlas. En general serán dependientes del medio ambiente.