Center Demostrator - Cloud Migration

Owned by Onesait Platform
Last updated: 07/03/23
4 min read

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, …).

 

  • Kubernetes environments where the cloud solution will be deployed.

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: