Estrategia de despliegue de la Onesait Platform

Hoy vamos a hablar un poco sobre la estrategia que seguimos a la hora de desplegar nuestra Platafoma.

Base tecnológica de onesait Plataform

Contenerización. ¿Por qué contenedores?

La Onesait Platform está basada en una arquitectura de microservicios escritos en Java usando el framework Spring Boot, y 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:

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.

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 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, 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.

Despliegue de Onesait Platform en k8s. ¿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.

Soluciones digitales

Para la diversas Soluciones/Productos de la compañía 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, frente la actual y a la que deberán ir migrando de manera progresiva las distintas Soluciones, basada en el reaprovechamiento de infraestructura y donde tanto la Plataforma como las Soluciones desplegarán en un cluster único de Openshift.

Durante el mes de Enero de 2019, Onesait lanza una RFP para decidir cual es la Plataforma para el despliegue de contenedores de referencia en la organización, entre otras estaban Microsoft con AKS, Red Hat con Openshift y Rancher 2 con RKE. Tras el lanzamiento de esta RFP se decide en usar Openshift como base tecnológica.

Rancher 1.6 + Cattle – entornos “legacy”

La estrategia inicial de despliegue de las distintas Soluciones y Disruptores de la organización, 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 las 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 de 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 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.

La migración de las Soluciones gestionadas con VM’s dedicadas y Rancher 1.6 a Openshift se hará progresivamente y bajo petición.

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).
• Métricas integradas y visualización de las mismas con Prometheus y Grafana.
• CI/CD integrado.
• Amplio catálogo de herramientas integrado y paquetizado con Helm.
• Ofrecen de manera opcional soporte de dos tipos: Standard y Platinum con 4 niveles de severidad cada uno, 8×5 y 24×7.

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 el caso 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 proovedor 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 de 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 Soluciones con Rancher 1.6.

---

Como veis, nuestra estrategia es avanzada y adaptada según las necesidades. Esperamos que os haya sido de interés, y cualquier consulta o duda que os surja, podéis dejarnos un comentario.

Confluence | Estrategia de despliegue de la onesait Platform

✍🏻 Author(s)