Introducción

Como herramienta aceleradora de proyectos, el Onesait Platform Center ha desarrollado un enfoque para migrar aplicaciones existentes a entornos Cloud utilizando el estándar Kubernetes.

Pasos para la migración

Los pasos propuestos para migrar una aplicación Legacy a una arquitectura contenerizada son estos:

1. Assessment de la aplicación actual: Consiste en identificar todos los elementos del sistema actual. El principal objetivo es identificar:

   • Elementos software a contenerizar, bien mediante un contenedor generado ad-hoc (ej WAR de un desarrollo a medida), bien mediante un contenedor oficial de un producto que se venia usando mediante un despliegue on-premise (ej API Manager comercial).

   • Elementos software candidatos a sustituir por un servicio Cloud (ej Base de datos).

   • Interacciones entre elementos.

   • Distribución de la aplicación en un entorno de despliegue típico, que permita identificar requisitos a tener en cuenta en el entorno cloud (número de máquinas, requisitos mínimos, despliegue multizona o multiregión…).

   • Elementos a mantener temporalmente y cuya migración se acometerá en iteraciones sucesivas. (Pej: software de integración con otros sistemas).

   • Elementos a mantener de forma permanente y que necesitarán de una solución hibrida cloud – onpremise. (Pej: HSM de cifrado).

2. Contenerización del software actual: Identificadas las piezas a desplegar en entorno cloud de las que no se disponga de una imagen oficial proporcionada por un fabricante, se construyen imágenes contenerizadas de las mismas, se versionan y se publican en un registro para su descarga en el entorno cloud. Este paso puede constituir ya de por sí una primera descomposición del sistema original, ya que mientras en el sistema original un mismo servidor podía albergar varios módulos software (ej Un WAS ejecuta múltiples módulos de una misma aplicación o un Apache contiene múltiples aplicaciones web), en la contenerización se pueden individualizar para que cada módulo constituya una unidad independiente

3. Preparación para despliegue en Kubernetes: Kubernetes supone el estándar actual para el despliegue de aplicaciones en entornos Cloud tanto públicos como privados, por lo que cualquier aplicación migrada al cloud debe ser aplantillada para ser desplegada en Kubernetes de manera transparente a la cloud donde se haga el despliegue. En este sentido existen diferentes alternativas, como Kustomize o Helm para aplantillar aplicaciones mediante los descriptores yaml de Kubernetes.

4. Despliegue de la misma aplicación en los diferentes entornos cloud con cambios mínimos de configuración.

Siguiendo estos pasos, se puede llevar una aplicación al cloud con los cambios mínimos, permitiendo al equipo familiarizarse con el nuevo paradigma, identificar las ventajas de llevar su solución a un entorno Cloud, descubrir las  nuevas herramientas y técnicas y así acometer los siguientes pasos iterativamente, haciendo rearquitecturado de módulos en diferentes sprints y migrando paulatinamente a una arquitectura de microservicios.

Soporte en Control Center

El Center proporcionan un conjunto de herramientas y transformaciones automáticas para facilitarlo.

Para ello disponemos de un tipo de proyecto concreto para acometer Migraciones al Cloud.

Open

Una vez dado de alta un proyecto de Migración al Cloud, dispondrá del conjunto de opciones que permitan llevar a cabo una migración al cloud según las fases descritas anteriormente.

Fase de Assessment

Identificación de todos los elementos que componen nuestra aplicación en la actualizad. Hay 2 formas de abordarlo:

• Assessment Manual: Dando de alta uno a uno cada elemento en un formulario.

• Mediante un agente: Pequeño software que analiza un entorno típico identificando elementos candidatos para incluir como elementos de la aplicación, una finalizado se sube el resultado al Platform Center y se termina de editar manualmente si falta o sobra algún elemento.

Open

Un Assessment completado consiste en la identificación de todos los módulos software y del resto de piezas que componen la aplicación.

En concreto:

• Listado de módulos WAR y sus contenedores JEE de despliegue (Tomcat, Jetty, JBoss…)

• Listado aplicaciones web y los servidores web donde están desplegadas (NGINX, Apache…)

• Listado de Procesos standalone:

  • Java

  • Python

  • NodeJS

  • Otros procesos

• Listado de Bases de datos, su SGBD y la lista de esquemas.

• Listado de Balanceadores, su tecnología subyacente y redirecciones.

• Listado de Brokers de mensajería, su tecnología subyacente más la lista de colas y tópicos.

• Listado de ESBs y su tecnología subyacente.

• Listado de Api Managers, su tecnología subyacente y redirecciones.

• Listado de Caches distribuidas y su tecnología.

• Distribución de todos los elementos software en las diferentes máquinas para un despliegue típico.

Complementario al Assessment, se genera un Diagrama de Assessment, que recoge toda la información anterior de una manera gráfica. Se trata de un diagrama editable, de manera que todos las modificaciones que se hagan en el diagrama se reflejan en el assessment y viceversa

Fase de contenerización

Identificados todos los elementos de la aplicación se lleva a cabo una contenerización de los mismos.

Desde el propio Assessment de la aplicación es posible solicitar una contenerización automática, de manera que el Center genera un diagrama de contenerización a modo de propuesta. Este diagrama se puede aceptar o modificar una vez evaluado por un arquitecto de la aplicación.

El Onesait Platform Center sigue los siguientes criterios para contenerizar los elementos del assessment:

• Por cada WAR: Un contenedor, eligiendo como imagen base del contenedor la del contenedor JEE seleccionado en el assessment (tomcat, JBoss, otro) y conteniendo el WAR.

• Por cada Aplicación Web: Un contenedor, eligiendo com imagen base del contenedor la del servidor seleccionado en el assessment (Nginx, Apache...) y conteniendo la aplicación web.

• Por cada Balanceador: Un contenedor, eligiendo como imagen base del contenedor la del balanceador seleccionado en el assessment. En caso de NGINX se puede cargar un nginx.conf (lo vemos cuando lo hagamos).

• Por cada Proceso Java u otro proceso: Un contenedor eligiendo como imagen base del contenedor la de la tecnologia a la que pertenezca el proceso Java, Node...

En principio Bases de datos y software de integración no se contenerizan en este paso, ya que en el paso posterior (aplantillado Helm) se utilizarán imágenes oficiales de cada fabricante para crear los Workloads correspondientes a dichos módulos. No obstante el arquitecto que revise la contenerización puede decidir añadir esto módulos para contenerizarlos.

Una vez editado el diagrama se generan las imágenes correspondientes. Para ello a través del Center se pueden realizar 2 acciones:

• Generar la estructura de Dockerfiles de los contenedores, que permitirá su edición para una construcción:

  • Edición de Dockerfiles desde el propioCenter.

  • Almacenamiento de Dockerfiles en el gitlab del proyecto.

  • Un mismo proyecto puede tener diferentes Diagramas de contenerización, por lo que existe versionado de las contenerizaciones.

• Generar y Publicar imágenes en un registro.

  • Registro general preconfigurado o configurable proporcionando credenciales.

  • A cada imagen se le asocia un identificador que se registra internamente en el Center.

  • Registro de las versiones generadas.

Fase de preparación para despliegue en Kubernetes

Tras el Assessment y la contenerización el Onesait Platform center dispone de información clave para generar un despliegue aproximado sobre Kubernetes. Esta información comprende:

• Lista de elementos software que constituyen la aplicación

• Relaciones entre ellos.

• Imágenes contenerizadas tanto de la aplicación como del software base

Con esta información se construye un Chart Helm, de nuevo editable por arquitecto para que modifique o añada lo que considere necesario, para llevar la contenerización a un entorno Cloud.

Desde el Onesait Platform Center se puede solicitar la construcción de un Chart Helm asociado a una contenerización (Diagrama de contenerización), de manera que pueda identificar:

• Lista de imágenes y url en el que están publicadas.

• Versiones de imágenes: A elegir entre las generadas en las diferentes generaciones que se hayan llevado a cabo para el diagrama

• Resto de información del Assessment. Intrinseco al proyecto al ser un proyecto de migración al cloud.

Las consideraciones para generar el Chart Helm son las siguientes:

• Un Namespace para el proyecto

• Un Registry Credentials asociado al namespace para el registro del que descargar las imágenes generadas en la contenerización.

• Por cada contenedor.

  • Un Deployment

  • Un Service

  • Un config-map

•  Por cada Base de datos

  • Un Deployment

  • Un Service

  • Un PV+PVC asociado al Deploymen

• Un secret por cada Deployment que acceda a Base de datos

• Por cada balaneador un Ingress con una regla Ingress al servicio del deployment correspondiente por cada redirección registrada

• Un PV+PVC asociado a todos los deployments (generico para el almacenamiento persitente que puedan tener).

• Fichero values.yaml por defecto del chart con todos los valores configurados en el assessment y la contenerización.

A partir del Diagrama generado y revisado por un arquitecto de la aplicación, es posible generar el Chart Helm con todos los descriptores que permitan desplegar la aplicación en un entorno Kubernetes. Para ello:

• Se genera el Chart y se almacena en el Gitlab del proyecto.

• Un proyecto puede definir diferentes Charts y versionarlos en el Gitlab del proyecto para que el usuario pueda desplegar el mas adecuado.

Fase de despliegue en entorno Cloud

El Onesait Platform Center permite gestionar los entornos de despliegue de una aplicación o proyecto, para ello los tiene registrados y se integra con la plataforma de gestión de contenedores de cada entorno.

Para desplegar una aplicación migrada al cloud mediante este procedimiento, se selecciona el entorno y el diagrama que se corresponde con el Chart a desplegar:

Se ajustan las variables del Chart específicas del entorno donde se va a desplegar:

Se aplica el Chart sobre el entorno:

Al aplicar el chart sobre un entorno, las variables customizadas para dicho entorno se versionan en la aplicación y en Gitlab para futuras actualizaciones