Eficiencia de la arquitectura con contenedores

¿Por qué es tan barato ejecutar un contenedor en la arquitectura de tu sistema? ¿Qué hace que un contenedor sea mucho más eficiente que una máquina virtual? ¿Por qué deberíamos ejecutarlos en producción y qué ventajas aportan para el desarrollo y la escalabilidad?

Olvida todo lo que crees saber sobre los contenedores. En esta publicación, analizamos las ventajas de empaquetar tus procesos.

Te preguntarás, ¿qué es un contenedor? Muy sencillo: en cuanto a la arquitectura del sistema y el entorno de desarrollo, un contenedor es solo un proceso contenido.

Al igual que hay muchas formas de almacenar y organizar los datos, existen muchas formas de almacenar procesos y aplicaciones. Una de las mejores es usar contenedores. En nuestro contexto, analizaremos los contenedores desde el kernel de Linux. Por lo tanto, puede resultar útil pensar en un contenedor como un CHROOT. Un CHROOT es una especie de cárcel para el proceso. Pones tu proceso en la cárcel y, mientras esté allí, no podrá acceder a ningún proceso externo. Solo accederá a los sistemas de archivos que se le proporcionaron al construir la cárcel.

Ahora hablemos de lo que no son los contenedores. Los contenedores no son Docker. Docker suele llevarse todo el crédito por los contenedores, pero la tecnología central no la proporciona Docker, sino el propio kernel de Linux. Aun así, nos gusta Docker: es de código abierto y hace que interactuar con los contenedores de Linux sea divertido y sencillo.

Los CHROOT por sí solos no son suficientes. No es eficiente tener solo procesos contenidos que no puedan acceder a ninguna información externa después de crear el contenedor. Para mejorarlos, nacieron los espacios de nombres (namespaces) del kernel. Los espacios de nombres son excelentes para aislar procesos. Una vez aislados, todos los procesos que comparten un espacio de nombres de red pueden ver y usar la misma interfaz de red para comunicarse entre sí.

En realidad, los espacios de nombres no tienen nada que ver con los “nombres”, pero sí sirven para aislar los recursos en un espacio designado. Por ejemplo, los procesos que se ejecutan en Linux normalmente pueden ver otros procesos e interactuar con ellos porque no existen en un espacio de nombres. Pero en cuanto iniciamos un proceso en su propio espacio de nombres, este solo podrá ver otros procesos de ese mismo espacio. ¿Lo ves? Los espacios de nombres son como súper CHROOT, o cárceles muy indulgentes donde puedes invitar a otros procesos amigos a pasar el rato, si seguimos con la analogía de la prisión.

Si estás pensando: “¡Oye! Este asunto del kernel de Linux suena como un hipervisor”, felicidades por estar familiarizado con los hipervisores. Los hipervisores solo son programas que se usan para gestionar varias máquinas virtuales en un ordenador; aunque los contenedores y las máquinas virtuales tienen similitudes, no son lo mismo. Los contenedores son solo procesos que se ejecutan en un espacio de nombres.

La tecnología de los espacios de nombres es perfecta para la eficiencia porque es tan ligera que es casi inexistente. Casi no afecta al tiempo de inicio y su impacto en el tiempo de ejecución es nulo. El rendimiento no se ve afectado en absoluto al ejecutar el proceso en un contenedor en lugar de fuera de él.

La mayoría de las máquinas virtuales casi siempre ejecutan todo un sistema operativo. En cambio, los contenedores normalmente solo ejecutan uno o dos procesos. Sin embargo, como un espacio de nombres puede tener varios procesos, podrías ejecutar un sistema operativo completo desde un contenedor. Aun así, probablemente sea una mala idea, ya que supondría un desperdicio total de recursos.

Bien, ahora hablemos de la parte económica de la eficiencia. En una conferencia DOT de 2015, John Wilkes dio una charla sobre las eficiencias que consiguió Google al pasarse a los contenedores y a su orquestación. Calculó que si Google volviese a las máquinas virtuales tradicionales, tendría que construir el doble de centros de datos para ejecutar las mismas cargas de trabajo.

Quedan patentes las posibles ventajas de eficiencia que supone ejecutar contenedores en lugar de máquinas virtuales. Las máquinas virtuales conllevan el sobrecoste de tener que alimentar todo el sistema operativo  y los procesos de apoyo. Los contenedores  se limitan a ejecutar tu aplicación sin empantanarse con procesos externos. Como resultado, puedes ejecutar muchos más contenedores que máquinas virtuales en un único host.

Aunque el ahorro económico es una ventaja evidente, puede que aún te preguntes por qué deberías usar contenedores en lugar de máquinas virtuales. Al fin y al cabo, lo más seguro es que no te dediques a construir centros de datos como hace Google. ¿Acaso no acabamos de decir que los contenedores son solo procesos que se ejecutan en Linux? ¿No deberíamos ejecutar los procesos en el sistema operativo sin espacios de nombres? ¿Por qué necesitamos todo este rollo de los espacios de nombres y Docker?

El motivo original para ejecutar un proceso en un CHROOT era aislar la aplicación del resto del sistema operativo. ¿Recuerdas la cárcel? Esta configuración contenida sirve para limitar el acceso en caso de que la aplicación se vea comprometida. Si, por algún motivo, un hacker logra entrar y ejecutar procesos arbitrarios, sus opciones de acción se verán limitadas por los archivos y las herramientas proporcionados al proceso del CHROOT.

Los contenedores ofrecen esta misma ventaja de seguridad. No tienes que incluir todo el sistema operativo en el contenedor; puedes incluir únicamente los archivos y las bibliotecas que necesita tu aplicación para funcionar. De forma similar a un CHROOT, en caso de que hackeen tu aplicación, el hacker dispondrá de muy pocas herramientas para salir del contenedor o acceder a los recursos de la red, lo que limita los daños que puede causar.

Otro motivo para aislar la aplicación del sistema operativo es evitar la complejidad de gestionar muchas dependencias de las múltiples aplicaciones que podrías querer ejecutar en un solo servidor. Puede que algunos sistemas operativos no ofrezcan la dependencia requerida, o que las dependencias de dos aplicaciones independientes entren en conflicto. Esto puede hacer que su instalación y gestión sean una pesadilla. El equipo de desarrollo suele dejar la resolución de este infierno de dependencias a SRE, lo cual, al final, supone una absoluta pérdida de tiempo.

Con una imagen de contenedor, instalas únicamente las dependencias necesarias para que funcione la aplicación. Esto te permite ejecutar muchas aplicaciones dispares en el mismo servidor sin el riesgo de que haya conflictos de dependencias.

La buena noticia es que, gracias a este aislamiento de las aplicaciones, logramos mucha más flexibilidad a la hora de actualizar las dependencias. Por ejemplo, si todavía usas aplicaciones en Python 2.7 (cuya instalación ya no se permite en la mayoría de las últimas distribuciones de Linux), puedes emplear contenedores para aislar aplicaciones más antiguas y poder seguir ejecutando los servicios de Python. En este escenario, el uso de contenedores nos da margen para trasladar las aplicaciones a Go o Python 3, sin poner en riesgo el sistema operativo subyacente.

“En mi equipo funcionaba” es una frase muy común que pronuncian los equipos de desarrollo enfadados en todo el mundo. No obstante, gracias a las imágenes de contenedor, tienes la certeza de que la imagen que se generó y ejecutó en tu máquina local (o en el entorno de CI) es la misma que validará el control de calidad (QA) y la misma que acabará llegando al entorno de producción. Esto no solo soluciona los problemas de eficiencia en el desarrollo de aplicaciones, sino que también los traslada a producción.

¡A por ello! Los contenedores son solo procesos que se ejecutan en un espacio de nombres. Pero esto no significa que sean irrelevantes. A la hora de crear una arquitectura eficiente, los contenedores no solo ayudan con la organización y el aislamiento, sino también con la seguridad, lo cual resulta de lo más rentable.

¿Te resulta interesante? ¡A nosotros también! Nos encanta profundizar y ponernos un poco frikis con temas específicos como este. No olvides suscribirte a nuestra newsletter para descubrir más novedades y análisis técnicos exhaustivos.

Autor: Derrick Wippler Derrick Wippler is the Principal Engineer at Sinch Mailgun. He researches, develops and oversees our engineering initiatives. He writes about engineering topics, system architecture, services, and efficiencies. We suspect he's part computer himself.