Mejores prácticas para manejar una gran cantidad de archivos de configuración / propiedad estructurados

Imagine un sistema que tiene una gran cantidad de servidores. Cada uno de ellos tiene una serie de configuraciones:

• Algunos específicos para el servidor.
• Algunos específicos de la región.
• Algunos comunes en todos ellos
• Tal vez pueda tener algunas agrupaciones personalizadas, como este grupo de servidores es solo para lectura
• etc.

La práctica actual que tengo en mente es una estructura de propiedad simple con habilidades primordiales.

Tomemos los servidores de Google para el propósito del ejemplo. Cada uno de ellos tiene una lista de configuraciones para cargar.

Por ejemplo, el servidor de Londres puede tener:

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

Donde cada archivo contiene un conjunto de propiedades y la secuencia de carga le permite anular propiedades, cuanto más avance.

Por ejemplo: rootsettings.propertiespuede tener accessible=falsepor defecto, pero se reemplaza searchengine.propertiesconaccessible=true

El problema que tengo con esta estructura es que es muy fácil perder el control. No está estructurado en absoluto, lo que significa que puede definir cualquier propiedad en cualquier nivel y muchos elementos pueden quedar obsoletos.

Además, cambiar un nivel medio se vuelve imposible a medida que la red crece, ya que ahora afecta a una gran cantidad de servidores.

Por último, pero no menos importante, cada instancia individual puede necesitar 1 propiedad especial, lo que significa que su árbol termina con una configuración para cada servidor de todos modos, por lo que no es una solución muy óptima.

Le agradecería mucho si tiene alguna sugerencia / idea de una mejor arquitectura de gestión de la configuración.

Creo que primero debe hacerse algunas preguntas y aclarar algunos puntos, luego puede decidir mejor cómo resolver su problema.

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

• ¿Es un solo administrador quien controlará cientos de servidores? Entonces necesita centralizar la configuración tanto como sea posible.

• ¿O cada servidor está potencialmente bajo el control de un administrador individual, que no quiere que su configuración sea anulada o controlada por una configuración centralizada? Entonces debería centrarse en la configuración descentralizada. Si cada administrador tiene un puñado de servidores para administrar al máximo, esto aún se puede administrar manualmente.

Segundo: ¿realmente necesita toneladas de opciones de configuración, o puede reducir el número a unas pocas? En lugar de hacer que todo y todo sea configurable "por si acaso", mejor limítese a las opciones que sabe que su sistema realmente necesita. Esto puede hacerse, por ejemplo, por

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

• siguiendo rígidamente la "convención sobre la configuración", por ejemplo, estableciendo ciertas convenciones de nomenclatura o derivando algunas opciones como predeterminadas 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 similar a un árbol realmente es la mejor estructura para ellos, o cuántos niveles debe tener el árbol. La solución más simple que se me ocurre es que no proporciona ninguna configuración centralizada, solo un archivo de configuración por servidor, y deja que los administradores responsables del servidor decidan cómo resolver el problema de administrar las configuraciones de varios servidores.

Por ejemplo, los administradores pueden escribir scripts de generador que distribuyan un archivo de configuración central a un grupo de servidores diferentes y que realicen algunas modificaciones menores en cada copia. De esa manera, no tiene que hacer ninguna suposición 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 algunos conocimientos sobre cómo escribir scripts en un lenguaje como Perl, Python, Bash o Powershell.

Personalmente nunca me gustó la herencia del archivo de configuración. Usted menciona que tiene una secuencia de carga, no está seguro de cómo se define o deriva. Tal vez sea útil hacer que la secuencia sea obvia reflejándola en una estructura de directorio en la que coloca los archivos o incluyéndola en los nombres de archivo.

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

Esto funcionará hasta cierto punto hasta que 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 los agregados de valores de configuración en sus propios archivos y tener un archivo de configuración (hoja) que apunte a uno.

Un ejemplo:

bigcity.searchsettings.properties
regional.searchsettings.properties

En londonsettings.propertiessu interior 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 mi solución de fuente abierta. Puede encontrar el código fuente aquí https://github.com/Bikeman868/Urchin

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 puede agregar reglas como "todas las máquinas en este entorno crean archivos de registro en 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, como solo en esta instancia específica de esta aplicación que se ejecuta en este servidor específico.

Las reglas se aplican en el orden de menos específico a más específico, y las reglas posteriores pueden anular los valores especificados en reglas anteriores. Esto significa, por ejemplo, que puede crear una regla que se aplique a una aplicación en particular, 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 biblioteca de cliente conveniente para aplicaciones .Net.

Este tipo de configuración es una pesadilla para administrar. Es mejor intentar reducirlos lo más posible haciendo que los componentes de su software manejen todos los casos.

es decir, en lugar de configurar un servidor api para una región, pase la región con la llamada 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 que se encuentra. Le aconsejaría que no configure un sistema para generar ajustes de configuración. Solo agrega complejidad a un problema ya complejo.

En su lugar, tenga la configuración almacenada en su herramienta de implementación por tipo de servidor. (configuración de implementación de Octopus, reescritura de archivos de teamcity, etc.) Esto le permite asegurarse de que está implementando la misma configuración que la última vez que realizó la actualización del 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 de metaconfiguración y luego tiene que probar qué archivo de configuración produce en sus diversas regiones / servidores / agrupaciones personalizadas

Ninguna investigación; Toda opinión personal, más de 30 años de experiencia en TI. Suena como una estructura de datos complicada, que puede cambiar / modificarse rápidamente, con una gran cantidad 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; encontrar casos duplicados, 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, puede eliminar el problema de herencia de configuración. Ese tipo de solución requerirá una estructura de base de datos adicional. La estructura correcta de la clave compuesta es muy importante.

Esa es mi sugerencia.

Puede analizar algunos sistemas de control y seguridad de sistemas de proveedores muy costosos que implementan este tipo de servicio. Considerarlos. En general, dependerán del medio ambiente.