Se trata de un demostrador en el que se realiza la migración a Cloud sobre kubernetes, 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
...
It is a demonstrator in which the migration of a legacy application deployed in a traditional way, to the Cloud, over Kubernetes, is carried out, .
For it:
We create a project in the Center
In this step, the project is created and its configuration is assigned, including:
Administrative information and users associated with the project.
...
DevOps configuration (Gitlab, Jenkins, …).
...
Entornos Kubernetes donde se desplegará la solución en cloudKubernetes environments where the cloud solution will be deployed.
...
...
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 es, la identificación de todos los elementos lógicos de la aplicación y su configuración de despliegue en un entorno tipo.
Para ello mediante un formulario ( aunque en el futuro tenemos pensadas alternativas mas automáticas) se identifican:
Frontales Web de la aplicación
Módulos de Backend (Servidores JEE, Microservicios Spring Boot…)
Bases de datos.
Procesos batch.
Middleware de integración (Apis Manager, ESBs, Brokers de 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 kubernetes.
Para ello, por cada elemento identificado se crea un contenedor sobre un diagrama editable:
...
El resultado de la contenerización se plama en los correspondientes descriptores Dockerfile sobre el Gitlab del proyecto así como en la publicación en un registro de las imagenes de los diferentes contenedores:
...
Aplantillamos la aplicación con Helm
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 kubernetes.
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 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 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 del proyecto:
...
Despliegamos en Kubernetes
Un Diagrama Helm tambien pude instalarse en 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 la aplicación en el entorno kubernetes seleccionado:
...
Video
...
We carry out the Assessment of the legacy application
Once the project has been created, the next step is to identify the elements that make up the legacy application to migrate to the cloud. For this, an Assessment is carried out, that is, the identification of all the logical elements of the application and its deployment configuration in a typical environment.
To do this, using a form (although in the future we plan to have more automatic alternatives), the following are identified:
Application web frontends.
Backend Modules (JEE Servers, Spring Boot Microservices, …)
Databases.
Batch processes.
Integration middleware (API Managers, ESBs, messaging brokers, …)
Balancers.
...
Alternatively to the form and in a bidirectional way, this information is reflected in an editable Assessment Diagram, organized by layers:
...
We containerize the application
Once the Assessment is complete, the next step towards the cloud is to convert the logical elements identified in the application into deployable containers as Kubernetes workloads.
To do this, for each identified element, a container is created on an editable diagram:
...
The result of the containerization is reflected in the corresponding Dockerfile descriptors on the GitLab of the project, as well as in the publication in a registry of the images of the different containers:
...
We template the application with Helm
With the containerization finished, and the relationships between logical components defined in the assessment, the Center already has an image to infer a deployment proposal on Kubernetes.
In the next step, this information is used to automatically generate a Helm Chart, that is, a graphical representation of all the application's Helm descriptors. For this, the following is created automatically:
A Namespace for the application.
A Deployment and a Service for each container.
A Config-map with the configuration of each containerized Database.
A Secret with the credentials of each containerized Database.
A PV and a PVC for each Database, to provide persistent storage.
A PV and a general PVC for the rest of Deployments that are not Databases.
An Ingress with balancing rules towards the Services, that have balancing rules in the Assessment.
...
Like the rest of the elements generated by the Center, this diagram is editable for the architect to refine or modify any element.
A Helm diagram represents a graphical abstraction of a Helm Chart, so that an architect without very deep Helm knowledge can build the Charts from it. But a Helm diagram ends up being materialized into a Helm Chart, with the YAML descriptors and configuration externalized in a values.yaml file. These charts can be downloaded or versioned in the project’s GitLab:
...
We deploy in Kubernetes
A Helm chart can also be installed in Kubernetes on top of one of the project environments. To do this, when selecting the diagram, we can choose “Display Chart Helm”.
...
Since the configuration has been externalized, certain variables can be overwritten for the environment:
...
The installation ends showing the Helm log:
...
with the application being deployed in the selected Kubernetes environment:
...
Video
The entire process can be seen in the following video, where you can also see how the application is deployed on the kubernetes environment managed by Rancher:
...