Manejo de archivos de configuración en aplicaciones web Spring

Question

Me he topado varias veces con el mismo problema, y ​​me gustaría tener alguna información sobre lo que otras personas piensan sobre el problema: Supongamos que tenemos la aplicación Spring empaquetada como .war y queremos ejecutarlo en varios entornos. (desarrollo/prueba/preproceso/prod/etc)

Para acceder a la infraestructura que necesita la aplicación, (bases de datos/servicios web, etc.) almacenamos la información de acceso en archivos de configuración, también hay alguna configuración comercial en esos archivos. Digamos que usamos .properties archivos para este propósito (porque tenemos una aplicación de resorte dentro de la guerra y nos gusta que las propiedades sean leídas por un trazador de líneas en el contexto de aplicación) y también suponemos que en los diferentes entornos no utilizamos No tiene el mismo servidor de aplicaciones/contenedor de servlets. (Por ejemplo: dev, test: amarre, preprod: Tomcat, prod: GlassFish)

Lo que por lo general han hecho es crear múltiples perfiles de Maven , uno para cada entorno, la configuración necesaria en los archivos correspondientes para cada uno.

Ahora, recientemente me he enfrentado a una pregunta de un tipo que ejecuta operaciones: '¿Realmente tenemos que generar una nueva compilación con el perfil apropiado en el servidor de compilación si el DB se cambia en el entorno preprod?' me respondió: 'No, en realidad se puede ir a .../webapps/currentApp/WEB-INF/classes/config/application.properties y cambiar los valores de allí, a continuación, reinicie el contenedor'

Hemos llegado con una solución que resuelve algunos aspectos de este problema: usando el plugin de ensamblaje de Maven, incrustamos un Jetty dentro de la guerra que lo hace utilizable como una guerra 'ejecutable', también nos da la posibilidad de tener una configuración global XML, del cual el iniciador del Jetty integrado crea/modifica los archivos .properties apropiados en el directorio de guerra explotado y solo luego inicia la aplicación.

Pero, una vez más, esto no resuelve el problema si desea utilizar cualquier otra cosa que no sea Jetty.

¿Cómo se está enfrentando cada uno con la misma situación?

Answer 1

variable de entorno, los archivos de configuración externos

Tenemos algo similar, una aplicación Web que se ejecuta en Tomcat/Weblogic con la primavera. Lo que hacemos es definir environment property CONFIG_PATH y poner todos los archivos XML (incluida la configuración de resorte) y de propiedades en ese directorio.

Tenemos varios archivos de propiedades (por entorno) que le enviamos como un archivo tar. La aplicación web carga todas las propiedades/archivos de configuración Spring del directorio CONFIG_PATH. Esta variable se define como variable de entorno en el entorno respectivo

De esta forma no estamos tocando el archivo WAR ni creando WAR separados para el entorno. Piense en este escenario: QA archivos WAR & PROD construidos, control de calidad a prueba de control de calidad archivo de la guerra, GUERRA PROD desplegado en PROD pero algo hace saltar :(

Hacemos algo de la siguiente manera:

En xml de configuración de la primavera, definimos :.

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
    <property name="order" value="0"></property> 
    <property name="locations"> 
     <list> 
      <value>file:${CONFIG_PATH}/App.properties</value> 
     </list> 
    </property> 
</bean> 

Consulte todas las variables como es habitual en la configuración de primavera

en web.xml definimos configuración de primavera de la siguiente manera:

<listener> 
    <listener-class>org.springframework.web.context.ContextLoaderListener 
    </listener-class> 
</listener> 

<context-param> 
    <param-name>contextConfigLocation</param-name> 
    <param-value>file:${CONFIG_PATH}/**/spring-config.xml 
    </param-value> 
</context-param> 

El equipo de QA/PROD despliega el mismo artefacto con sus archivos de entorno correspondientes. Si algo explota, sabemos que es solo el env. propiedades que están en mal estado. HTH

Answer 2

base de datos

Los desarrolladores no pueden tocar un WAR una vez que vaya a un entorno en el que trabajo, por lo que si tenemos que cambiar un valor de configuración sin volver a desplegar lo ponemos en una base de datos relacional.

No es necesario volver a empaquetar, redistribuir ni botar un servidor. Sin embargo, la aplicación tiene que actualizar la configuración de solo lectura periódicamente.

JNDI

JNDI ajustes permanecen fijos desde un entorno a otro; esos cambios son configurados una vez por el administrador del servidor de la aplicación y no cambian. (Ver Oracle Tutorial)

Estoy hablando de pares de nombre/valor para la configuración de la aplicación en sí, no JNDI.

Answer 3

Para fuentes de datos; es un enfoque común en el contexto de Tomcat crear una entrada de recursos JNDI y desacoplar las entradas/configuraciones de recursos de su aplicación. Si se cambia DB, entonces puede reconfigurar su recurso JNDI en su contenedor (Tomcat, Jetty etc.) y reiniciar.Si tiene una granja de contenedores, no será un problema reiniciar sus instancias de tomcat. puede desactivarlos en el equilibrador de carga y reiniciar, reactivar. Creo que hay un archivo de contexto en Jetty también en el que puede agregar recursos JNDI. Además, hay perfiles maven para las propiedades que dependen de contextos diferentes. puede seleccionar su perfil con el parámetro "-P" de maven, y su proyecto se construirá con estas configuraciones, por ejemplo para los diferentes contextos de destino, como en vivo y prueba.