Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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.

se realiza un ejercicio de contenerización automática por el Center. En este proceso, Para ello, por cada elemento lógico identificado en el Assessment se considera como un contenedro, en la que el arquitecto puede intervenir para refinar ciertos detallles. Todo ello mediante un Diagrama de contenerización cuyo resultado se plasma en 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 y opcionalmente mediante la construcción de los contenedores y publicación de sus imágenes en un registro.así como en la publicación en un registro de las imagenes de los diferentes contenedores:

...

Helm Chart

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:

...

O instalarse directamente en kubernetes sobre uno de los entornos del proyecto.

...

Al haberse externalizado la configuración, se pueden sobrescribir determinadas variables para el entorno:

...

La instalación finaliza mostrando el log

  • en un Chart desplegable, que se puede descargar, versionar en Gitlab o desplegar en cualquiera de los entornos kubernetes configurados para el proyecto. En esto consiste el último paso de la demo, en el despliegue en un entorno kubernetes del chart generado desde el diagrama propuesto por el center.

  • Realizado el despliegue se puede observar

...