tutorial ejemplo crear aws java spring configuration web-applications

java - ejemplo - lambda eclipse



¿Cómo mantienes Java Webapps en diferentes entornos de ensayo? (13)

Archivos de configuración separados, almacenados en el repositorio de control de origen y actualizados a mano. Normalmente, la configuración no cambia radicalmente entre una versión y la siguiente, por lo que la sincronización (incluso a mano) no es realmente un problema importante.

Para sistemas altamente escalables en entornos de producción, recomendaría seriamente un esquema en el que los archivos de configuración se guarden en plantillas, y como parte del script de construcción, estas plantillas se utilizan para procesar archivos de configuración "finales" (todos los entornos deberían usar el mismo proceso).

Es posible que tenga un conjunto de propiedades que se utiliza en la máquina del desarrollador, que varía de desarrollador a desarrollador, otro conjunto para un entorno de ensayo y otro para el entorno de producción.

En una aplicación de Spring, también puede tener beans que desee cargar en un entorno local, pero no en un entorno de producción, y viceversa.

Como manejas esto? ¿Utiliza archivos separados, filtrado de recursos ant / maven u otros enfoques?

Caleb P y JeeBee probablemente tengan su solución más rápida. Además, no tiene que configurar diferentes servicios o apuntar a archivos en diferentes máquinas. Puede especificar su entorno utilizando una variable $ {user.name} o especificando el perfil en un argumento -D para Ant o Maven.

Además, en esta configuración, puede tener un archivo de propiedades genéricas y anular los archivos de propiedades para los entornos específicos. Amb Ant y Maven soportan estas capacidades.

Solo uso diferentes archivos de configuración Spring XML para cada máquina y me aseguro de que todos los bits de datos de configuración que varían entre las máquinas sean referenciados por los beans que se cargan desde esos archivos de configuración de Spring.

Por ejemplo, tengo una aplicación web que se conecta a una interfaz Java RMI de otra aplicación. Mi aplicación obtiene la dirección de la interfaz RMI de esta otra aplicación a través de un bean configurado en el archivo de configuración Spring XML. Tanto mi aplicación como la otra tienen instancias de desarrollo, prueba y producción, así que tengo tres archivos de configuración para mi aplicación, uno que corresponde a la configuración adecuada para la instancia de producción, uno para la instancia de prueba y otro para el desarrollador ejemplo.

Entonces, lo único que necesito mantener en línea es qué archivo de configuración se despliega en cada máquina. Hasta ahora, no he tenido ningún problema con la estrategia de crear tareas Ant que manejen la copia del archivo de configuración correcto en su lugar antes de generar mi archivo WAR; así, en el ejemplo anterior, tengo tres tareas Ant, una que genera WAR de producción, una que genera el dev WAR y otra que genera la prueba WAR. Las tres tareas se encargan de copiar el archivo de configuración correcto en el lugar correcto y luego llamar al siguiente paso siguiente, que es compilar la aplicación y crear el WAR.

Espero que esto tenga algo de sentido ...

Tengo diferentes carpetas de configuración que contienen las configuraciones para la implementación de destino, y utilizo ANT para seleccionar la que se utilizará durante la etapa de copia de archivo.

Una solución que he visto utilizar es configurar el entorno de transición para que sea idéntico al entorno de producción. Esto significa que cada entorno tiene una VLAN con el mismo rango de IP y roles de máquina en las mismas direcciones IP (por ejemplo, la IP del clúster db siempre es 192.168.1.101 en cada entorno). Los cortafuegos mapeaban las direcciones externas a los servidores web, por lo que al intercambiar los archivos host en su PC se podía usar la misma URL: http://www.myapp.com/webapp/file.jsp iría a la puesta en escena o producción, dependiendo de en qué archivo de hosts has intercambiado

No estoy seguro de que esta sea una solución ideal, es bastante complicado de mantener, pero es interesante de notar.

Usamos archivos de propiedades específicos de los entornos y hacemos que la construcción de ant seleccione el conjunto correcto al construir los jarrones / guerras.

Las cosas específicas del entorno también pueden manejarse a través del servicio de directorio (JNDI), dependiendo de su servidor de aplicaciones. Usamos tomcat y nuestro DataSource se define en la implementación JNDI de solo lectura de Tomcat. Spring hace que la búsqueda sea muy fácil.

También usamos la estrategia ant para construir diferentes sitios (contenido diferente, roles de seguridad, etc.) desde el mismo proyecto fuente también.

Hay una cosa que nos causa un pequeño problema con esta estrategia de compilación, y es que a menudo los archivos y directorios no existen hasta que se ejecuta la compilación, por lo que puede dificultar la escritura de verdaderas pruebas de integración (usando el mismo conjunto de resorte) como cuando se implementó) que se pueden ejecutar desde el IDE. También te pierdes parte de la capacidad del IDE para verificar la existencia de archivos, etc.

Uso Maven para filtrar los recursos en src / main / resources en mi proyecto. Utilizo esto en combinación con archivos de propiedades para incorporar atributos personalizados en mis proyectos basados ​​en Spring.

Para las compilaciones predeterminadas, tengo un archivo de propiedades en mi directorio de inicio que Maven usa como sustituciones (para que mi instalación local de Tomcat se encuentre correctamente). El servidor de prueba y el servidor de producción son mis otros perfiles. Una simple -Pproduction es todo lo que se necesita para crear una aplicación para mi servidor de producción.

Uso la copia de Ant con un archivo de filtro. En el directorio con el archivo de configuración con variables, tengo un directorio con un archivo para cada entorno. El script de construcción conoce el env y usa el archivo variable correcto.

Utilizamos diferentes objetivos de hormigas para diferentes entornos. La forma en que lo hacemos puede ser un poco poco elegante, pero funciona. Simplemente le diremos a ciertos objetivos antis para filtrar los diferentes archivos de recursos (que es cómo se puede excluir la carga de ciertos beans), cargar diferentes propiedades de la base de datos y cargar diferentes datos iniciales en la base de datos. Realmente no tenemos un "experto" de hormigas corriendo, pero podemos ejecutar nuestras compilaciones con diferentes configuraciones desde un solo comando.

Acabo de poner las diversas propiedades en JNDI. De esta forma, cada uno de los servidores puede configurarse y puedo tener UN archivo war. Si la lista de propiedades es grande, alojaré los archivos de propiedades (o XML) en otro servidor. Usaré JNDI para especificar la URL del archivo a usar.

Si está creando diferentes archivos de aplicación (guerra / oído) para cada entorno, entonces no está desplegando la misma guerra / oído que está probando.

En una de mis aplicaciones, utilizamos varios servicios REST. Acabo de poner la url raíz en JNDI. Luego, en cada entorno, el servidor se puede configurar para comunicarse con el servicio REST adecuado para ese entorno.

No olvide investigar PropertyPlaceholderConfigurer: esto es especialmente útil en entornos donde JNDI no está disponible