La aplicación desarrollada corresponde con un gestor de expedientes que dispone de documentación asociada a estos y que está sujeta a un flujo de tramitación (BPM). Este flujo de tramitación es una herramienta horizontal a una organización en la que pueden integrarse distintas aplicaciones, que pueden tramitar, en un determinado momento, el flujo correspondiente, de esta manera se puede orquestar un proceso completo en la gestión de un expediente en la que pueden verse involucrados varias aplicaciones o servicios.
La aplicación descrita con anterioridad ha sido implementada usando una arquitectura basada en microservicios y un diseño basado en eventos. Son 7 los microservicios desarrollados para la aplicación Filemanagement, representados con un hexágono en el siguiente diagrama:
La interacción y dependencias entre estos microservicios y los servicios correspondientes, están detallados en el documento de "Memoria académica" de este TFM.
Todos y cada uno de los 7 microservicios tienen su propio repositorio de git, por tanto es necesario realizar clonado de cada repositorio en local:
git clone <URL del repositorio>
<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd"
xmlns="http://maven.apache.org/SETTINGS/1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<servers>
<server>
<id>filesmanagements-repository</id>
<username>file-user-repo</username>
<password>?????????????</password>
<passphrase>?????????????</passphrase>
</server>
</servers>
<profiles>
<profile>
<id>default</id>
<repositories>
<repository>
<id>filesmanagements-repository</id>
<name>Repositorio virtual filesmanagement</name>
<url>http://artifactory:8101/artifactory/files-repository/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>default</activeProfile>
</activeProfiles>
</settings>
Debido a que existe un proceso CD / CI que ejecutará una serie de 'stages' para garantizar la calidad del software desarrollado, debería ejecutarse el siguiente comando Maven:
mvn clean verify pmd:check package
El anterior comando ejecuta los plugins de PMD y checkstyle configurados en cada uno de los microservicios. Después de compilar el proyecto, éste puede ser levantado mediante el siguiente comando de Maven:
mvn spring-boot:run
También puede generarse en un entorno local, una imagen Docker correspondiente al microservicio correspondiente, mediante la ejecución del siguiente comando de Maven:
mvn com.google.cloud.tools:jib-maven-plugin:3.2.0:build -Dimage=<NOMBRE_IMAGEN>:<VERSION> -Djib.to.auth.username=<USUARIO_DOCKER_HUB> -Djib.to.auth.password=<PASSWORD_DOCKER_HUB>
Desde el punto de vista del desarrollo en un entorno local, es interesante utilizar Docker y/o Docker-compose, que permiten levantar servicios y microservicios, previamente dockerizados. En la carpeta "/docker" existen tres archivos de configuración de docker-compose que pueden ayudar al desarrollador en local:
-
docker-compose.yml: contiene todos los servicios y microservicios de la aplicación. Se tendrá que tener en cuenta las versiones actuales de cada uno de ellos para su integración.
-
docker-compose-services.yml: contiene solamente los servicios, por lo que se podría, por ejemplo, realizar pruebas de integración con una base de datos o una cola Kafka.
-
docker-compose-ci.yml: como ya se verá más adelante, este fichero levantan el entorno de integración.
Para poder utilizar alguna de estas configuraciones, es necesario ejecutar alguno de los siguientes comandos:
docker-compose -f <FICHERO.yml> up ->
Crea los contenedores y los inicializa.
docker-compose -f <FICHERO.yml> down ->
Elimina los contenedores previamente creados en el fichero.
docker-compose -f <FICHERO.yml> start ->
Inicializa los contenedores creados previamente por el mismo fichero.
docker-compose -f <FICHERO.yml> stop ->
Realiza la parada de los contenedores iniciados previamente por el mismo fichero.
- ci-cd: esta carpeta contiene el manifiesto para el despliegue de jenkins.
- svc: contiene todos los manifiestos de los servicios (kafka, mongodb, mysql, zookeeper).
- bpm.yml: manifiesto del microservicio de BPM.
- cdc-service.yml: manifiesto del servicio de Eventuate.
- docs.yml: manifiesto del microservicio de DOCS (documentación).
- files.yml: manifiesto del microservicio de FILES (expedientes, principal).
- front.yml: manifiesto del microservicio para el fontal de la aplicación.
- gateway.yml: manifiesto del microservicio de Gateway.
- index.yml: manifiesto del microservicio de indexación.
- ingress.yml: manifiesto para la configuración de Ingress.
- oauth2.yml: manifiesto del microservicio de autenticación.
- secrets.yml: manifiesto de configuración usuarios y passwords.
docker run --name artifactory -v <VOLUMEN>:/var/opt/jfrog/artifactory -d -p 8101:8081 -p 8102:8082 releases-docker.jfrog.io/jfrog/artifactory-oss:latest
/docker/docker-compose-ci.yml.
Todos los pipelines que son ejecutados mediante Jenkins son obtenidos del fichero Jenkinsfile existente en cada microservicio. Una posible configuración de jobs es la utilizada en este TFM que tiene las siguientes configuraciones:
- Crear proyecto "Multibranch": mediante este tipo de proyectos, Jenkins puede obtener todas las ramas de un repositorio.
- Configurar el repositorio de git: previamente hay que generar las credenciales y guardarlas en Jenkins.
- Asignar la ubicación relativa al proyecto donde se encuentra el fichero Jenkinsfile.
- Configurar tiempo para el poll que conecta Jenkins con el repositorio
- El despliegue de la aplicación en Okteto se realiza mediante la ejecución del contenedor de una imagen (dtzar/helm-kubectl). Para configurar las credenciales es necesario realizar un mapeo del fichero ".kube" que genera la instalción de la consola de Okteto
Al finalizar la configuración, Jenkins detectará cualquier cambio en alguna de las ramas del repositorio y lanzará el siguiente flujo, común para todos los microservicios:
