Externalización

Otro de los starter que nos proporciona Spring es el “server-config”. Esta api nos permite la carga completa de un fichero de configuración de forma externalizada.

Se necesitarán dos elementos, el server-config (servidor de configuración) y los clientes que recojan sus configuraciones en momento de arranque, de dicho server.

De lo que se trata es de que la mayor parte de la información que pueda haber en los ficheros de configuración de cualquier aplicación se externalicen en un lugar centralizado y externo a la propia aplicación. El server config será el encargado de hacer de puente entre las aplicaciones cliente y sus configuraciones específicas.

Con esta forma de carga de configuraciones, por ejemplo, cualquier modificación de alguno de los valores de una variable dada no haría necesario el despliegue de un nuevo artefacto de las aplicaciones cliente. Ni siquiera, como veremos gracias al starter actuator, será necesario reiniciar la aplicación dada.

En esta entrada veremos en detalle el config server, dejando para una posterior la del config client. No obstante, aun no disponiendo del cliente, veremos como verificar que el server está funcionando de forma correcta.

Config server

Como decíamos, el config server, será el encargado de gestionar todos los ficheros de configuración que caigan bajo su responsabilidad y servirlos a las aplicaciones cliente que lo soliciten.

Lo más habitual es ubicar los ficheros de configuración en un repositorio tipo git (github, gitlab…). A nivel empresarial, lo normal es que sea un repositorio privado. Es nuestro caso utilizaremos el gitlab público.

Dispondremos de tres entornos, des, dev y prod. Los ficheros se guardarán en una carpeta con el nombre de la aplicación cliente. A modo de ejemplo, la estructura en el gitlab será la siguiente para una aplicación cliente que llamaremos "config-client-example":

pom.xml

Añadimos la referencia al parent:

<parent>

             <groupId>org.springframework.boot</groupId>

             <artifactId>spring-boot-starter-parent</artifactId>

             <version>2.0.2.RELEASE</version>

       </parent>

Añadimos la referencia  específica del config server:

<dependency>

             <groupId>org.springframework.cloud</groupId>

             <artifactId>spring-cloud-config-server</artifactId>

       </dependency>

Para poder incluir este nuevo estarter hemos de añadir al pom:

            <dependencyManagement>

             <dependencies>

                    <dependency>

                           <groupId>org.springframework.cloud</groupId>

                           <artifactId>spring-cloud-dependencies</artifactId>

                           <version>Finchley.M9</version>

                           <type>pom</type>

                           <scope>import</scope>

                    </dependency>

             </dependencies>

       </dependencyManagement>
       <repositories>
                       <repository>
                   <id>spring-milestones</id>
                                    <name>Spring Milestones</name>
                                     <url>https://repo.spring.io/libs-milestone</url>
                                     <snapshots>
                                                <enabled>false</enabled>
                                     </snapshots>
                       </repository>
             </repositories>



java

A nivel de código en la clase principal se ha de añadir la anotación “@EnableConfigServer”. El resto del main permanece como cualquier aplicación Spring boot.

application.yml

En el fichero de configuración de nuestro config server habrá una mínima configuración

    server:

      port: 8888

 

    spring:

      cloud:

        config:

          server:

            git:

              uri: https://gitlab.com/gincol-cloud/config-files.git

              searchPaths: '{application}'

              cloneOnStart: true

              force-pull: true

              username: XXXX *

              password: YYYY *

    management:
      endpoints:
        web:
          exposure:
            include: refresh, info, health, metrics, trace

    (*) Sustituir por los valores correctos. Sólo necesario si el repositorio es privado, y debe serlo.            Si utilizáis un repositorio público, como en este ejemplo, no sería necesario.

Con esta configuración estamos apuntando a un gitlab como repositorio, que como decíamos es lo más habitual.

Con searchPaths indicamos que los ficheros estarán en la ruta del gitlab, pero en el interior de la carpeta con el nombre de la aplicación.

Con cloneOnStart indicamos que en el arranque se descage los ficheros a local para servirlos de forma más eficiente. Provoca un mayor tiempo de arranque.

Con force-pull indicamos que si por cualquier motivo, la copia local se degenerase, entonces se los vuelva a descargar del repositorio configurado.

Hemos incluido la configuración para el endpoint "/refresh" (ver artículo en este mismo blog) aunque veremos su utilidad en la entrada del config client.

Prueba

Una vez arrancado nuestro server invocamos la url "http://localhost:8888/config-client-example/des", donde el contexto se refiere al nombre de aplicación cliente que construiremos en unos momentos pero que ya hemos subido a una ruta de nuestro gitlab, y "des" corresponde al entorno del cual queremos recuperar el fichero.

y que se corresponde con el contenido del fichero "application-des.yml" de nuestro gitlab:

Podemos hacer lo mismo con el resto de entornos para ver el contenido del fichero correspondiente a dichos entornos. Para ello debemos cambiar "/des" por, en nuestro caso, "/dev" o "/prod".

Como decíamos más arriba, dejamos para la siguiente entrada como una aplicación cliente puede hacer uso de esta atractiva funcionalidad.

El código se puede descargar de

1. código server: https://gitlab.com/gincol-blog/config-server-example.git
2. ficheros configuración: https://gitlab.com/gincol-blog/config-files.git