Base tecnológica de Onesait Platform

Contenerización ¿Por qué contenedores?

La onesait Platform está basada en una arquitectura de microservicios escritos en Java usando el framework Spring Boot, cada uno de estos módulos o microservicios se ejecuta dentro de un contenedor Docker. Existen numerosas razones por las cuales se ha elegido esta manera de empaquetar y ejecutar estos microservicios con Docker, entre ellas cabe destacar las siguientes.

Open

Retorno de la inversión y ahorro de costes

La primera ventaja de usar contenedores es el ROI.

Cuando más se pueden reducir los costes de una solución más aumentan los beneficios y mejor es la solución.

En este sentido los contenedores ayudan a facilitar este tipo de ahorro al reducir los recursos de infraestructura, ya que se necesitan menos recursos para ejecutar la misma aplicación.

Estandarización y productividad

Los contenedores garantizan la coherencia en múltiples entornos, ciclos de liberación. Una de las mayores ventajas de la contenerización es la estandarización, ya que se proporcionan entornos replicables de desarrollo, construcción, prueba y producción. La estandarización de la infraestructura de servicio en todo el proceso permite que cada miembro del equipo trabaje en un entorno idéntico al de un entorno productivo. Como consecuencia de esto, los ingenieros están más equipados para analizar y corregir errores de manera ágil y eficiente. Esto reduce los tiempos de corrección de bugs y el time-to-market.

Los contenedores permiten realizar cambios en las imágenes y controlar la versión de estos. Por ejemplo, si al realizar una actualización de un componente se comprueban anomalías en el funcionamiento de todo un entorno, es muy fácil hacer rollback y volver a una versión anterior de su imagen. Todo este proceso puede probarse en unos minutos.

Portabilidad, compatibilidad e independencia del sistema operativo subyacente

Uno de las principales ventajas es la paridad, en términos de contenedores significa que las imágenes se ejecutan igual sin importar en qué servidor o en qué computadora portátil se ejecutan o en que sistema operativo se ejecutan ya sea Windows , Linux o MacOS.

Open

Para los desarrolladores, esto significa menos tiempo dedicado a configurar entornos, depurar problemas específicos del entorno y una base de código más portátil y fácil de configurar. La paridad también significa que la infraestructura de producción será más confiable y más fácil de mantener.

Simplicidad y configuraciones más rápidas

Uno de los beneficios clave de los contenedores es la forma en que simplifica las cosas. Los usuarios pueden tener su propia configuración, ponerla en el código y desplegarla sin ningún problema. Como se puede utilizar en una amplia variedad de entornos, los requisitos de la infraestructura ya no están vinculados con el entorno de la aplicación.

Agilidad en los despliegues

Los contenedores logran reducir el tiempo de despliegue. Esto se debe al hecho de que se crea un contenedor para cada proceso y no arranca un sistema operativo.

Una de las ventajas más importantes de los contenedores frente a los Hypervisores es que no se replica un sistema operativo completo, sino lo mínimo e imprescindible para que la aplicación que se quiera contenerizar funcione correctamente y las imágenes sean mucho más ligeras y fáciles de mover entre entornos. Además, los contenedores no reservan en exclusiva los recursos del sistema operativo (memoria, cpu) sino que los comparten con otros contenedores en ejecución.

Despliegue continuo y pruebas

Los contenedores garantizan entornos consistentes desde el desarrollo hasta la producción. Los contenedores están preparados para mantener todas las configuraciones y dependencias internamente. Por lo tanto, es posible usar la misma imagen desde el entorno de desarrollo hasta el de producción, asegurándose de que no haya discrepancias ni intervención manual.

Plataformas multi-nube

Este es posiblemente uno de los mayores beneficios de los contenedores. En los últimos años, todos los principales proveedores de computación en nube, incluidos Amazon Web Services (AWS) y Google Compute Platform (GCP), han adoptado la disponibilidad de Docker y han agregado soporte individual. Los contenedores acoplables se pueden ejecutar dentro de una instancia de Amazon EC2, instancia de Google Compute Engine, servidor de Rackspace o VirtualBox, siempre que el sistema operativo host sea compatible con Docker. Si este es el caso, un contenedor que se ejecuta en una instancia de Amazon EC2 se puede portar fácilmente entre entornos.

Además, Docker funciona muy bien con otros proveedores como Microsoft Azure y OpenStack, y se puede usar con varios administradores de configuración como Chef, Puppet y Ansible, etc.

Aislamiento y Seguridad

En un sistema en el que se produzca un mal funcionamiento de un contenedor no implica que el sistema completo en el que se ejecute deje de responder o presente anomalías de funcionamiento, es decir, se garantiza que las aplicaciones que se ejecutan en contenedores estén completamente segregadas y aisladas entre sí, lo que le otorga un control total sobre el flujo y la administración del sistema operativo. Ningún contenedor puede ver los procesos que se ejecutan dentro de otro contenedor.

Contenerización ¿Por qué Docker?

La tecnología de contenerización no es nueva. Ya Oracle la implementó en Solaris a comienzos del 2000, como medida de aislamiento de recursos y portabilidad de aplicaciones. Sin embargo esta tecnología no maduró hasta la llegada de Linux Containers o abreviado a LxC, con el uso de cgroups y namespaces de Linux, ya incorporado al Kernel de manera nativa.

Más adelante llegó CloudFoundry con su propia implementación de LxC llamada Warden, CoreOS con Rocket (rkt) y la comunidad con Docker, todas ellas usan tanto cgroups como namespaces para limitar y asignar recursos del sistema operativo, sin embargo Docker implementa una capa más de abstracción con su propia librería: libcontainer.

La elección de Docker frente al resto es sencilla:

• Ampliamente soportado por la comunidad Open Source

• Su uso está muy extendido

• Tiene el mayor grado de madurez frente al resto

• Amplio catálogo de aplicaciones o “imágenes base” de los productos más populares: MySQL, MariaDB, MongoDB, Maven, Open JDK, etc…

• La mayor parte de orquestadores de contenedores soportan Docker como estándar de facto, por ejemplo: Swarm, Cattle, Kubernetes/Openshift, Portainer, Mesos, Nomad, etc…

• Para entornos empresariales cuentan con una versión EE.

Orquestación de Contenedores ¿Por qué Kubernetes?

Si podemos considerar a Docker como estándar de facto en la contenerización de aplicaciones, Kubernetes podría considerarse como el estándar de facto en la orquestación de contenedores Docker. Kubernetes está escrito en Go y fue desarrollado inicialmente por Google y continuado por la Cloud Native Foundation.

En este caso la elección de Kubernetes frente a otros orquestadores se basa en:

• Ampliamente soportado por la comunidad Open Source

• Más de 10 años de madurez

• Integrado completamente con Docker

• Basado en código abierto

• Preparado para trabajar en sistemas en Producción permitiendo su despliegue en HA y garantizando la HA de las aplicaciones (pods¹) que despliegan

• Soporta clusters de hasta 5000 nodos y hasta 150000 pods en ejecución

• Dashboard gráfico integrado

• Ofrecido como PaaS en diversos clouds: Amazon (EKS) Azure (AKS) Google (GKE) Oracle (OCI)

• Implementado por Red Hat como Openshift en versión empresarial (OCP) y Community (OKD)

• Implementado y/o integrado por Rancher 2

¹En Kubernetes la unidad mínima de despliegue es el pod. Un pod son uno o más contenedores en ejecución que comparten almacenamiento y red

¿Por qué Helm?

Para automatizar, distribuir y desplegar la onesait Platform en clusters existentes de Kubernetes se ha elegido Helm como tecnología base por varios motivos:

• Es un proyecto oficial de Kubernetes, está desarrollado para Kubernetes y mantenido por la Cloud Native Foundation.

• Permite su uso tanto en clusters de Kubernetes como de Openshift.

• Permite instalar y desintalar aplicaciones así como gestionar su ciclo de vida como paquetes o piezas de software.

• Con Helm se pueden escribir Operadores de Openshift (además de con Ansible o Go)

Helm permite empaquetar aplicaciones complejas para ser desplegadas en Kubernetes, pudiendo “aplantillar“ sus ficheros o manifest, tales como Deployment, Service, PersistentVolumeClaim, Ingress, Secret, etc… en plantillas o Templates de Helm y empaquetados en un Chart. Una vez empaquetadas, los Charts pueden distribuirse y versionarse en servidores de Charts (Chart Museum) y ser instalados en clusters de Kubernetes.

Estrategia CaaS

A la hora de elegir un CaaS para cubrir el ciclo de vida completo de la onesait Platform se tienen que tener en cuenta diversas consideraciones:

1. En qué ámbito se va a usar (soluciones o proyectos)

2. Tipo de coste y/o licenciamiento

3. Soporte

4. No vendor lock-in

Estrategia de despliegue de Productos ofrecidos como servicio

Para los productos construidos sobre Plataforma se han seguido dos estrategias CaaS durante estos años:

• La inicial que contemplaba el uso de máquinas virtuales dedicadas y donde la Plataforma se desplegaba mediante contenedores orquestados con Rancher 1.6 versus

• La actual y a la que deberán ir migrando de manera progresiva las distintas Soluciones que se vayan a ofrecer como servicio , basada en el reaprovechamiento de infraestructura y donde tanto la Plataforma como las Soluciones desplegarán en un cluster único de Openshift.

Rancher 1.6 + Cattle - entornos “legacy”

La estrategia inicial de despliegue de las distintas Soluciones, que usan como base tecnológica la onesait Platform, se basa en máquinas virtuales dedicadas donde despliegan los distintos contenedores tanto de la onesait Platform como de la Solución que la utiliza. Estos contenedores están gestionados por Rancher 1.6, un CaaS completamente Open Source con un orquestador desarrollado ad-hoc para Rancher llamado Cattle.

Con esta estrategia las vm’s se provisionan en la cloud de Azure plataformadas con CentOS en entornos de desarrollo y pre producción, mientras que en entornos productivos se plataforman con RHEL, de esta manera se cuenta con el soporte de Azure en la infraestructura y el soporte de Red Hat en el sistema operativo.

Una vez disponible la infraestructura, la instalación del software base en la misma (Docker y paquetes adicionales del sistema operativo) del CaaS (Rancher) así como el despliegue y puesta en marcha de la Plataforma se gestiona con Ansible. Ansible es una herramienta de IaaC (Infraestructure as a code) Open Source y desarrollada por Red Hat, que ha sido elegida frente a otras como Chef o Puppet por las siguientes razones:

• Basado en el principio de idempotencia, la ejecución repetida de un playbook no altera el funcionamiento del sistema una vez que se ha llegado al estado deseado.

• No necesita agentes ejecutándose en la/s máquinas que gestiona

• Curva de aprendizaje muy sencilla

La instalación con Ansible, simplificando, se realiza en los siguientes pasos

• Instalación del software base (Docker, docker-compose, paquetes adicionales)

• Instalación del CaaS

• Despliegue de la Plataforma en Cattle con docker-compose

• Instalación de scripts de arranque y parada ordenada para aquellos entornos en los que precisen, por ahorro de costes, el apagado de la infraestructura por las noches y fines de semana

Cuando desplegamos la plataforma sobre VMS en Entornos de desarrollo la propuesta de despliegue de plataforma es como esta: 

• Entorno CaaS (Rancher 1.6):

  • Despliegue en Single-Instance: 1 VM pequeña (2 cores y 8 GiB) ya que una indisponibilidad del CaaS no afecta a la operación.

• Worker nodes (Plataforma):

  • Despliegue contenerizado de todos los módulos incluida persistencia y proxy inverso o balanceador.

  • Despliegue en 1 VM según necesidades del proyecto y módulos a desplegar:

    • Entorno básico: 1 VM con 4 cores y 16 GiB RAM y 256 GiB disco.

    • Entorno típico: 1 VM con 8 cores y 32 GiB RAM y 512 GiB disco.

    • Entorno alta carga: 1 VM con 16 cores y 64 GiB RAM y 1 TiB disco.

En entornos productivos, la propuesta de despliegue de plataforma contempla:

• Proxy inverso / Load-Balancer:          

  • Se puede usar un Load-Balancer del proovedor de cloud elegido, o el proxy inverso de Plataforma (NGINX) o un balanceador HW.

• Entorno CaaS (Rancher):

  • En función de la HA requerida se puede montar en Single-Instance o en cluster (3 VMS) con la base de datos externalizada

• Worker nodes (Plataforma):

  • Despliegue contenerizado de los módulos de plataforma sin incluir persistencia.

  • Despliegue en al menos 3 VM según necesidades del proyecto y módulos a desplegar:

    • Entorno básico: 2 VM con 4 cores y 16 GiB RAM y 256 GiB disco

    • Entorno típico: 2/3 VM con 8 cores y 32 GiB RAM y 512 GiB disco

    • Entorno alta carga: 3 VM con 16 cores y 64 GiB RAM y 1 TiB disco

OpenShift

OpenShift es la plataforma de Red Hat de gestión de contenedores (pods) que ofrece las herramientas necesarias para cubrir el ciclo de vida completo de un contenedor.

Openshift se basa en distintos componentes Open Source como:

• Kubernetes, como orquestador de contenedores

• Prometheus para la recolección de métricas

• Grafana para la visualización de las distintas métricas del sistema

• Quay como registro de imágenes Docker

• RHCOS / RHEL

La arquitectura física de OpenShift en cuanto a infraestructura de máquinas mínima en HA require tres vm’s para los nodos master y tres vm's para los nodos de procesamiento o worker nodes

La elección de OpenShift se centró en varios puntos importantes:

• Soporte: tanto del sistema operativo de los nodos en los que despliega, como del propio Openshift pasando por todos los componentes software que certifican y que pueden usarse mediante los Operadores.

• Soporte: todos los niveles de soporte son ofrecidos por Red Hat.

• Seguridad: Openshift pone especial atención en los requisitos de seguridad, como no permitir desplegar pods con usuario root.

• Formación: y certificaciones oficiales tanto en la parte de administración y operación como en la parte de desarrollo sobre Openshift.

• CI/CD: Integrado en la Plataforma, ya sea con S2i nativo (source to image) o con Operadores de Jenkins certificados por Red Hat.

• Suscripción: una única suscripción permite diversas instalaciones en clouds públicas o privadas e incluso on premise.

Estrategia de despliegue para proyectos

En el caso de aquellos clientes/proyectos que no tengan una estrategia CaaS definida, no dispongan del conocimiento necesario acerca de las tecnologías de contenerización/orquestación existentes o bien, por ahorro de costes no puedan costear una licencia de Openshift, se proponen los siguientes escenarios de implantación de la Plataforma.

Rancher 2 + Kubernetes

La estrategia a seguir en proyectos en los que no dispongan de un CaaS es la de instalarlo junto con la onesait Platform. La evolución en este caso ha sido pasar de Rancher 1.6 como CaaS y Cattle como orquestador de contenedores a Rancher 2 y Kubernetes. El paso de Rancher 1.6 a Rancher 2 se debe a que Rancher 1.6 alcanza el EOL el 30 de Junio de 2020.

Como características principales de Rancher 2 destacan las siguientes:

• Es 100% Open Source y gratuito (sin soporte) .

• Soporta Kubernetes hasta la versión 1.17.X (dependiendo si se gestiona con RKE o es importado).

• Ofrece RKE como motor de instalación de clusters de Kubernetes de manera muy sencilla.

• Se integra con clusters existentes de Kubernetes, on cloud u on premise.

• Se integra con clusters de Kubernetes proporcionados como servicios por las distintas clouds (AKS, EKS, GKE, OCI).

• Incluye métricas integradas y visualización de las mismas con Prometheus y Grafana

• Tiene CI/CD integrado.

• Tiene amplio catálogo de herramientas integrado y paquetizado con Helm.

• Ofrece de manera opcional soporte de dos tipos: Standard y Platinum con 4 niveles de severidad cada uno, 8x5 y 24x7.

Al igual que en las versiones 1.6 de Rancher la instalación tanto del sofware base como del CaaS y despliegue de la Plataforma se gestiona con Ansible de la siguiente manera:

• Instalación del software base (Docker, docker-compose, paquetes adicionales).

• Instalación del CaaS y despliegue de Kubernetes con RKE.

• Despliegue de la Plataforma en Kubernetes con Helm.

• Instalación de scripts de arranque y parada ordenada para aquellos entornos en los que precisen, por ahorro de costes, el apagado de la infraestructura por las noches y fines de semana.

En cuanto a la infraestructura recomendada para desarrollo y producción no varía respecto a lo detallado anteriormente para el caso de las Soluciones:

Para entornos de desarrollo:

• Entorno CaaS (Rancher 2 + etcd + Control Plane):

  • Despliegue en Single-Instance: 1 VM pequeña (4 cores, 8 GiB de memoria y 256GiB de disco) ya que una indisponibilidad del CaaS no afecta a la operación.

• Worker nodes (onesait Plataform):

  • Despliegue contenerizado de todos los módulos incluida persistencia y proxy inverso o balanceador expuesto mediante Ingress.

  • Despliegue en 1 VM según necesidades del proyecto y módulos a desplegar:

    • Entorno básico: 1 VM con 4 cores y 16 GiB RAM y 256 GiB disco.

    • Entorno típico: 1 VM con 8 cores y 32 GiB RAM y 512 GiB disco.

    • Entorno alta carga: 1 VM con 16 cores y 64 GiB RAM y 1 TiB disco.

Para entornos de producción:

• Proxy inverso / Load-Balancer:          

  • Se puede usar un Load-Balancer del proveedor de cloud elegido, o el proxy inverso de Plataforma (NGINX) o un balanceador HW.

• Entorno CaaS (Rancher 2 + etcd + Control Plane):

  • En función de la HA requerida se puede montar en Single-Instance o en cluster (3 VMS) con la base de datos etcd externalizada

• Worker nodes (onesait Plataform):

  • Despliegue contenerizado de los módulos de plataforma sin incluir persistencia.

  • Despliegue en al menos 3 VM según necesidades del proyecto y módulos a desplegar:

    • Entorno básico: 2 VM con 4 cores y 16 GiB RAM y 256 GiB disco.

    • Entorno típico: 2/3 VM con 8 cores y 32 GiB RAM y 512 GiB disco.

    • Entorno alta carga: 3 VM con 16 cores y 64 GiB RAM y 1 TiB disco.

Rancher 2 + Kubernetes as a service (AKS/EKS/GKE)

En aquellos clientes/proyectos que ya cuenten con un cluster de Kubernetes ya sea on Premise o como servicio cloud, se recomienda montar en una vm adicional y separada del cluster, Rancher 2 como consola de despliegue y monitorización centralizada.

Este nodo de Rancher 2 importará el cluster existente donde se podrán visualizar los namespaces y los distintos workloads. Además de poder realizar nuevos despliegues, arranque, parada y escalado/desecalado de los mismos, etc…

Rancher 1.6 + Cattle - entornos “legacy“

Aplica lo ya detallado para el caso de productos con Rancher 1.6.

Estrategia IaaS

Breve introducción a la Infraestructura como Servicio

La infraestructura como servicio (IaaS) es un tipo de modelo de servicio en la nube en la que se alojan recursos informáticos. Es uno de los cuatro tipos de servicios en la nube, junto con software como servicio (SaaS), plataforma como servicio (PaaS) y Serverless.

Las empresas usan el modelo IaaS para trasladar parte o la totalidad su infraestructura local a la nube, que es propiedad y está administrada por un proveedor.

Los elementos de la infraestructura pueden ser hardware de cómputo (CPU, RAM), hardware de red y almacenamiento, etc.

En el modelo IaaS el proveedor de la nube posee y opera tanto el hardware como el software, además de ser el propietario de los centros de datos donde se alojan los recursos usados.

IaaS VS Modelo tradicional de Infraestructura

En un escenario tradicional una empresa administra y mantiene su propio centro de datos. Tambien deben invertir en servidores, almacenamiento, software y otras tecnologías, así como contratar personal cualificado para comprar, administrar y actualizar todos los equipos y licencias. El centro de datos debe construirse para satisfacer la demanda máxima, aunque a veces las cargas de trabajo disminuyen y esos recursos permanecen inactivos. Ante un rápido crecimiento del negocio el departamento de TI podría encontrar dificultades para mantenerse al día.

En un modelo típico de IaaS una empresa consume servicios como CPU, RAM, almacenamiento y bases de datos de un proveedor de la nube. Ya no necesitará comprar y administrar sus propios equipos, tampoco espacio en un centro de datos donde “enracar” los equipos. El coste de la infraestructura cambiará a un modelo de pago por uso con un escalado fácil y rápidamente ejecutable.

¿Por qué IaaS?

IaaS proporciona cuatro beneficios principales que permiten a las empresas avanzar más rápido y alcanzar sus objetivos de transformación digital.

1. Reduce el tiempo, el coste y mejora el aprovisionamiento y escalado de los entornos de desarrollo, de pruebas y de producción. Esto concede a los desarrolladores y a los equipos de DevOps más libertad para experimentar e innovar.

2. Al hacer que los servicios y recursos estén disponibles bajo demanda, IaaS permite a las empresas escalar su infraestructura aumentando o disminuyendo recursos según sea necesario, pagando solo por lo que usan por hora, día o mes.

3. IaaS está disponible en la mayoría de las paises, con presencia regional cerca de grandes centros de población, lo que permite a las empresas aumentar su presencia en esas geografías más rápidamente.

4. Puede proporcionar acceso a equipos y servicios nuevos y actualizados, como los últimos procesadores, hardware de almacenamiento, elementos de seguridad de red, orquestación de contenedores, etc.

Derivados de estos beneficios se obtienen las siguientes ventajas:

1. Elimina el gasto inicial de Infraestructura y reduce el coste a lo largo de su vida útil. Se evita el coste inicial de configurar y administrar la infraestructura en un CPD, lo que lo convierte en una opción económica.

2. Mejora la continuidad del negocio y la recuperación ante desastres. Lograr alta disponibilidad, continuidad de negocio y la recuperación ante desastres es costoso y complejo, ya que requiere una cantidad significativa de infraestructura y personal cualificado. IaaS reduce este coste y facilita el acceso a las aplicaciones y los datos durante una incidencia o una interrupción del servicio.

3. Innovación rápida. La infraestructura necesaria para lanzar un nuevo producto o una nueva iniciativa puede estar disponible y 100% operativa en horas o incluso en minutos. En un modelo tradicional nos iríamos a días, semanas o a meses.

4. Flexible a las variaciones en la demanda de recursos. Permite escalar recursos rápidamente para hacer frente a los picos de demanda y luego volver a reducirlos cuando la actividad disminuye.

5. Permite enfocarse en el negocio. El equipo de trabajo se centra en el negocio y en la funcionalidad en lugar de poner empeño en la infraestructura de TI.

6. Aumenta la estabilidad, la fiabilidad y la capacidad. No hay necesidad de mantener y actualizar software y hardware o solucionar problemas de equipos. El proveedor de servicios asegura que su infraestructura es confiable y cumple con los niveles de servicio establecidos (SLAs).

7. Mejora en la seguridad. El proveedor Cloud proporciona una capa de seguridad para las aplicaciones y datos adicional a la ya aplicada por la propia compañía.

8. Aplicaciones en Producción a mayor velocidad. No es necesario disponer de la infraestructura antes de desarrollar y entregar aplicaciones.