DevOps

Qué son los contenedores

Los contenedores, en esencia, son procesos que corren dentro del sistema operativo los cuáles cumplen con algunas características que los hacen “especiales”. Comparten el ecosistema junto con procesos “comunes” y es gracias al KERNEL de Linux que, mediante algunas características de este, brinda a estos procesos, capacidades notables.

Un contenedor es un proceso que corre aislado de otros contenedores, incluso también se ejecuta aislado de otros procesos “comunes”, y es por medio de una estructura del KERNEL llamada Namespaces que proporciona esta capacidad. Además, cuando es deseable limitar y controlar el acceso a recursos de cómputo tales como CPU o memoria, el KERNEL de Linux proporciona una característica llamado controlGroups o cgroups que brinda esta posibilidad.

En su expresión más básica, un contenedor no es más que cgroups y namespaces junto con otras estructuras como seccomp para limitar algunas llamadas al sistema y controles de acceso mandatorios, tales como SELinux o AppArmor.

Historia de los contenedores

Si bien los contenedores se han vuelto populares en los últimos años, lo cierto es que no es una tecnología nueva, de hecho, la estrategia de aislar y segmentar procesos viene desde hace muchos años. Este es el timeline de eventos que derivaron en lo que hoy conocemos como “Contenedores”.

• En 1999 FreeBSD incorpora el término “Jails” que es un mecanismo para crear “mini sistemas” que comparten el mismo KERNEL.
• En 2001 Linux-VServer se desarrolla y proporciona un mecanismo para virtualizar a nivel del Sistema Operativo.
• En 2004 Solaris introduce el concepto de snapshots con “Solaris Zones”.
• En 2006 Google introduce el término conocido como “cgroups” o “controGroups”.
• En 2008 Red Hat introdujo a los “Namespaces”.
• En 2008 además, IBM crea el proyecto LxC, también conocido como “Linux Containers”, que provee una serie de herramientas para trabajar con “cgroups” y “namespaces”.
• En 2013, finalmente, Docker introduce herramientas que simplifican y masifican la creación de Contenedores y aparece un nuevo término; el de “Imagen”.

Como verán, los contenedores no son una tecnología “nueva” sino por el contrario, es el resultado de varios años de experiencia en la segmentación de cargas de trabajo, separación y aislación de aplicaciones.

Ventajas de los contenedores

No cabe duda que los contenedores han revolucionado la forma en que se empaqueta y entrega el software y que muchas son las ventajas respecto al modelo tradicional de despliegue de aplicaciones basados en máquinas virtuales, desde la simplicidad hasta la portabilidad.

Para mencionar algunas de las ventajas más notables, tenemos:

• Los contenedores son livianos puesto que solo involucra al proceso de la aplicación y nada más.
• Se dice que los contenedores son más densos, en el sentido de cantidad, por cada Máquina Virtual, podemos tener N contenedores.
• Son portables entre ambientes. El código usado para desplegar un contenedor puede ser replicado N veces.
• Los contenedores son inmutables. Es decir, que perderemos todo cambio realizado directamente sobre el contenedor luego de que el proceso finaliza abruptamente o por orden del usuario. De esta forma, se mejora notablemente la estabilidad del servicio prestado.
• Son escalables. Podemos tener N cantidad de réplicas del mismo servicio creando más contenedores, con muy bajo esfuerzo.
• Son seguros. Si se siguen las buenas prácticas, brindan un entorno de ejecución limitado, por lo que si la aplicación o servicio que ejecuta ese contenedor se ve comprometido, el sistema subyacente no se vería afectado.

Contenedores vs Máquinas Virtuales

Las máquinas virtuales y los contenedores difieren en muchos aspectos. El primero y quizás el más notorio, es que las máquinas virtuales son creadas con un subconjunto de recursos de cómputo del hardware físico, es decir, por cada máquina virtual obtenemos un pool de recursos como RAM, CPU, Disco, etc. El hipervisor es el encargado de gestionar tanto los recursos físicos como los recursos virtuales provistos.

Cada máquina virtual se despliega con un sistema operativo con sus librerías y dependencias necesarias para luego poder instalar las aplicaciones que dicha máquina va a servir.

Los contenedores, en cambio, como ya lo hemos mencionado, están a un nivel de abstracción mucho más alto, por lo que el concepto de hardware virtual es desconocido para estos procesos especiales. Los contenedores pueden correr en servidores virtuales o físicos indistintamente, obteniendo el mismo resultado, lo único que necesitan es un entorno de ejecución y un KERNEL de Linux.
Si se siguen las buenas prácticas, un contenedor solo debería estar compuesto por el proceso de la aplicación y las dependencias necesarias, nada más.

Mientras que el hipervisor es el encargado de gestionar las máquinas virtuales, junto a los contenedores existe un gestor llamado “Container Engine” que se encarga de dialogar con las estructuras del KERNEL correspondientes.

Uso de los contenedores

Los contenedores han sido una de las piezas de tecnología más importantes en los últimos tiempos gracias al movimiento DevOps y a las distintas estrategias de arquitectura de software para ensamblar aplicaciones cloud nativas, en gran medida por su versatilidad y practicidad, aunque cualquiera sea la necesidad, es posible que podamos emplear contenedores.

Entre los casos más destacados, tenemos:

• Aplicaciones basadas en microservicios: Cada microservicio se ejecuta como una unidad lógica de negocio independiente de otros microservicios. Los contenedores son la mejor pieza de infraestructura para alojar a estos microservicios y lograr esa independencia.

• Ambientes de desarrollo basados en ciclos de CI/CD: Los ciclos de integración continua y despliegue / delivery continuo, son uno de los procesos emblema del movimiento DevOps. El uso de contenedores en este proceso, habilita a los equipos DevOps en la creación de ambientes homogéneos y repetibles, a prueba de errores e integrados con herramientas para complementar el ecosistema.

• Escalabilidad horizontal manual o automática: Una propiedad embebida del software encargado de gestionar contenedores, es la posibilidad de crearlos bajo demanda y con las mismas prestaciones. Esta característica es de las más explotadas en aplicaciones cloud nativas donde la elasticidad es requerida para aumentar la cantidad de contenedores para soportar los picos de consumo y bajar la cantidad cuando el consumo se estabiliza.

• Inmutabilidad en la infraestructura desplegada: Los contenedores se crean a partir de unos binarios llamados imágenes. El ensamblado de estos binarios es, probablemente, la tarea más importante del SRE o DevOps y gracias a cómo están diseñadas las imágenes, los contenedores que se crean son efímeros, es decir, los cambios que hagamos dentro se perderán junto con este, por lo que, cualquier cambio que queramos hacer, debemos de efectuarlo a nivel de la imagen.

• Ambientes de sandbox y controlados: Los equipos de SRE, DevOps e incluso de Desarrollo, a menudo necesitan desplegar ambientes descartables de forma rápida. Los contenedores habilitan la creación de estos ambientes. Existen repositorios de imágenes oficiales y de terceros, con un vasto catálogo de productos y software que podemos usar como base, y de ser necesario, también podemos armar nuestro propio binario.

• Refactorización y/o modernización de las aplicaciones legacy: Ya sea que estemos estudiando y analizando cómo modernizar una aplicación desarrollada sobre tecnologías obsoletas o iniciando el camino hacia la adopción de tecnologías de Cloud, los contenedores son una pieza de software que articulan el cambio. Su versatilidad aporta al proceso la posibilidad de dividir en etapas el proyecto, donde cada incremento puede ser por componente o funcionalidad, de hecho, podemos acoplar componentes refactorizados a componentes legacy. Un ejemplo son las aplicaciones del sector bancario, donde por un lado tenemos al core desarrollado en lenguajes con bastantes años y funcionando sobre hardware que ya casi no se fabrica y por el otro, el home banking desarrollado en tecnologías y frameworks más modernos y corriendo sobre infraestructura de cloud.

• Automatización de los despliegues de infraestructura: Los contenedores son emblema en el mundo de la “Infraestructura como Código”, y en parte esto es porque creamos y desplegamos contenedores de forma automatizada y usando código en distintas herramientas como Terraform o Ansible. Lo cierto es que, no importa cuál es el ambiente que deseamos ensamblar, con la elección de las herramientas correctas, podemos desplegar infraestructura rápidamente usando código. Este grado de flexibilidad permite responder rápidamente frente a cambios en el negocio.

Orquestación de contenedores

Antes de hablar sobre cómo orquestar contenedores, debemos de hablar de qué tareas están involucradas en la gestión de éstos. A menudo las organizaciones que están comenzando a transitar el camino hacia el uso de tecnologías basadas en contenedores, el punto de partida es lo que se conoce como un ¨Container host¨ que no es más que una máquina virtual o física con el software instalado para trabajar con contenedores.

La gestión de estos está delegada en un componente de software llamado Container Engine cuya función es la de recibir las peticiones del usuario y delegar a las distintas primitivas las operaciones que se pueden efectuar, tales como crear y detener contenedores, descargar imágenes, pushear imágenes al catálogo, etc.

Gracias a este motor, la complejidad que supone trabajar con las estructuras del KERNEL, pasa a ser una tarea accesible para desarrolladores y equipos DevOps. En parte, el éxito de la tecnología se debe a esto.

Existen varios motores de contenedores, con distintas características y prestaciones, entre los más populares tenemos:

• Docker
• Podman
• CRI-O
• LxC

Internamente, y a modo de ejemplificar, el Container Engine tiene esta arquitectura:

• El usuario ejecuta la orden de operación, por ejemplo, crear un contenedor.
• El container engine recibe la petición.
• El container engine, mediante librerías y binarios se fija si la imagen existe localmente.
• Si no existe, va al catálogo de imágenes y hace un pull de la misma.
• Luego va contra al KERNEL para instanciar el proceso
• El proceso dentro del contenedor se inicia.

Por supuesto que el flujo, a bajo nivel, es un poco más complejo, sobre todo si hacemos “doble click” en los componentes que hacen al motor de contenedores y además de que depende del motor que usemos, ya que no es lo mismo usar Docker que Podman, pero sin duda que sirve para ilustrar como es el proceso desde que el usuario ingresa la orden y se crea el contenedor.

Ahora que ya hemos definido que es un Container Engine, podemos hacernos la siguiente pregunta. ¿Es suficiente con un Motor de Contenedores? La respuesta correcta es: Tal vez, si tenemos pocos contenedores. Depende del grado de madurez en la tecnología, 10 contenedores pueden ser pocos o muchísimos.

Lo cierto es que, cuando empezamos a hacernos algunas de las siguientes preguntas, estamos evidenciando la necesidad de evaluar herramientas que complementen al motor de contenedores.

• ¿Cómo escala mi aplicación?
• ¿Cómo evitamos conflictos de puertos en un host?
• ¿Cómo distribuimos cargas de trabajo en varios hosts?
• ¿Cómo garantizamos que un contenedor va a estar en ejecución?
• ¿Cómo gestionamos el ciclo de vida del contenedor?
• ¿Cómo encuentro un contenedor en un grupo de hosts?

A medida que las aplicaciones van creciendo y la adopción de contenedores se hace más fuerte se hacen necesarias herramientas para automatizar el mantenimiento: reemplazo de contenedores fallidos o auto-recuperación de los mismos, cambios en las configuraciones, updates periódicos, manejo de escalamiento horizontal y vertical bajo demanda, y mucho más.

Este software se le conoce como Orquestador de Contenedores. Ejemplos de orquestadores pueden ser:

• Kubernetes (a.k.a k8s o simplemente Kube)
• Docker Swarm
• Mesos

De los mencionados, sin duda el más popular es Kubernetes al punto de convertirse en el estándar de facto de la industria en lo que manejo de contenedores a gran escala se refiere. Tan es así que los principales proveedores de Cloud Pública tienen servicios gestionados basados en Kubernetes.

Kubernetes es un proyecto Open Source liberado a la comunidad por Google en el año 2014 y derivado del proyecto Borg, ampliamente probado en el manejo de cargas de trabajo contenerizadas y desde entonces varias comunidades del ecosistema Open Source han puesto mucho foco en soportar esta plataforma, adaptando o incluso re-diseñando aplicaciones para que corran sobre Kubernetes.

Conclusiones

Sin duda alguna los contenedores han revolucionado la industria del Software y la Infraestructura y las tecnologías que usamos para trabajarlos han dado lugar a nuevos paradigmas y estrategias que, cada vez se hacen más populares. Un ejemplo es Function as a Service, un caso práctico dentro de “Serverless” o “Computación sin servidor”, el cuál es un enfoque que está soportada por la idea de cómputo efímero, donde solo tenemos acceso a esos recursos mientras se ejecuta la función, desde el instante en que fue invocada hasta que la misma finaliza devolviendo el resultado. Este nuevo paradigma también está apoyado en contenedores.

No importa si nuestro caso de uso es migrar una aplicación legada o una aplicación cloud nativa, lo cierto es que hace algunos años comenzó la carrera en la adopción de contenedores y son pocas las empresas que todavía no han iniciado el viaje.

Los contenedores van a seguir evolucionando y debemos de estar atentos a los nuevos desafíos, por lo que la invitación es a que se mantengan sintonizados en este mundo de las aplicaciones cloud nativas!