Se trata de un demostrador en el que se realiza la migración a Cloud sobre kubernetesKubernetes, de una aplicación legacy desplegada de forma tradicional.
Para ello:
Creamos un proyecto en el Center
...
En este paso, se crea el proyecto y se le asigna su configuración, incluyendo:
Información administrativa y usuarios asociados al proyecto
...
Configuración devops DevOps (Gitlab, Jenkins…Jenkins, …).
...
Entornos Kubernetes donde se desplegará la solución en cloud.
...
Una vez creado el proyecto, el siguiente paso es identificar los elementos que componen la aplicación legacy a migrar a cloud. Para ello se realiza un Assessment. Esto , esto es, la identificación de todos los elementos lógicos de la aplicación y su configuración de despliegue en un entorno tipo.
...
Frontales Web de la aplicación.
Módulos de Backend (Servidores JEE, Microservicios Spring Boot…Boot, …)
Bases de datos.
Procesos batch.
Middleware de integración (Apis ManagerAPI Managers, ESBs, Brokers de mensajeria…mensajeria, …)
Balanceadores.
...
Alternativamente al formulario y de manera bidireccional, esta información se plasma en un Diagrama de Assessment editable, organizado por capas:
...
Contenerizamos la aplicación
...
Finalizado el Assessment, el siguiente paso hacia el cloud, es convertir los elementos lógicos identificados en la aplicación en contenedores desplegables como cargas de trabajo kubernetesKubernetes.
Para ello, por cada elemento identificado se crea un contenedor sobre un diagrama editable:
...
El resultado de la contenerización se plama plasma en los correspondientes descriptores Dockerfile sobre el Gitlab GitLab del proyecto, así como en la publicación en un registro de las imagenes imágenes de los diferentes contenedores:
...
Con la contenerización finalizada, y las relaciones entre componentes lógicos definidas en el assessment, el Center ya dispone de una imagen para inferir una propuesta de despliegue sobre kubernetesKubernetes.
El En el siguiente paso, esta información es utilizada para generar de forma automática un Diagrama Helm, esto es, una representación gráfica de todos los descriptores Helm de la aplicación. Para ello se crea de forma automática:
Un Namespace para la aplicación.
Un Deployment y un Service por cada contenedor.
Un Config-map con la configuración de cada Base de datos contenerizada.
Un Secret con las credenciales de cada Base de datos contenerizada.
Un PV y un PVC por cada Base de datos, para proporcionar almacenamiento persistente.
Un PV y un PVC general para el resto de Deployments que no sean Base de datos.
Un Ingress con reglas de balanceo hacia los Service que tuvieran reglas de balanceo en en Assessment.
...
Como en el resto de elementos generados por el Center, este diagrama es editable para que el arquitecto refine o modifique cualquier elemento.
Un diagrama Helm respresenta representa una abstracción gráfica de un Chart Helm, de manera que un arquitecto sin conocimientos muy profundos de Helm pueda construir sus Charts. Pero un diagrama Helm se termina manerializando materializando en un Chart Helm, con los descriptores YAML y la configuración externalizada en un fichero values.yaml. Estos chart pueden descargarse o versionarse en el gitlab GitLab del proyecto:
...
Despliegamos en Kubernetes
Un Diagrama Helm tambien también pude instalarse en kubernetes Kubernetes sobre uno de los entornos del proyecto. Para ello, seleccionando el diagrama podemos elegir “Desplegar Chart Helm”.
...
Al haberse externalizado la configuración, se pueden sobrescribir determinadas variables para el entorno:
...
La instalación finaliza mostrando el log de Helm:
...
Quedando despledada quedando desplegada la aplicación en el entorno kubernetes Kubernetes seleccionado:
...
...
Vídeo
Todo el proceso se puede apreciar en el siguiente video, donde tambien también se muestra en vivio como cómo se despliega la aplicación sobre el entorno kubernetes Kubernetes gestionado mediante Rancher:
...