¡Hola a todo el mundo! Hoy nos gustaría hablaros de lo que en Essi Projects conocemos como el poder de la contenerización: cómo una arquitectura de contenedores para aplicaciones basadas en microservicios puede ayudarnos a maximizar la productividad. Implementando el uso de Red Hat OpenShift Container Platform capacitamos a administradores y desarrolladores con todas las herramientas necesarias para facilitar la gestión y mantenimiento de aplicaciones.
Ya hemos hablado en otras ocasiones de Red Hat OpenShift Container Platform, del necesario equilibrio entre hardware y aplicación (puedes leer el post aquí). Pero en el post de hoy, te contamos qué son las aplicaciones monolíticas, los beneficios de los contenedores en aplicaciones orientadas a microservicios y de cómo Red Hat OpenShift Container Platform tiene un papel protagonista en todo el proceso.
¡Sigue leyendo!
Aplicaciones monolíticas
Cuando hablamos de aplicaciones modernas, nos referimos a un conjunto de componentes que interactúan entre sí. Generalmente, estos componentes se encuentran fuertemente acoplados en lo que se conoce como «aplicación monolítica”. La aplicación monolítica tiene la desventaja de que si falla uno de los componentes de la aplicación, se dificultan las tareas de depuración y de corrección del fallo. Pero no sólo se presenta este inconveniente, sino que también una aplicación monolítica se caracteriza por una fuerte dependencia con librerías y ficheros de configuración del sistema operativo, los cuales deben ser los adecuados para poder ejecutarse correctamente.
Aquí ya podemos percibir uno de los principales problemas de las aplicaciones monolíticas: la falta de modularidad dificulta, en gran medida, la substitución de un componente de la aplicación por otro. Al mismo tiempo, la actualización de librerías para una aplicación puede representar un problema de compatibilidad o interrupción de servicio para otras aplicaciones.
Aplicaciones monolíticas en la práctica
Imaginemos por un momento una aplicación web cuyos componentes sean un servidor web, una aplicación «backend» que realice diversas operaciones y una base de datos para almacenar estos datos para su futura recuperación. Tradicionalmente, estos componentes se encuentran todos instalados en una misma máquina (ya sea una máquina física o máquina virtual), con lo cual tendríamos una fuerte dependencia de estos componentes. Es decir, si en el peor de los casos la máquina fallara, entonces dejaría de dar servicio tanto el servidor web, la base de datos y por supuesto, la aplicación backend.
Entonces… ¿Cómo conseguimos que nuestra aplicación siga siendo accesible y dando servicio a pesar de una caída del sistema? ¿De qué manera actualizamos nuestra aplicación y sus dependencias sin ocasionar problemas al resto de aplicaciones? ¿Qué debemos hacer para aumentar la capacidad de respuesta de nuestra aplicación y con ello, la productividad?
La Clave es una arquitectura orientada a microservicios
La respuesta a todas estas preguntas la encontraremos en una arquitectura orientada a microservicios.
¿Y cómo conseguimos una arquitectura orientada en microservicios? Muy fácil: ¡con contenedores para aplicaciones basadas en microservicios!
Evolución del modelo tradicional a modelo de contenerización
Contenedores para aplicaciones basadas en microservicios
Los contenedores nos aportan todas las características necesarias para implementar aplicaciones orientadas a microservicios. Por ejemplo:
– Aislamiento (sistema de ficheros, red y acceso a recursos exclusivos)
– Menor uso de recursos hardware comparado al modelo tradicional de aislamiento de procesos en máquinas virtuales
– Inicio y finalización muy rápidos, ya que consumen pocos recursos y evitamos la inicialización de un SO completo como en el caso de máquinas virtuales
– Menor riesgo de interrupción de servicio de otras aplicaciones al actualizar librerías
– Mayor seguridad gracias al aislamiento de procesos
– Mayor facilidad de portabilidad de la aplicación entre diferentes entornos
desacoplar aplicaciones monolíticas
De esta manera, gracias a los contenedores podremos desacoplar una aplicación monolítica en diferentes componentes, cada uno de ellos en un contenedor diferente y que se comuniquen entre sí.
Y aquí es donde se ponen interesantes las cosas… Si lo que queremos conseguir es una mayor resiliencia y disponibilidad de nuestra aplicación (a la vez que aumentamos el número de peticiones que ésta pueda atender), tendremos que encontrar alguna manera de ejecutar múltiples instancias en paralelo de nuestra aplicación. Preferiblemente distribuidas en diferentes máquinas o «nodos» que conformarían un clúster.
Pero gestionar un número elevado de contenedores se puede convertir en una difícil tarea, por lo que necesitaremos lo que se conoce como un orquestador, es decir, una plataforma que simplifique el despliegue, la gestión y el escalado de aplicaciones contenerizadas.
Aquí es donde entra en escena Red Hat OpenShift Container Platform.
Algunos conceptos sobre red hat openshift container platform
Red Hat OpenShift Container Platform (OCP) es un orquestador de aplicaciones contenerizadas basado en Kubernetes. Es la herramienta perfecta para construir una arquitectura de contenedores para aplicaciones basadas en microservicios. De Kubernetes hereda algunas características a la vez que extiende otras:
– Alta disponibilidad que se obtiene gracias a «Etcd«, una base de datos distribuida que guarda el estado del clúster OCP, con lo que se asegura en todo momento el estado de ejecución de las aplicaciones.
– Basado en CoreOS, un sistema operativo ligero optimizado para ejecutar contenedores que proporciona agilidad, portabilidad, y seguridad.
– Balanceo de carga, que además de permitir un mayor volumen de peticiones, proporciona acceso a las aplicaciones desde el exterior del clúster OpenShift Container Platform.
– Automatización de escalado de aplicaciones bajo demanda, para una adaptación a un mayor o menor volumen de peticiones.
– Logging y monitorización.
– Abstracción de almacenamiento. Es decir, los contenedores consumen espacio de almacenamiento sin necesidad de conocer detalles del almacenamiento subyacente.
– Auto-aprovisionamiento de recursos del clúster OpenShift Container Platform, que facilita a los desarrolladores el desarrollo y despliegue de sus aplicaciones.
– Extensibilidad del clúster OpenShift Container Platform gracias a extensiones conocidas como «Operators».
Visión general de arquitectura de OpenShift Container Platform
¿Cómo se estructura un clúster OpenShift?
Para conocer la arquitectura de un clúster OpenShift, lo haremos mediante la definición de sus componentes, tanto máquinas (nodos) y recursos (definidos en JSON o YAML)
Nodos
Master: es una máquina servidor que controla el «Plano de Control» del clúster. Controla el estado del clúster almacenado en la base de datos «Etcd» y provee servicios básicos como una API para interactuar con el clúster (a través de un CLI o consola web).
Worker: es una máquina que básicamente se encarga de ejecutar cargas de trabajo. Es decir, son máquinas que simplemente ejecutarán contenedores.
Recursos
Pod: Es una forma de encapsular uno o varios contenedores y se conoce como la unidad mínima de trabajo en un clúster Kubernetes y por lo tanto en un clúster OpenShift.
Controlador: Es un proceso que «vigila» y mantiene el clúster para que permanezca en un estado en concreto. Un ejemplo es el llamado «Controlador de Replicación», que es el encargado de mantener constante el número de réplicas de Pods distribuidos en el clúster.
Servicio: Se usa para acceder a los Pods, de manera que si tenemos múltiples réplicas de un mismo Pod, podremos acceder a uno de ellos a través del servicio con una política de acceso round-robin.
Volumen persistente (o PV): Define un almacenamiento persistente, ya que dada la naturaleza efímera de los contenedores, todos los cambios se pierden al terminar la ejecución de los Pods. De esta manera los Pods pueden montar un sistema de ficheros en red y almacenar los cambios de forma persistente.
Reclamo de volumen persistente (o PVC): Representa una solicitud de almacenamiento persistente por parte de un Pod. Es la manera de vincular un almacenamiento persistente (PV) con un Pod.
Secretos y ConfigMaps: Sirven de almacén de datos (codificados o no) centralizada, es decir, una colección de pares de claves-valor que pueden ser utilizados por otros recursos del clúster.
DeploymentConfig (DC): Representa un conjunto de contenedores que componen un Pod, y también la estrategia de despliegue a ser utilizada.
BuildConfig (BC): Permite automatizar la construcción de una imagen de contenedor desde un repositorio Git gracias al proceso conocido como «Source to Image» (S2I).
Ruta: Representa un nombre DNS reconocido por el router del clúster OpenShift y sirve como punto de entrada para acceder a los Pods que ejecutan las aplicaciones desde el exterior del clúster OpenShift.
¿Cómo se intercomunican los componentes de una aplicación?
Bien, ya tenemos claro muchos conceptos sobre contenedores para aplicaciones basadas en una arquitectura orientada a microservicios, y ya nos hemos hecho la idea de cómo dividir los diferentes componentes de nuestra aplicación. Y ahora surge la típica pregunta: ¿Cómo se comunican los diferentes componentes de nuestra aplicación (Pods) entre ellos?
La respuesta es, gracias a una red definida por software o SDN («Software Defined Network»). Este tipo de red permite la comunicación tanto de componentes propios de la infraestructura del clúster Red Hat OpenShift, como también entre aplicaciones (Pods). Además, abstrae toda la comunicación desde el cliente que realiza una petición y la aplicación que responde a dicha petición.
En pocas palabras, si quisiéramos acceder a nuestra aplicación que se ejecuta en un clúster OpenShift, simplemente tendremos que «exponer» una ruta y la red SDN se encargará de realizar el enrutamiento necesario hacia la aplicación, todo de forma transparente.
Una arquitectura orientada a microservicios
Últimamente y con más frecuencia, nos veremos en la necesidad de diseñar aplicaciones basadas en una arquitectura orientada a microservicios dadas todas las ventajas que nos aporta: alta disponibilidad mediante el escalado de aplicaciones, reducción de impacto al resto de aplicaciones debido a una actualización, exprimir al máximo los recursos hardware comparando a otros modelos tradicionales de virtualización, etc.
Red Hat OpenShift Container Platform también facilita la ejecución de una aplicación desde su código fuente, con todo el proceso automatizado desde su construcción, pasando por el despliegue y la ejecución distribuida en el clúster, y finalmente el escalado en función de la demanda de recursos por parte de la aplicación, todo de forma transparente al administrador.
En resumen, si pensamos en maximización de productividad, entonces pensaremos en Red Hat OpenShift Container Platfom como la solución que mejor se ajustará a nuestras necesidades.
¿Quieres saber más sobre esta tecnología?
Essi Projects, Red Hat Premier Partner en España, está certificado como Red Hat Container Platform Specialist, lo que nos acredita como expertos en Red Hat OpenShift Container Platform y partner de referencia en España.
Si quieres saber un poco más sobre esta tecnología, ¡no lo dudes!
¡Cuéntanos cómo podemos ayudarte!
Además, si tienes alguna otra duda, será un placer ayudarte. Puedes ponerte en contacto con nosotros a través del Formulario de Contacto o enviando un correo a info@essiprojects.com
Essi Projects
Comparte la noticia
