Sistema de documentación en los laboratorios ꢀꢁꢂꢀ+.
Estudio de caso de microservicios, devops y gestión de incidencias
vꢀꢁázqꢂꢀz bꢃꢄꢄꢀꢄꢃ, P., lꢅpꢀz Pꢆz, c. r., iꢇꢈꢆꢇꢉꢀ aꢊꢄꢀꢂ, a. l., eꢋꢌꢆꢁꢀꢄꢆ fꢆꢄꢍñꢆꢋ K.
revista cubana
de transformación digital
como obtener el plan de modificación de los documentos durante los próximos 3 años, poseer
información sobre el estado de implantación del sistema, la gestión de nomencladores y tener
la flexibilidad de poder implementar documentos en paralelo.
En el plano tecnológico, se incorporó el uso del Identity Access Manager (IAM) WSO2
Identity Server (WSO2 IS, 2023), en lo adelante IS, como solución de Single Sign On (SSO) en
la empresa, que se integra con el Lightweight Directory Access Protocol (LDAP) existente en la
empresa, con lo cual todas las aplicaciones desarrolladas deben ser configuradas en esta he-
rramienta para obtener los token correspondientes, y configurar los grupos y los usuarios que
pertenecerán a estos grupos.
También se incorporó la herramienta WSO2 Api Manager (WSO2 AM, 2023), en lo ade-
lante AM, para tener un control centralizado de las Api y controlar su acceso. El AM se inte-
gra con el IS para permitir que el token que genera el IS que pueda ser validado por el AM. El
hecho de tener un solo punto de entrada a todos los servicios propició que los especialistas de
redes pudieran realizar los cambios pertinentes en la Intranet, para que las Api no puedan ser
consumidas desde una subred que no sea la de administración; para cada subred se creó un
enlace en el firewall, como único punto posible de acceso al AM por temas de seguridad.
Se crearon dos entornos de despliegue, uno de prueba y otro de producción. Para ello se
establecieron dos clientes en el IS y el AM. En el caso del AM, por la integración mencionada
anteriormente, se pudo exponer la Api en la misma url, ya que como parte del procesamiento
del token es capaz de diferenciar los clientes asociados a cada entorno e internamente redirigir
la petición a la Api correspondiente. En la configuración del CI/CD se crearon dos configura-
ciones que se activan en dependencia de la rama que se haya modificado. En este aspecto, se
utiliza la rama máster, la cual está protegida y solo se puede actualizar a través de un Merge
Request, y la rama develop, donde se irán subiendo las nuevas funcionalidades para que los
usuarios las validen y, una vez hecho esto y comprobada la estabilidad, se pasa a la rama máster.
Para el despliegue de los frontends en el entorno de desarrollo como en el de producción,
se utilizó Nginx (Nginx, 2023) como proxy reverso, con el objetivo de replicar las experiencias
en la configuración de las políticas de acceso en la red, actuar como balanceador de carga y
añadir una cache. Esto último es muy importante, ya que las tecnologías utilizadas potencian
el uso de una cache.
Para dar respuesta a estos cambios, se hizo un cambio en la tecnología utilizada en la solu-
ción. Se decidió utilizar Nextjs (Nextjs, 2023), porque se aprovechan las lecciones aprendidas
en el desarrollo de la primera versión y de otros proyectos del grupo de desarrollo, resuelve al-
gunos problemas encontrados durante el desarrollo con React y permite una integración fácil
con cualquier sistema que soporte los protocolos OIDC (Oidc, 2023), OAUTH (Oauth, 2023)
y SAML, ya que viene con algunos default para los proveedores de identidad más utilizados y
da la posibilidad de configurar de forma relativamente sencilla una integración con cualquier
proveedor. Esto último fue lo que se hizo, ya que la integración con el IS no está entre los pro-
veedores para los que ya existe una configuración por defecto. La figura 1 muestra algunas
vistas funcionales del sistema de documentación.