OpenShift v3
Introducción
OpenShift v3 incorpora muchos cambios en su arquitectura e introduce nuevos conceptos y componentes. Está construido para ejecutar las aplicaciones en contenedores Docker, soportando programación y gestión provistos por el proyecto Kubernetes, y añadiendo una capa de funcionalidades de despliegue, orquestación y enrutamiento.
Los cambios más significativos giran entorno al modelo de contenedores y cómo son monitorizados e interconectados. Kubernetes pods son un grupo de contenedores que actuan como una única Máquina Virtual: tienen una IP única, pueden compartir un sistema de ficheros y, normalment, tienen parámetros de seguridad idénticos. Agrupar contendores incrementa de manera exponencial el número de aplicaciones que pueden incorporarse a OpenShift. En lugar de enfocarse en un modelo de microservicios que excluya al resto de patrones, los pods permiten a los desarrolladores migrar las aplicaciones existentes que necesitan compartir recursos locales mientras se benefician de este modelo en contenedores.
En segundo lugar, se espera que los contenedores de OpenShift sean inmutables: la imagen contiene un snapshot en concreto del código de la aplicación junto con las librerias necesarias, mientras que cualquier otra configuración, claves o datos persistentes son acoplados al contenedor en tiempo de ejecución. Esto permite a los administradores, y a los integradores, seoarar el código y los parches de las configuraciones y los datos. Aunque sigue siendo posible modificar los contenedores, mantener los conceptos de alto nivel de constucción y despliegue de contenedores inmutables ofrece garantías de qué código se está ejecutando y dónde.
El tercer cambio importante está en el diseño del núcleo del sistema: OpenShift y Kubernetes se construyen como un conjunto de microservicios que trabajan al unísono mediante un REST APIs para modificar el sistema. Esos APIs estñan disponbles para integradores de sistemes, y esos mismos componentes del núcleo se pueden deshabilitar para permitir implementaciones diferentes. Un claro ejemplo es el API watch: un cliente se puede conectar y recibir información de los cambios en los pods (u otros objetos) y realizar alguna acción cuando el pod esté disponible (para localizar errores o cambios en los registros del sistema). OpenShift establece un control de acceso preciso sobre su REST APIs para permitir esta integración, lo que quiere decir que no habrá cambios que realice el sistema que no pueda hacerlos un integrador.
Extraído de la documentación oficial de OpenShift
Continue reading →
