Cuál es la mejor manera de administrar los datos de configuración

Question

Estoy trabajando en un paquete de productos que tiene 4 productos. En este momento, todos los datos de configuración se encuentran en los archivos XML o de propiedades. Este enfoque no se puede mantener ya que tenemos que administrar diferentes archivos de configuración para diferentes entornos (por ejemplo, producción, desarrollo, etc.).

Entonces, ¿cuál es la mejor manera de manejar los datos de configuración?

Además, ¿podemos modularizar esto en un módulo separado? Para que todos los productos puedan usar este módulo. No queremos utilizar los archivos de propiedad. Estoy buscando una solución en la que podamos mover todo el código específico de configuración como un nuevo módulo de configuración y conservar todos los datos de configuración en la base de datos.

Answer 1

Usando commons-configuration tiene una API unificada para acceder a las propiedades, no importa cuán están representados - .properties, xml, JNDI, etc. Por ejemplo:

config.properties:

jdbcHost=192.168.12.35 
jdbcUsername=dbuser 
jdbcPassword=pass 

config.xml:

<config> 
    <jdbcHost>192.168.12.35</jdbcHost> 
    <jdbcUsername>dbuser</jdbcUsername> 
    <jdbcPassword>pass</jdbcPassword> 
</config> 

en ambos casos serán accesibles wi º algo como:

String host = config.getString("jdbcHost"); 

Answer 2

Ya casi ha terminado ... Me gustaría mantener el mismo enfoque y tirar en el archivo de configuración correcto para la instancia de la aplicación que se ejecuta por un método similar a uno de los siguientes :

1. nombre de todos sus archivos de configuración diferente y tiene su aplicación a tirar en algunos criterios únicos (nombre de usuario, nombre de host, etc.):

   • producción .properties
   • Developer1 .properties
   • Developer2 .properties

2. manteniéndolos fuera de la base de código en un lugar basado en una variable de entorno que la aplicación asume existe:

   • YOURAPP_CONFIG_DIR /server_config.xml
   • YOURAPP_CONFIG_DIR /database_config.properties

incluso he usado una combinación de estos enfoques en el mismo proyecto (# 1 para configuraciones de proceso de construcción y # 2 para las configuraciones de ejecución).

Answer 3

Para todos nuestros entornos, los datos de configuración se almacenan en las máquinas de destino en forma de archivos de propiedades.Usamos PropertyPlaceholderconfigurer de SpringFramework para vincular estas propiedades a nuestras aplicaciones para mantener las cosas portátiles en todos los entornos.

Por ejemplo, el tiempo que sé que /etc/myapp/database.properties estarán presentes en cualquier máquina de mi aplicación se ejecuta en, a continuación, en mi configuración de la primavera, sólo necesito algo así:

<bean id="myPropertyConfigurer" 
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
    <property name="locations"> 
     <list> 
      <value>/etc/myapp/database.properties</value> 
     </list> 
    </property> 
</bean> 
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource"> 
    <property name="driverClassName" value="com.mysql.jdbc.Driver" /> 
    <property name="url" 
     value="jdbc:mysql://${db.host}:3306/${db.name}" /> 
    <property name="username" value="${db.user}" /> 
    <property name="password" value="${db.pass}" />  
</bean> 

Hay un montón de opciones para esa clase de Spring sobre dónde pueden vivir los archivos de propiedades. Incluso puede hacer que las sustituciones y pasarlos en como variables de entorno:

<bean id="myPropertyConfigurer" 
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
    <property name="searchSystemEnvironment" value="true" /> 
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" /> 
    <property name="locations"> 
     <list> 
      <value>${database.configuration.file.url}</value> 
     </list> 
    </property> 
</bean> 

Y en bash_profile (o lo que sea): JAVA_OPTS exportación = "-Ddatabase.configuration.file.url = file: /// etc/myapp/database.properties "

O simplemente la misma opción -D que ingresa cuando llama a" java "dependiendo de lo que esté haciendo.

FWIW, mantenemos nuestros archivos de propiedades por separado como RPM.

Answer 4

Si las aplicaciones trabajan con una base de datos, puede crear una tabla de "configuración" de la siguiente manera:

create table configuration (mode char(3), key varchar(255), value varchar(1023)); 

Se podría inicializar usando un guión de inicio, dicen init.sql con contenidos a lo largo de las líneas de:

insert into configuration values ('pro', 'param1', 'value1'); -- production 
insert into configuration values ('dev', 'param1', 'value1'); -- development 
insert into configuration values ('tst', 'param1', 'value1'); -- testing 
... 

los beneficios de este enfoque son los siguientes:

• que la versión del script togeth er con su código
• se puede ampliar fácilmente para incluir por usuario o por grupo de ajustes por la adición de un identificador de usuario/grupo
• se puede cambiar la configuración en tiempo de ejecución si es necesario hacerlo
• se llega a utilizar la misma pila (APP + DAO, Cayena ...) que normalmente se utiliza para datos de aplicación núcleo mango a datos de configuración de la manija

Answer 5

Hay un montón de diferentes estrategias. Todos ellos son buenos y dependen de lo que mejor te convenga.

1. Construya un artefacto único e implemente las configuraciones en una ubicación separada. El artefacto podría tener variables de marcador de posición y, en el despliegue, la configuración podría leerse. Eche un vistazo al marcador de posición de la propiedad Springs. Funciona de manera fantástica para webapps que usan Spring y no implica involucrar a ops.
2. Tiene una configuración de propiedad externalizada que vive fuera de la aplicación web. Mantenga la ubicación constante y siempre lea desde la configuración de la propiedad. Actualice la configuración en cualquier etapa y se reiniciarán los nuevos valores.
3. Si está modificando el entorno (es decir, el servidor de aplicaciones utilizado o los permisos de usuario/grupo), mire utilizando los métodos anteriores con puppet o chef. También eche un vistazo a la administración de sus archivos de configuración con estas herramientas.

Answer 6

Aquí hay una solución sencilla y estúpida.

El fragmento de código, que intenta utilizar primero el archivo de propiedades en el directorio actual. Si falla, utilice el archivo de propiedades en el directorio de recursos (o en el archivo jar) en su lugar.

Properties configFile = new Properties(); 
    try { 
     configFile.load(new FileInputStream("production.properties")); 
    } catch (Exception e) { 
     System.err.println("Can not read properties, try to use default properties file."); 
     configFile.load(this.getClass().getClassLoader(). 
        getResourceAsStream("development.properties")); 
    } 

Answer 7

Las variables de entorno son casi la forma más fácil de hacerlo. Configúrelos como lo haría en cualquier otro momento, acceda a ellos con System.getenv("...")

Answer 8

Config es una herramienta de administración de archivos de configuración. Puede crear configuraciones comunes en todos los entornos, o puede crear una configuración específica del entorno. Puede seguir usando sus archivos XML y de propiedades, y dejar que Config mantenga las diferencias en el entorno. Puede pensar en Config como su base de datos centralizada y puede generar el archivo de configuración en el formato que desee. Siempre que desee su archivo de configuración, simplemente impleméntelo (empuje o tire) desde Config hasta su ubicación deseada. Tenga en cuenta que soy parte del equipo de configuración.