Creación de nuevo micro servicio

De manera general, la creación de un nuevo microservicio incluye los siguientes pasos:

Elección del repositorio para el servicio

El código de los microservicios se encuentra organizado en repositorios por funcionalidad. Cuando se requiera crear un servicio nuevo, debe de pensarse en cuál de los repositorios actuales encaja o si es necesario generar un nuevo repositorio. Esta decisión puede consultarse con el líder técnico o arquitecto de desarrollo asignado al pod.

Nombramiento del servicio

El estándar de nombramiento de microservicios es el siguiente: <canal*>-<dominio o funcionalidad*>-service

Canal: únicamente se usa si el servicio estará en la capa OSL (canal) (ver: Organización de Microservicios Spin ), de ser el caso, se debe usar el nombre del canal como prefijo, por ejemplo, un servicio que será consumido por el app Spin estará en la capa de canal mobile y su nombre deberá comenzar con “mobile”. Si es un servicio de capa DSL core, no debe llevar ningún valor en este campo.

Ejemplos de canales y servicios:

Dominio o funcionalidad: únicamente se usa si el servicio es de capa DSL, el valor será el dominio o funcionalidad que abstraiga el servicio. Por ejemplo: account-service, user-service, transaction-inquiry-service, pricing-service.

Implementación

Para facilitar la implementación y garantizar que se sigan los estándares de estructura de paquetes y archivos de configuración de docker y kubernetes, se utiliza un plugin de gradle que genera un proyecto con la estructura de paquetes y archivos de configuración necesarios. Las instrucciones de cómo usarlo están en el README del proyecto de este plugin: https://github.com/fintechdigitalventure/spin-services-utils/blob/master/service-creator-gradle-plugin/README.md

Para la elección del puerto, debe ser un puerto que no haya ya sido usado por algún otro microservicio (preguntar en el canal de #backend de slack o a tu líder técnico)

Alta de Rol AWS IAM

Para que el servicio pueda consumir recursos AWS e interactuar con kubernetes EKS etc, es necesario que se dé de alta un rol IAM con el nombre del microservicio. Se debe solicitar a DEVOPS el alta en todos los ambientes no productivos y productivos. Para esta solicitud se debe generar un ticket de soporte técnico en el portal de service desk de Spin: https://fintechdigital.atlassian.net/servicedesk/customer/portal/5/group/7/create/26

Es necesario mencionar el nombre del servicio que debe coincidir con el que se coloca en la propiedad spring.application.name en el application.yml.

Una vez generado, se notifica a devops en el canal de Slack #devopsToDevelopers para que se atienda , arrobar al encargado de Devops.

Alta de log group de AWS Cloudwatch

Para que el servicio pueda reportar sus logs en cloudwatch, es necesario que tenga un log group creado. Se debe solicitar a DEVOPS el alta en todos los ambientes no productivos y productivos. Para esta solicitud se debe generar un ticket de soporte técnico en el portal de service desk de Spin: https://fintechdigital.atlassian.net/servicedesk/customer/portal/5/group/7/create/26

Es necesario mencionar el nombre del servicio que debe coincidir con el que se coloca en la propiedad spring.application.name en el application.yml.

Una vez generado, se notifica a devops en el canal de Slack #devopsToDevelopers para que se atienda , arrobar al encargado de Devops.

Alta de repositorio de imagen docker AWS ECR

El proceso de build construye las imágenes de docker y las almacena en el Elastic Container Registry (ECR) de AWS, por eso es necesario crear un registro ECR donde se estarán almacenando las imágenes del nuevo microservicio. Para esta solicitud se debe generar un ticket de soporte técnico en el portal de service desk de Spin: https://fintechdigital.atlassian.net/servicedesk/customer/portal/5/group/7/create/26

Es necesario mencionar el nombre del servicio que debe coincidir con el que se coloca en la propiedad spring.application.name en el application.yml.

Una vez generado, se notifica a devops en el canal de Slack #devopsToDevelopers para que se atienda , arrobar al encargado de Devops.

Alta de credenciales de acceso a mongo

Si el servicio requiere conexión a mongo, debe solicitarse al DBA el alta del usuario y credenciales que usará el microservicio para conectarse a mongo.

Para esta solicitud se debe generar un ticket de soporte técnico en el portal de service desk de Spin: https://fintechdigital.atlassian.net/servicedesk/customer/portal/5/group/7/create/26

Es necesario mencionar el nombre del servicio que debe coincidir con el que se coloca en la propiedad spring.application.name en el application.yml.

Una vez generado, se notifica al DBA (equipo Hydra) en el canal de Slack #data-team donde podrán asignarlo a alguien.

Cuando las credenciales sean generadas en todos los ambientes, se debe dar de alta la URL de conexión a mongo como secreto de kubernetes (ver: Administración de secretos de kubernetes )

Si el servicio no se conectará a mongo no es necesario este punto y deben hacerse las siguientes acciones:

• eliminar las dependencias de spring-data-starter del archivo build.gradle

• eliminar la propiedad spring.data y sus sub-propiedades del application.yml

• eliminar la referencia al secreto de kubernetes de asignación a la variable que comienza con MONGODB_URI en el archivo kubernetes.yml

  • Ejemplo, eliminar todo este código:

  • - name: MONGODB_URI_KYC
      valueFrom:
        secretKeyRef:
          name: kyc-service
          key: mongodb-kyc-uri

Alta de rutas en ALB ingress

Todas las peticiones a los PODs pasan por un balanceador de aplicación ALB (application load balancer) y este rutea la petición al microservicio mapeado en su configuración. Esto implica que cuando se crea un servicio nuevo, se requiere configurar al ALB para que pueda rutear el nuevo path al POD correcto.

Si el servicio es de capa core (ver: /wiki/spaces/SBO/pages/2092138549 ), se debe dar de alta únicamente en el ALB privado.

Si el servicio es de capa de canal, debe estar en el ALB público.

Configuración de secreto de kubernetes de trend micron

Los microservicios tienen un agente de seguridad que ayuda a protegerlos de ataques. Este agente se incluye en la imagen de docker de cada servicio como un JAR y debe configurarse a través de dos variables de ambiente: TREND_AP_KEY y TREND_AP_SECRET

Dependiendo de la capa (/wiki/spaces/SBO/pages/2092138549 ) en la que esté el nuevo servicio, deberá ser el secreto que se mapee a estas variables de ambiente. La configuración debe hacerse en el archivo kubernetes.yml del servicio, el mapeo ya estará ahí dado de alta por el service-creator-plugin, pero debe modificarse usando la siguiente tabla:

Ejemplo de un servicio de capa core:

- name: TREND_AP_KEY
  valueFrom:
    secretKeyRef:
      name: trend-micron
      key: key-spin-backend-services
- name: TREND_AP_SECRET
  valueFrom:
    secretKeyRef:
      name: trend-micron
      key: secret-spin-backend-services

Añadir el servicio al archivo settings.gradle del repositorio

Para que el build pueda construir el servicio se debe dar de alta en el archivo settings.gradle del repositorio donde vive el servicio