Openshift es la “Plataforma como servicio” (PAAS en inglés) de Red Hat. El concepto de PaaS lo que intenta es abstraer a los desarrolladores de todo lo relacionado con la infraestructura, la forma en que lo hace OpenShift a groso modo es la siguiente:

Soy un desarrollador y quiero desplegar una aplicación, supongamos para el ejemplo un blog con WordPress, primero elijo el tamaño que quiero que tenga mi aplicación, en términos de RAM y de espacio en disco, le pongo un nombre, a continuación añado mediante “cartuchos” las tecnologías a usar, en este caso PHP y MySQL, al añadir los cartuchos obtengo los datos de conexión necesarios para poder desplegar mi código o mi base de datos, si en algún momento mi aplicación necesita más recursos, puedo activar el autoescalado y ni siquiera preocuparme de morir de éxito.

Antes de pasar a la parte más técnica, quiero enumerar algunas ventajas/características que tiene OpenShift:

  • Tiene versión Online y versión para desplegar internamente en nuestra infraestructura, llamada OpenShift Enterprise.
  • La versión online se puede usar gratuitamente, aunque con limitaciones: Sólo 3 aplicaciones, el tamaño de estas es del tipo pequeño, no tiene soporte, etcétera.
  • La versión interna se puede desplegar en cualquier infraestructura virtual, ya sea RHEV, VMWare, OpenNebula, OpenStack… Evidentemente si se mantiene un ecosistema Red Hat, usando RHEV u OpenStack, tienes documentos de referencia y más articulos en la Knowledge Base 
  • La versión interna dispone a su vez de una versión comunidad, Origin 
  • Hay una gran comunidad de usuarios detrás, por lo que es fácil encontrar bastantes ejemplos de como desplegar aplicaciones, y no sólo ejemplos, sino guias rápidas con las que poder desplegar aplicaciones con sólo 2 clicks.
  • Es agnóstico al lenguaje de programación, hay cartuchos de python, php, perl, ruby, java e incluso .net
  • Hay bastante documentación:

¿Cómo funciona técnicamente OpenShift Online?

  1. Te creas una cuenta, que como ya he dicho hay una versión gratuita que permite hasta 3 aplicaciones.
  2. Creas la aplicación mediante la consola web , usando Eclipse , o la línea de comandos 
  3. A la hora de crear la aplicación eliges el tamaño de “Gear” hay 3 tamaños ya predefinidos, todos con 1 GB de espacio en disco inicial, y con 512MBs de RAM (Pequeño), 1GB de RAM (Mediano) y 2GB de RAM (Grande)
  4. En la aplicación recién creada, agregamos los cartuchos necesarios 
  5. Al agregar los cartuchos creamos a su vez repositorios privados de git dónde poder aplicar cambios con comandos git estandares.
  6. Una vez subido el codigo, OpenShift usa herramientas como Maven, Jenkins o Apache para completar el despliegue.
  7. En caso de activar el auto escalado, OpenShift inserta un HA-Proxy delante de la aplicación para monitorizarla y escalar en caso de que sea necesario.

¿Cómo funciona técnicamente OpenShift Enterprise/Origin?

Básicamente se compone de 2 elementos principales:

  1. Los “Broker” que son el punto de contacto para todas las actividades de gestión de una aplicación. Logins, DNS, monitorización de la aplicación, etcétera. Los usuarios no acceden directamente al broker sino que interactúan con él gracias a la API basada en REST, ya sea mediante la consola web, el cliente de línea de comandos o un IDE. El broker usa MCollective para los sistemas donde realmente residen las aplicaciones, los “Nodos”.
  2. Los Nodos albergan los cartuchos preconstruidos asi como las aplicaciones de los usuarios contenidas en “Gears”. En cada Nodo hay un cliente MCollective encargado de recibir y ejecutar las peticiones del Broker.

La comunicación entre los clientes MCollective de los Nodos y el Broker se hace usando un servicio de cola de mensajes. Tanto Enterprise como Origin usar ActiveMQ inicialmente, pero cualquier otro sistema compatible con AMQP como RabbitMQ debe funcionar.

Las topologías a poder usar son multiples, por ejemplo:

  • Todos los componentes en un solo sistema.
  • Un sistema con un broker y ActiveMQ y multiples sistemas Nodo.
  • Varios brokers balanceados, un sistema dedicado en exclusiva para ActiveMQ, con varios servidores MongoDB replicados y múltiples sistemas Nodo.

Como hemos dicho antes, los Gears, representan las porciones de CPU, memoria RAM y espacio en disco que están disponibles para una determinada aplicación. Una aplicación nunca puede sobrepasar el uso de estos recursos, a excepción del espacio en disco cuya cuota es ampliable por el administrador. Las tecnologías en las que se basa OpenShift para aislar los Gears y para controlar sus cuotas son SELinux y cgroups

Esto último cambiará próximamente puesto que OpenShift va a empezar a adoptar Docker , el problema de Docker, es que tiene algunos aspectos no muy pulidos:

  • ¿ Cual es la mejor manera de desplegar una aplicación en un contenedor recién creado?
  • ¿ Cómo conectar un montón de contenedores para formar una sola aplicación?
  • ¿ Cómo hacer desde el punto de vista de red que estos contenedores aparezcan como una simple aplicación al mundo exterior?
  • ¿ Cuando despliego un contenedor, he instalado todo lo necesario?

Aquí es donde GearD llega al rescate, e inicialmente se centrará en:

  • Convertir fuentes de aplicaciones en imagenes de Docker
  • Proveer conexiones elásticas entre varios contenedores
  • Facilitar los despliegues

De hecho, como ya he comentado en mi anterior post hay un nuevo proyecto llamado Project Atomic, que combina Docker, GearD y cockpit, así que no me extrañaría que pudiera usarse para desplegar “Nodos”

Últimamente hay mucho ruido alrededor de un nuevo proyecto open source llamado Docker  asi que voy a intentar tratar de aportar mi granito de arena.

Empecemos por la descripción de Docker: “Un proyecto open source para empaquetar, distribuir y ejecutar cualquier aplicación como un contenedor ligero”. Muy bonito, pero ¿Que es un contenedor?

Un contenedor es una forma ligera de virtualizar de forma que los recursos que ya se están ejecutando en la maquina host son compartidos con los contenedores, por ejemplo los contenedores no necesitan ejecutar su propia instancia del kernel, lo que permite una carga mucho menor, así como un arranque muy rápido y una gestión simplificada de los mismos. Es decir sería algo parecido a chroot con esteroides, en el sentido de que no sólo se usa para aislar una sola aplicación.

La tecnología de contenedores es conocida desde hace mucho tiempo y existen varias, cómo lxc , openvz , FreeBSD Jails o Solaris Containers .

Entonces ¿Que aporta Docker?. Pues como su descripción indica, Docker aporta las herramientas para tratar a los contenedores como si fueran repositorios de código, es decir, combinar paquetería y código todo en uno, de forma que se puedan desplegar, clonar, hacer vuelta atrás de versiones, etcétera con un simple comando.

Otra forma de desplegar contenedores que permite docker es mediante los Dockerfile, que son recetas en las que especificas el contenedor base y todos los cambios que quieres aplicar en un solo fichero.

La tecnología Docker es reciente y por eso, y tal como dicen en su web, “Aún no está preparado para produción”, no obstante tiene mucha tracción, por ejemplo Amazón ha anunciado recientemente su soporte  

Red Hat ha anunciado el “Project Atomic” que además de Docker, usa systemd , GearD y cockpit para crear una versión de RHEL especialmente destinada a usarse como “hypervisor” de contenedores.

Red Hat también ha anunciado que ha incluido Docker en su programa de High Touch Beta de forma que los clientes que participen en este programa puedan probarlo y reportar feedback, y se espera que este incluido en RHEL 7, aunque no en las primeras versiones.

Si quereis probar Docker, recomiendo hacer el tutorial interactivo de Docker.