Información general
El modelo de despliegue de servicios de interoperabilidad describe:
El contexto y plataformas en los que se despliegan los servicios.
Los requisitos del proceso de despliegue.
Cómo solicitar y configurar el pipeline para la construcción y despliegue.
Este modelo va dirigido a equipos de desarrollo que necesiten conocer el contexto en el que se despliegan los servicios de interoperabilidad, cómo solicitar la creación de un pipeline y sus opciones de configuración.
Diagrama de despliegue
Namespace
Existirá un namespace (API-M) para el clúster de interoperabilidad (MI Cluster), que será compartido con el clúster de API Manager (APIM Cluster). Este namespace será la puerta de entrada hacia los servicios de interoperabilidad, cuando las peticiones se realizan desde dentro de la plataforma de Openshift, y pasando por las APIs publicadas en el API Manager, cuando las peticiones vienen desde el exterior.
Dentro de este namespace, se desplegarán los pods que sean necesarios de la plataforma WSO2 Micro Integrator, que es la que permite que los servicios de interoperabilidad puedan funcionar.
Los servicios de interoperabilidad desplegados permitirán la comunicación con componentes que requieran de algún tipo de integración específica o pertenezcan a un sistema de información corporativo o sectorial.
Pod
Los pods son objetos que representan la unidad básica de despliegue en Kubernetes. Internamente un pod puede estar compuesto de uno o más contenedores.
El core de la plataforma de interoperabilidad se almacena en un único pod. De un pod pueden crearse varias réplicas que permiten distribuir la carga y garantizar la alta disponibilidad. Durante el despliegue del pod debe definirse qué contenedores lo conforman, así como la configuración de estos. En concreto, se desplegarán dos pods con la plataforma de WSO2 Micro Integrator para dar servicio en alta disponibilidad a la arquitectura de interoperabilidad como se indica en el patrón de despliegue según la documentación oficial de WSO2.
Servicio
Un Servicio es un recurso de la plataforma que proporciona un punto de acceso estable a una aplicación ejecutándose en un conjunto de pods como un servicio de red.
Todos los servicios existentes en el namespace estarán definidos con una DNS y tendrán un puerto asociado. De esta forma, durante el arranque del pod de WSO2 Micro Integrator, se establecerá una conexión con el servicio de autodescubrimiento de openshift que permitirá mapear las DNS por IP válidas para establecer la comunicación.
El principal beneficio de usar servicios y el servicio de autodescubrimiento proporcionado por Openshift es que abstrae a los componentes que necesiten usar los servicios de interoperabilidad de conocer la url física de los pods de WSO2 Micro Integrator. Dado que la IP se renueva cada vez que se reinicia el pod y que el número de réplicas puede cambiar, es muy complicado conocer esa información. Gracias al servicio de autodescubrimiento este proceso es transparente para dichos componentes, que solo se tienen que preocupar por conocer el DNS y el puerto del servicio con el que se quiere comunicar.
El nombrado del servicio se basa en la norma establecida para el nombrado de componentes añadiendo el sufijo -svc: [S/SA/SI]-[sistema]-[componente]-svc.
Volumen
Un volumen es un objeto de Kubernetes que permite almacenar información de forma persistente. En un objeto de tipo Volumen se almacena aquella información que no quiere perderse cuando el pod desaparezca.
Un pod puede tener asociado ninguno, uno o varios volúmenes. Los volúmenes son unidades de almacenamiento independientes para cada pod aunque compartida por todos los contenedores que lo forman.
Es posible crear volúmenes que se compartan entre varios pods usando el objeto de Kubernetes Persistent Volume Claim.
Persistent Volume Claim
Un PersistentVolumeClaim es un objeto en Kubernetes que permite solicitar y reservar un recurso de almacenamiento persistente. Un Persistent Volume Claim permite a los pods acceder al almacenamiento persistente sin importar el proveedor o la tecnología subyacente.
Un Persistent Volume Claim siempre está asociado a un volumen. Cuando la vinculación con el volumen se realiza con éxito, el pod puede utilizar ese volumen como almacenamiento persistente. El Persistent Volume Claim se encarga de administrar el ciclo de vida del recurso de almacenamiento, lo que incluye la creación, el montaje y la liberación del almacenamiento cuando ya no es necesario.
Este objeto es muy importante en la arquitectura de interoperabilidad porque los servicios de interoperabilidad se “despliegan” en un almacenamiento, que debe ser compartido por cada uno de los pods de WSO2 Micro Integrator. Cuando los pods se despliegan, cada uno monta el PVC en su sistema de archivos, permitiéndoles acceder a ese mismo espacio de almacenamiento compartido, donde pueden ver y modificar los servicios de interoperabilidad de forma sincronizada y persistente.
La creación de PVC en todos los entornos debe solicitarme mediante petición al equipo de operaciones. En la petición tiene que incluirse el nombre del PVC, el namespace donde se va a crear, el tamaño en almacenamiento que requiere y el modo de acceso.
Configuración
La configuración de los servicios de interoperabilidad se hará mediante ficheros ConfigMap. Estos ficheros almacenarán las propiedades de configuración de los servicios. Existirá un único fichero configmap en cada entorno y su gobierno es responsabilidad de la Oficina de Interoperabilidad.
El nombrado de los ficheros ConfigMap se basa en la norma establecida para el nombrado de componentes añadiendo el sufijo -config: [S/SA/SI]-[sistema]-[componente]-config.
Siempre que sea posible, este Configmap tendrá la información necesaria para conectarse a un servidor git externo donde se almacene la configuración de los servicios. Existirá un repositorio de configuración organizado por carpetas, una por cada servicio de interoperabilidad que se despliegue. Dentro de cada una de estas carpetas estarán los ficheros de configuración divididos por entornos.
La responsabilidad de gestionar y mantener estos repositorios de documentación será del equipo de la Oficina de Interoperabilidad. Para facilitar esta tarea, la Oficina de Arquitectura de Soluciones publicará herramientas que faciliten la conexión con los repositorios externos de configuración.
Secretos
Los secretos almacenan parámetros de configuración con información sensible y que no pueden estar reflejados en claro en un ConfigMap.
Los secretos no se cifrarán en el entorno de DES y será responsabilidad de los equipos de desarrollo la gestión y configuración de estos secretos, así como su repositado en el repositorio de la aplicación para delegar su aplicación a la herramienta ArgoCD. Además, si se observa la existencia de información sensible global para todos los servicios de un aplicativo se deberá crear un repositorio para ese tenant que contendrá todos los recursos globales de su configuración, como secrets, configmaps, keystores, etc.
Para los entornos de PRE y PRO los secretos se cifrarán y gestionarán usando la herramienta Sealed Secrets.
Un servicio de interoperabilidad puede tener asociado varios secretos. En cada namespace pueden crearse secretos comunes donde se centralicen en un único lugar la información sensible que deba ser compartida por todos los servicios.
El gobierno de este repositorio centralizado por namespace será responsabilidad de la Oficina de Interoperabilidad, que determinará qué parámetros son comunes y actualizará sus valores.
OTEL Collector
Aunque la plataforma actual usa Filebeat para la recolección de logs, se ha propuesto OTEL Collector como solución general para recolectar logs, métricas y trazas.
El OTEL Collector es un componente basado en Open Telemetry cuya principal funcionalidad es recopilar y procesar la información de observabilidad recolectada por cada uno de los componentes desplegados en el namespace.
La información recogida se mandará a los componentes de la Plataforma de Observabilidad para su gestión y visualización.
El principal beneficio de Open Telemetry Collector es que permite aislar a los componentes del namespace de la plataforma de observabilidad. Un servicio de interoperabilidad no necesita saber a dónde van a dirigirse las métricas, trazas y logs generados; Open Telemetry Collector centraliza la recolección y manda la información a los diferentes destinos que tiene configurado, como pueden ser las herramientas de observabilidad (Prometheus, Jaeger…) definidas en la plataforma de observabilidad centralizada.
La plataforma de interoperabilidad enviará al OTEL Collector las métricas, trazas y logs producidas por el código en tiempo de ejecución. Estas métricas, trazas y logs incluyen tanto las que genera automáticamente la plataforma, los conectores de terceros que usen y las generadas programáticamente por el equipo de desarrollo directamente en el servicio de interoperabilidad.
Comunicaciones
A continuación, se indican los diferentes casos de uso que se identifican para gobernar la comunicación con servicios de interoperabilidad.
Comunicación entre un FrontEnd y un servicio de interoperabilidad
Este tipo de comunicación normalmente se produce cuando un componente Frontend (portal web, MicroFrontEnd, aplicación móvil…) solicita información a un componente Backend de un Servicio de Información Corporativo o un Sistema de Información Sectorial para realizar una tarea.
Deberá analizarse, por parte del equipo de desarrollo, qué información debe solicitar el Frontend para que el equipo de la Oficina de Interoperabilidad cree las API necesarias, siguiendo los criterios establecidos por la Arquitectura de API, desplegándolas en el API Manager siguiendo las directrices indicadas en el Modelo de Despliegue de API.
Sea como sea, esta comunicación deberá estar securizada mediante token JWT, mTLS o algún mecanismo de seguridad similar que garantice que se cumple el principio de Zero Trust.
Comunicación entre un microservicio y un servicio de interoperabilidad
Se engloba en este caso de uso la comunicación entre un microservicio y un servicio que es desplegado por la arquitectura de interoperabilidad, pero no es publicado como API en el API Manager.
En este caso, el equipo de desarrollo de la Oficina de Interoperabilidad creará o habrá creado un conector en el bus de interoperabilidad que permita dicha comunicación. Esta comunicación estará gobernada por la Oficina de Interoperabilidad, que guiará al equipo de desarrollo del microservicio sobre la mejor forma de realizarse.
Seguridad
Será necesario que el acceso a los servicios de interoperabilidad esté securizado.
Por un lado, a nivel de capa transporte, además de usar HTTPS, se puede configurar Mutual SSL. Para ello, es necesario cargar los certificados públicos de los clientes que van a consumir los servicios. Estos tendrán que configurar su certificado privado en el momento de realizar la petición.
Por otro lado, según el tipo de servicio a implementar, también hay que añadir seguridad para su uso:
- API REST: WSO2 Micro Integrator solo permite el uso de autenticación básica (usuario y contraseña), enviada en la cabecera Authorization en el formato Base64(username:password). No obstante, y siguiendo las directrices de seguridad generales, todos las integraciones API REST se autenticarán mediante token jwt. Para ello, será necesario que se proporcionen servicios de verificación de token jwt para que la plataforma de integración pueda validarlos.
- Proxy Service: WSO2 Micro Integrator permite añadir seguridad a los servicios proxy a través de la creación de una política de seguridad (WS-Policy).
- Data Service: WSO2 Micro Integrator admite las especificaciones WS-Security, WS-Policy y WS-Security Policy. Estas especificaciones definen un modelo de comportamiento para los servicios web. Para habilitar una política de seguridad para un servicio de datos, se debe crear un archivo de política de seguridad para luego agregarlo al servicio de datos.
Proceso de instalación y despliegue
Entorno pre-cloud
A continuación se listan los pasos que deben seguirse para desplegar un módulo de interoperabilidad.
- Ponerse en contacto con DevSecOps para notificar el despliegue del módulo y solicitarles los siguientes elementos:
- Creación de una instancia de la pipeline de camino único en Jenkins.
- Creación del despliegue en ArgoCD.
- En el repositorio git deben crearse el Webhook con los siguientes datos:
- URL: Instancia de la pipeline proporcionada por DevSecOps
- Check que deben estar marcados: Tag push events, Merge request events y Enable SSL verification.
- El módulo debe tener configurado los siguientes elementos.
- Fichero pom.xml: Se debe definir el empaquetado para genere artefactos de tipo CAR.
- Fichero ci.json: Contiene la configuración de los parámetros de entrada para la correcta ejecución de la pipeline de Jenkins.
- Fichero sonar.properties: Contiene la configuración para que la pipeline pueda ejecutar correctamente el paso de validación de calidad del código en Sonarcube.
- Directorio despliegue: Este directorio contiene una carpeta para cada entorno (test, pre y pro). Cada carpeta contiene los ficheros necesarios para el despliegue en ese entorno. El contenido de esta carpeta sigue el patrón de despliegue de Kubernetes Kustomize.
- Iniciar el proceso de despliegue siguiendo el procedimiento indicado en la documentación relativa a la estrategia de ramificación y verificar tanto en Jenkins como en ArgoCD y Openshift que el proceso de despliegue se está ejecutando correctamente.
Para más información sobre estos ficheros consultar la documentación publicada por DevSecOps y la documentación oficial de Red Hat Openshift y Kubernetes.