Administre fácilmente configuraciones de microservicios con microconfig.io

Uno de los principales problemas en el desarrollo y posterior funcionamiento de microservicios es la configuración competente y precisa de sus instancias. En mi opinión, un nuevo marco puede ayudar con esto. microconfig.io. Le permite resolver algunas tareas rutinarias de configuración de aplicaciones de manera bastante elegante.

Si tiene muchos microservicios y cada uno de ellos viene con su propio archivo/archivos de configuración, entonces existe una alta probabilidad de cometer un error en uno de ellos, lo que puede ser muy difícil de detectar sin la habilidad adecuada y un sistema de registro. La tarea principal que el marco se propone es minimizar los parámetros de configuración de instancias duplicados, reduciendo así la probabilidad de agregar un error.

Veamos un ejemplo. Digamos que tenemos una aplicación simple con un archivo de configuración. yaml. Puede ser cualquier microservicio en cualquier idioma. Veamos cómo se puede aplicar el marco a este servicio.

Pero primero, para mayor comodidad, creemos un proyecto vacío en Idea IDE, después de instalar el complemento microconfig.io en él:

Configuramos la configuración de inicio del complemento, puede usar la configuración predeterminada, como en la captura de pantalla anterior.

Nuestro servicio se llama pedido, luego en un nuevo proyecto crearemos una estructura similar:

Coloque el archivo de configuración en la carpeta con el nombre del servicio - aplicación.yaml. Todos los microservicios se ejecutan en algún tipo de entorno, por lo que, además de crear una configuración para el servicio en sí, es necesario describir el entorno en sí: para ello crearemos una carpeta. env y agregarle un archivo con el nombre de nuestro entorno de trabajo. Por lo tanto, el marco creará archivos de configuración para los servicios en el entorno. dev, ya que este parámetro se establece en la configuración del complemento.

Estructura de archivos dev.yaml será bastante simple:

mainorder:
    components:
         - order

El marco funciona con configuraciones que están agrupadas. Para nuestro servicio, elija un nombre para el grupo. orden principal. El marco encuentra cada grupo de aplicaciones en el archivo de entorno y crea configuraciones para todas ellas, que encuentra en las carpetas correspondientes.

En el propio archivo de configuración del servicio solicite Especifiquemos solo un parámetro por ahora:

spring.application.name: order

Ahora ejecutemos el complemento y generará la configuración requerida para nuestro servicio de acuerdo con la ruta especificada en las propiedades:

Uno puede llevarse bien y sin instalar un complemento, simplemente descargando la distribución del marco y ejecutándola desde la línea de comandos.
Esta solución es adecuada para su uso en un servidor de compilación.

Vale la pena señalar que el marco comprende perfectamente perfecta sintaxis, es decir, archivos de propiedades ordinarios que se pueden utilizar juntos en yaml configuraciones.

Agreguemos otro servicio pago y complicar el existente.
В solicite:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

В pago:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100

El principal problema con estas configuraciones es la presencia de una gran cantidad de copiar y pegar en la configuración del servicio. Veamos cómo el marco ayudará a deshacerse de él. Comencemos con lo más obvio: la presencia de configuración. eureka en la descripción de cada microservicio. Creemos un nuevo directorio con el archivo de configuración y agreguemosle una nueva configuración:

Y ahora agreguemos la línea a cada uno de nuestros proyectos. #incluir eureka.

El marco encontrará automáticamente la configuración de eureka y la copiará en los archivos de configuración del servicio, mientras que no se creará una configuración de eureka separada, ya que no la especificaremos en el archivo de entorno. dev.yaml. Servicio solicite:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

También podemos mover la configuración de la base de datos a una configuración separada cambiando la línea de importación a #incluye eureka, oráculo.

Vale la pena señalar que el marco rastrea cada cambio cuando se regeneran los archivos de configuración y los coloca en un archivo especial al lado del archivo de configuración principal. La entrada en su registro se ve así: “La propiedad almacenada 1 cambia a orden/diff-aplicación.yaml" Esto le permite detectar rápidamente cambios en archivos de configuración grandes.

Eliminar partes comunes de la configuración le permite deshacerse de una gran cantidad de copiar y pegar innecesarios, pero no le permite crear de manera flexible una configuración para diferentes entornos; los puntos finales de nuestros servicios son únicos y están codificados, esto es malo. Intentemos eliminar esto.

Una buena solución sería mantener todos los puntos finales en una configuración a la que otros puedan hacer referencia. Para ello se ha introducido en el framework el soporte para comodines. Así cambiará el archivo de configuración eureka:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

Ahora veamos cómo funciona este marcador de posición. El sistema encuentra un componente llamado criterios de valoración y busca significado en ello eurekaip, y luego lo sustituye en nuestra configuración. Pero ¿qué pasa con los diferentes entornos? Para hacer esto, cree un archivo de configuración en criterios de valoración el siguiente tipo aplicación.dev.yaml. El marco de forma independiente, basándose en la extensión del archivo, decide a qué entorno pertenece esta configuración y la carga:

Contenido del archivo de desarrollo:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Podemos crear la misma configuración para los puertos de nuestros servicios:

server.port: ${ports@order}.

Todas las configuraciones importantes están en un solo lugar, lo que reduce la probabilidad de errores debido a parámetros dispersos en los archivos de configuración.

El marco proporciona muchos marcadores de posición ya preparados, por ejemplo, puede obtener el nombre del directorio en el que se encuentra el archivo de configuración y asignarlo:

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

Gracias a esto, no es necesario especificar adicionalmente el nombre de la aplicación en la configuración y también se puede colocar en un módulo común, por ejemplo, en el mismo eureka:

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

El archivo de configuración solicite se reducirá a una línea:

#include eureka, oracle
server.port: ${ports@order}

Si no necesitamos ninguna configuración de la configuración principal, podemos especificarla en nuestra configuración y se aplicará durante la generación. Es decir, si por algún motivo necesitamos un nombre único para el servicio de pedidos, simplemente dejaremos el parámetro nombre.de.aplicación.de.primavera.

Supongamos que necesita agregar configuraciones de registro personalizadas al servicio, que se almacenan en un archivo separado, por ejemplo, inicio de sesión.xml. Creemos un grupo separado de configuraciones para ello:

En la configuración básica, le indicaremos al marco dónde colocar el archivo de configuración de registro que necesitamos usando un marcador de posición. @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

En archivo inicio de sesión.xml Configuramos apéndices estándar, que a su vez también pueden contener marcadores de posición que el marco cambiará durante la generación de configuraciones, por ejemplo:

<file>logs/${this@name}.log</file>

Al agregar importación a las configuraciones del servicio volver a iniciar sesión, obtenemos automáticamente el registro configurado para cada servicio:

#include eureka, oracle, logback
server.port: ${ports@order}

Es hora de familiarizarse con más detalle con todos los marcadores de posición disponibles del marco:

${este@env} - devuelve el nombre del entorno actual.
${…@nombre} — devuelve el nombre del componente.
${…@configDir} — devuelve la ruta completa al directorio de configuración del componente.
${…@resultDir} — devuelve la ruta completa al directorio de destino del componente (los archivos resultantes se colocarán en este directorio).
${this@configRoot} — devuelve la ruta completa al directorio raíz del almacén de configuración.

El sistema también le permite obtener variables de entorno, por ejemplo la ruta a java:
${env@JAVA_HOME}
O bien, dado que el marco está escrito en JAVA, podemos obtener variables del sistema similares a la llamada Sistema::getProperty usando una estructura como esta:
${[email protected]}
Vale la pena mencionar el soporte para el idioma de extensión. Primavera EL. Las siguientes expresiones son aplicables en la configuración:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

y puedes usar variables locales en archivos de configuración usando la expresión #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

Por lo tanto, el marco es una herramienta bastante poderosa para el ajuste y la configuración flexible de microservicios. El marco cumple perfectamente su tarea principal: eliminar copiar y pegar en la configuración, consolidar la configuración y, como resultado, minimizar posibles errores, al tiempo que le permite combinar configuraciones fácilmente y cambiarlas para diferentes entornos.

Si está interesado en este marco, le recomiendo visitar su página oficial y familiarizarse con el completo. documentación, o profundizar en las fuentes aquí.

Fuente: habr.com