¿Dónde debo poner la configuración de mi aplicación?

Últimamente he estado leyendo un debate sobre " ¿Dónde deben almacenarse las propiedades que dependen del medio ambiente? ".

La forma clásica es tener múltiples archivos de propiedades, uno por entorno, y en función de una variable de entorno (DEV, PROD ...), usted elige dónde leerlos al iniciar la aplicación (como con los perfiles Spring).

Por otro lado, si está utilizando un contenedor para implementar su aplicación, se dice que este tipo de configuración debe provenir del entorno mismo (utilizando variables de entorno que lee la aplicación), de modo que la imagen no cambie entre entornos.

¿Cuáles son los pros y los contras de cada enfoque? ¿Existe un "mejor" enfoque para el escenario contenedor?

¿Quién dijo que los archivos de propiedades y las variables de entorno eran mutuamente excluyentes?

Hay una distinción que debe hacerse entre "¿Por dónde almacenar la configuración de mi aplicación?" Y "¿de dónde viene mi aplicación fuente que es de configuración?"

El resultado más probable es que probablemente todos deberían seguir haciendo lo que están haciendo con los archivos de configuración como mecanismo de almacenamiento (piense en un estado persistente a largo plazo mientras exista el entorno).

Sin embargo, en lugar de colocar ese archivo de configuración en el contexto de la aplicación y dejar que se ejecute, la aplicación debería poder esperar que esas variables ya estén disponibles en el entorno cuando se inicie.

Esto significa que necesita tener dos flujos de trabajo de implementación:

1. Implemento la aplicación de mayo en un entorno pasando por el proceso de control de cambios X y haciendo revisiones Y con la herramienta Z, lo que sea.
2. Despliego la configuración de mi entorno en un entorno al pasar por un proceso de control de cambios y hacer revisiones B con la herramienta C, el mismo proceso y un resultado diferente.

Para usar un ejemplo de administración de variables de entorno como pares de valores clave en una herramienta como cónsul, si está almacenando archivos de configuración en git, entonces herramientas como git2consul con control para llevar esa configuración al entorno cuando se actualiza.

Si tiene una aplicación que espera que haya una configuración disponible como archivo de configuración, entonces puede evitar enviar múltiples copias del archivo de configuración con la aplicación creando un proceso de implementación con algo como plantilla de cónsul que tenga la capacidad de activar su los valores del cónsul vuelven a un archivo.

 La forma en que lo hacemos es que tenemos 3 piezas (o artefactos) para cada aplicación en ejecución.

1. La aplicación que estamos desarrollando. Esto es lo mismo independientemente del entorno. Para que coincida con su ejemplo, esa será la aplicación Spring como jar / war.
2. El contenedor que ejecutará la aplicación. Esto es lo mismo independientemente del entorno. Si usa Spring Boot, ya no necesita Tomcat y solo el tiempo de ejecución de Java. Entonces use el contenedor openjdk Docker.
3. La configuración que necesita la aplicación. Esto es lo único que es diferente en todos los entornos. En una aplicación Spring, es probable que estés usando un archivo de propiedades.

El archivo de configuración vive en un control de origen separado. Esto solía ser Git, pero ahora estamos usando un SaaS que creamos llamado Config, en http://www.configapp.com . La característica principal de Config es el manejo sencillo de la configuración específica del entorno. Para ejecutar nuestra aplicación en un nuevo servidor, extraemos el contenedor Docker, el artefacto de la aplicación y el archivo de configuración para ese entorno. En el contenedor, montamos el directorio donde se almacena la aplicación y el archivo de configuración, como parte de la ejecución del contenedor. Nuestra aplicación es la misma. Nuestro contenedor / imagen es el mismo. Solo el archivo de configuración es diferente.

En cuanto al archivo de configuración vs variables de entorno. Durante mucho tiempo estuvimos usando archivos de configuración. Cuando usamos PaaS / cloud, utilizamos variables de entorno. Fue un trabajo extra si tienes mucha configuración, así que terminamos usando variables de entorno para determinar el archivo de configuración correcto. Tenemos una aplicación que convirtió las propiedades en variables de entorno, pero eso es atípico. Si tenemos un servidor de configuración centralizado autorizado por la compañía, lo usamos, de lo contrario nos gusta la simplicidad de los archivos de configuración.

Para resumir, extraemos app.jar, app.properties, openjdk Docker. Luego ejecutamos openjdk Docker montando la ubicación de app.jar y app.properties. Lo único específico del entorno es app.properties. Para administrar fácilmente las propiedades de las aplicaciones, independientemente de cuántas claves de propiedad, entornos, instancias de clúster / región, utilizamos Config.