Virtualización con contenedores Docker: alternativas

Con Docker, la virtualización en el nivel del sistema operativo (Operating-system-level virtualization) regresó a escena. En un plazo de pocos años su equipo desarrollador logró revivir la tecnología de virtualización con contenedores basada en las funcionalidades del kernel de Linux, que, más allá del universo Linux, se ha consolidado como alternativa ligera a la virtualización por emulación de hardware apoyada en hipervisores.

Gracias a la resonancia de los medios de comunicación y a un ecosistema que no para de crecer, Docker se ha erigido como líder tecnológico en el mercado de la virtualización basada en contenedores. No obstante, a la liviana plataforma le han salido algunos contrincantes. A continuación, repasamos algunas de las alternativas a Docker y sus diferencias con el líder.

Por regla general, en los sistemas unix-like como Linux, la virtualización a nivel del sistema operativo se basa en una implementación ampliada de mecanismos Chroot nativos. A esto se añade que contenedores como Docker, rkt, LXC, LXD, Linux-VServer, OpenVZ/Virtuozzo y runC utilizan funcionalidades del núcleo de Linux con el fin de gestionar los recursos para implementar entornos de ejecución aislados para aplicaciones o para un sistema operativo al completo.

Docker recurre a características fundamentales del núcleo de Linux para aislar procesos entre sí y, gracias a su propio entorno de ejecución runC, permite que varias aplicaciones funcionen en paralelo en contenedores aislados sin necesidad de gastar recursos de la máquina. Con esto, esta liviana plataforma se consolida como alternativa a la virtualización basada en hipervisores. En nuestro manual de Docker para principiantes encontrarás una descripción detallada de la plataforma y sus componentes.

La herramienta de virtualización con contenedores Docker se distribuye como edición Community libre (CE) y como versión de pago Enterprise (EE), y es compatible con diversas distribuciones Linux. La versión libre también se puede utilizar como aplicación nativa para Windows y macOS desde la versión 1.12. Si en sistemas Mac Docker recurre al ligero hipervisor xhyve con el objeto de virtualizar tanto un entorno de ejecución para el motor de Docker como funciones específicas del kernel para el demonio de Docker, en Windows, esta función la lleva a cabo el hipervisor Hyper-V.

Desde septiembre de 2016, la versión Enterprise también está disponible de forma nativa para Windows Server 2016. En estrecha colaboración con el equipo de desarrolladores de Docker, Microsoft ha introducido diversas extensiones en el núcleo de Windows para iniciar procesos en forma de contenedor en una sandbox (entorno de pruebas separado del entorno de producción) sin hipervisor. Microsoft pone a disposición de la comunidad open source el código fuente del controlador hcsshim desarrollado expresamente para ello en GitHub.

El siguiente cuadro muestra los aspectos clave de la plataforma Docker:

A lo largo del tiempo se ha desarrollado un activo ecosistema en torno al proyecto originario de Docker. Si hacemos caso de los desarrolladores, el motor de Docker está integrado en más de 100.000 proyectos externos. Sin embargo, no está libre de críticas. El mayor problema que conlleva la virtualización de contenedores de Linux con Docker radica en el grado de aislamiento de cada uno de los procesos en un mismo sistema anfitrión (host). Docker utiliza características nativas del kernel de Linux como Cgroups y Namespaces para ejecutar contenedores en una instancia, pero estas no encapsulan a los contenedores en la misma medida que la virtualización total con máquinas virtuales. Para garantizar el funcionamiento estable de los contenedores de aplicaciones, las nuevas versiones de la plataforma soportan extensiones del núcleo como AppArmor, SELinux, Seccomp und GRSEC, blindando aún más los procesos aislados.

En febrero de 2016, con la versión 1.0 de rkt, CoreOS hizo el primer lanzamiento estable del entorno de ejecución de contenedores. El rival de Docker aspiraba a superar a su contrincante en funciones de seguridad. Entre estas destacan, junto al aislamiento de contenedores basado en KVM (Kernel-based Virtual Machine o máquina virtual basada en el núcleo), la compatibilidad con la extensión del núcleo SELInux, así como la validación con firma para imágenes de la especificación App Container (appc) desarrollada por CoreOS. Esta describe el formato de imagen ACI (App Container Image), el entorno de ejecución, un mecanismo de descubrimiento de imagen (image discovery) y la posibilidad de agrupar imágenes en aplicaciones multicontainer, los llamados App Container Pods.  

A diferencia de Docker, rkt soporta otros formatos de imagen además del suyo y no solo es compatible con imágenes Docker, sino que, con la herramienta libre Quay permite convertir cualquier formato de contenedor en su propio formato ACI.

Mientras que Docker se apoya en un demonio central ejecutado en un segundo plano con derechos root, rkt no necesita este tipo de operación secundaria y, en su lugar, para iniciar y administrar contenedores trabaja con sistemas init consolidados como systemd y upstart. Es de esta manera como rkt esquiva el antiguo problema de Docker (hoy solucionado) por el que los usuarios que querían iniciar el contenedor con el demonio necesitaban derechos root, por lo que obtenían acceso ilimitado al sistema anfitrión.

A diferencia de Docker, rkt no depende exclusivamente de funciones del kernel de Linux como Cgroups y Namespaces para virtualizar aplicaciones. Con el entorno de ejecución de CoreOS también se pueden iniciar contenedores como máquinas virtuales sobre la base de KVM (LKVM o QEMU) o de la tecnología Clear Container de Intel®.

Tanto la especificación appc como su implementación rkt encuentran apoyo en empresas de la talla de Google, Red Hat o VMware.

Para aislar los procesos entre sí, LXC utiliza los siguientes métodos de aislamiento:

• Espacios de nombres (namespaces) IPC, UTS, Mount, PID, de red y de usuario.
• Cgroups
• Perfiles AppArmor y SELinux
• Reglas Seccomp
• Chroots
• Kernel capabilities

El objetivo del proyecto LXC es crear un entorno para contenedores de software que se diferencie lo más mínimo posible de una instalación Linux estándar. LXC se desarrolla bajo la tutela de LinuxContainers.org junto a otros proyectos de código abierto como LXD, LXCFS y CGManager.

En su momento, LXC se desarrolló para ejecutar diferentes contenedores de sistema (full system containers) en un sistema anfitrión. Un contenedor Linux suele iniciar una distribución completa en un entorno virtual partiendo de una imagen del sistema operativo y los usuarios interactúan con ella de forma parecida a como harían con una máquina virtual. Los contenedores Linux rara vez inician aplicaciones, con lo que se diferencian claramente de Docker: mientras que LXC se centra sobre todo en la virtualización de sistemas, Docker se concentra en la virtualización y el despliegue de aplicaciones. Al principio también se utilizaban contenedores Linux con este objetivo. Hoy Docker apuesta por un formato de contenedor propio.

Una diferencia fundamental entre ambas tecnologías de virtualización se encuentra en los procesos que una y otra son capaces de desarrollar, en el caso de los contenedores Linux muchos, pero solo uno en el caso de Docker. Generalmente, las aplicaciones de Docker más complejas están compuestas por varios contenedores. Un despliegue efectivo de estas aplicaciones multicontenedor requiere el uso de herramientas adicionales.

Otra gran diferencia entre los contenedores Docker y Linux es la portabilidad. Desarrollar un software basado en LXC en un sistema de prueba local no garantiza el funcionamiento sin errores del contenedor en otros sistemas (un sistema productivo). La plataforma Docker, sin embargo, abstrae las aplicaciones de un modo más efectivo del sistema subyacente, de forma que un contenedor Docker puede funcionar en cualquier anfitrión que tenga Docker instalado sin depender del sistema operativo ni de la configuración de hardware del equipo.

LXC también funciona sin demonio central y, en su lugar, el software se integra en sistemas init como systemd y upstart, a semejanza de rkt, para iniciar y administrar contenedores.

LXD de Canonical

En noviembre de 2014, Canonical, el distribuidor de Linux, lanzó la alternativa a Docker LXD (se pronuncia “Lexdi”) como proyecto sucesor de LXC. El proyecto hunde sus raíces en la tecnología de contenedores de Linux y la amplía con el demonio LXD. El software puede considerarse como una especie de hipervisor de contenedores.

Técnicamente LXD se compone de tres elementos: el demonio LXD, la herramienta cliente de terminal LXC y el plugin nova-compute-lxd (Open Stack Nova). La comunicación entre el cliente y el demonio tiene lugar por una REST-API.

La finalidad de este proyecto es ofrecer una experiencia de usuario parecida a la obtenida con máquinas virtuales a los desarrolladores acostumbrados a la tecnología de contenedores de Linux, pero sin la sobrecarga resultante de una emulación de recursos de hardware.

Igual que LXC, LXD también gestiona contenedores full system. Esta función de gestión de máquinas le diferencia de Docker y rkt, cuyas funciones centrales se orientan más bien al despliegue de software. LXD utiliza los mismos métodos de aislamiento que el proyecto LXC de base.

El demonio LXD requiere un núcleo de Linux (no soporta otros sistemas operativos). Dado que la comunicación con el demonio tiene lugar con una REST-API, es posible acceder a él por acceso remoto con un cliente Windows o macOS. En un artículo del 9 de febrero de 2017, el director del proyecto LXD Stéphane Graber explica cómo configurar el cliente estándar LXD para un sistema operativo determinado.

Como los VPS funcionan en un sistema anfitrión como procesos aislados y utilizan las mismas interfaces de llamadas al sistema (system call) no se producen sobrecargas por emulación.

El proyecto de código abierto de Jacques Gélinas, hasta hace poco bajo el mando del austríaco Herbert Pötzl, es utilizado, por ejemplo, por proveedores de alojamiento web que ofrecen a sus clientes máquinas virtuales separadas que comparten una misma base de hardware.

Para proveer al núcleo de Linux de las funciones necesarias para la virtualización en el nivel del sistema operativo se ha de parchear, y es esto lo que diferencia fundamentalmente a esta tecnología de los contenedores de Linux (LXC) que se sirven de métodos de aislamiento nativos como Cgroups o Namespaces.

El último lanzamiento de VServer es la versión 2.2 en 2007.

En comparación con la versión precedente, OpenVZ 7 ofrece un conjunto nuevo de herramientas de terminal, las denominadas Gast Tools, que permiten ejecutar tareas de los sistemas huésped directamente en el terminal del sistema anfitrión. La sustitución del hipervisor para administrar máquinas virtuales a favor de las tecnologías consolidadas KVM y QEMU constituye otra novedad de este lanzamiento. En cambio, OpenVZ sigue apostando por su formato propio de contenedor, que, en primera instancia, virtualiza sistemas completos (VPS) como LXC y se diferencia de esta forma de Docker y rkt. Frente a LXC OpenVZ ofrece la opción de migrar en vivo por medio de Checkpoint/Restore in Userspace (CRIU) para poder generar imágenes persistentes de un contenedor en funcionamiento.

Técnicamente, OpenVZ y Virtuozzo representan una ampliación del núcleo de Linux que pone a disposición del usuario diversas herramientas de virtualización. En los denominados entornos virtuales (Virtual Environments, VE), que se ejecutan en un único kernel de Linux, se implementan los sistemas huésped. Esto evita la sobrecarga propia de una emulación de hardware basada en un hipervisor, como en las otras tecnologías presentadas hasta ahora. La subdivisión del núcleo de Linux tiene como consecuencia que todos los sistemas virtualizados estén determinados por la arquitectura y la versión del sistema que los alberga.

Entre las funciones principales de OpenVZ se cuentan la partición dinámica en tiempo real, la administración de los recursos y la gestión central de varios servidores físicos y virtuales.

• Partición dinámica en tiempo real: cada VPS constituye una partición aislada del servidor físico subyacente y contiene su propio sistema de archivos, sus grupos de usuarios (incluyendo un superusuario propio), árboles de procesos, direcciones de red y objetos IPC.

• Administración de recursos: la asignación de recursos de hardware tiene lugar en OpenVZ mediante los llamados parámetros de administración de recursos, que gestiona el administrador del sistema en el archivo general de configuración y en sus archivos de configuración de los contenedores.

OpenVZ y Virtuozzo utilizan la herramienta de gestión de Red Hats libvirt, compuesta por una API open source, el demonio libvirtd y el programa de líneas de comando virsh, para gestionar las máquinas virtuales y los contenedores del sistema.

Si Virtuozzo contiene de serie una interfaz GUI Parallels Virtual Automation (PVA) integrada, la instalación básica de OpenVZ carece de ella, aunque se puede instalar a posteriori con un software externo. El equipo de desarrolladores de OpenVZ recomiendan para ello el OpenVZ Web Panel de SoftUnity, pero también se puede recurrir a otras alternativas que presenta la wiki de OpenVZ.

La OCI ve la luz en 2015 como organización sin ánimo de lucro de la Fundación Linux de la mano de Docker y otras empresas de la industria de los contenedores de software, con el objetivo de consolidar un estándar abierto para el sector. En la actualidad, la OCI ofrece especificaciones para un entorno de ejecución de contenedores (runtime-spec) y un formato de imagen (image-spec).

El entorno de ejecución de código abierto runC se puede considerar una implementación estricta de estas especificaciones:

Este entorno de ejecución solo soporta contenedores en el formato OCI Bundle y lo único que necesita para ejecutarlos es un sistema de archivos root y un archivo de configuración OCI, pero el proyecto no ofrece ninguna herramienta para generar sistemas de archivos raíz para los contenedores. No obstante, los usuarios que tienen la plataforma Docker instalada pueden recurrir a su función de exportación para extraer un sistema de archivos raíz de un contenedor Docker ya existente, ampliarlo con un config.json y crear así una imagen del contenedor en formato OCI Bundle. El software también es compatible con otras herramientas para generar imágenes de contenedores como oci-image-tools, skopeo y umoci.

Como sucede en las alternativas a Docker rkt y LXC, runC tampoco utiliza ningún proceso-demonio central, sino que se integra con el proceso init systemd.

La siguiente tabla permite cotejar las soluciones presentadas como alternativas a Docker en función de sus características más destacadas:

Este principio de dividir recursos del sistema usando los mecanismos de aislamiento propios del kernel y separar procesos independientes entre sí funcionando en un mismo sistema ya se encuentra en diversos sistemas operativos unix-like: los contenedores Linux son equiparables a las llamadas “Jail” («prisión») en sistemas BSD o a las “Zonas” introducidas por Solaris 10. Para Windows se habla de los conceptos desarrollados con Microsoft Drawbridge, WinDocks, Sandboxie, Turbo y VMware ThinApp.

Gracias a su propio sistema de gestión de usuarios, se pueden definir grupos de usuarios independientes para cada prisión de tal forma que sus permisos se limiten al entorno de su prisión. Es así como un usuario con muchos derechos en una prisión no puede ejecutar operaciones críticas fuera de este entorno virtual. Es lo que también impide que un hacker que ha comprometido una prisión no pueda dañar el sistema completo.

A semejanza de otros conceptos de virtualización en el nivel del sistema operativo, las zonas de Solaris también representan una solución eficaz a la hora de implementar diversos sistemas operativos aislados en un mismo sistema sin gastar sus recursos.

El motor Docker nativo para Windows Server 2016 [Más información en microsoft.com] (https://www.microsoft.com/es-es/cloud-platform/windows-server) se diferencia de las aplicaciones Docker for Windows y Docker for Mac en lo más fundamental: mientras estas dos utilizan una máquina virtual ligera para operar el motor Docker, la versión nativa para Windows Server 2016 utiliza el núcleo mismo de Windows. Es por esto que los contenedores Docker clásicos no se pueden ejecutar en un servidor Windows 2016. Es por esto que en el marco de este proyecto se desarrolla un nuevo formato de contenedor llamado WSC (Windows Server Container). Microsoft ofrece también un contenedor basado en Hyper V que permite un mayor blindaje. Explicamos ambos formatos:

• Windows Server Container: con él Microsoft presenta una tecnología para la plataforma Docker que permite aislar procesos con funciones ampliadas del kernel de Windows. Como sucede con Linux, los contenedores del servidor de Windows también comparten el núcleo del sistema anfitrión que los aloja (anfitrión de contenedores).

• Hyper V Container: con los contenedores Hyper V Microsoft ofrece la posibilidad de aislar aún más los contenedores recurriendo a la clásica virtualización con hipervisores. Un Hyper V container es una máquina virtual que también se controla desde la plataforma Docker exactamente igual que los contenedores del servidor de Windows, pero que, al contar con su propio kernel, disfruta de un mayor aislamiento.

Antes incluso de que Microsoft, en el contexto de su cooperación con Docker, implementara tecnologías nativas de contenedor en el núcleo de Windows, algunos desarrolladores ya habían trabajado en métodos de virtualización para sistemas Windows eficaces en cuanto a recursos del sistema.  Entre los proyectos más conocidos se cuentan Microsoft Drawbridge, WinDocks, Sandboxie, Turbo y VMware ThinApp.

Microsoft Drawbridge

Con el nombre de Drawbridge Microsoft desarrolla el prototipo de una tecnología de virtualización que se apoya en el concepto que fundamenta al sistema operativo Library, que cuando se implementa en una aplicación lo hace como un conjunto de bibliotecas. Con Drawbridge las aplicaciones se ejecutan junto con Library en los denominados procesos Pico, contenedores de aislamiento basados en procesos con interfaces al kernel. En la documentación de WSC Microsoft describe a Drawbridge como un paso previo crucial a la hora de desarrollar la tecnología de contenedores en Windows Server 2016.

WinDocks

WinDocks es una importación de la tecnología Docker a Windows y permite crear y administrar contenedores para aplicaciones .NET y contenedores de datos para servidores SQL. A diferencia de los WSC, limitados por el momento a los sistemas Windows 10 y Windows Server 2016, Windocks también se puede utilizar con sistemas operativos más antiguos como Windows Server 2012, Windows Server 2012 R2 y Windows 8 y 8.1. El software se ofrece tanto en edición Community gratuita como en versión Enterprise con asistencia al cliente incluida.

Sandboxie

Con ayuda de Sandboxie se pueden ejecutar aplicaciones en un entorno aislado (“Sandbox”) en sistemas Windows. De forma parecida a la tecnología de contenedores, este método tiene el objetivo de proteger el sistema anfitrión y otros servicios frente a las actividades de los programas en una aplicación aislada. Para lograrlo, la herramienta se sitúa entre la aplicación y el sistema operativo para interceptar intentos de escritura en el disco duro y redirigirlos a un área protegida. Además de accesos a los archivos, con este proceder también se impiden peticiones de escritura a la base de datos de registros de Windows. Sandboxie está disponible como versión básica gratuita para todas las versiones actuales de Windows, así como también XP y Vista. Las versiones de pago cuentan con un abanico de funciones más amplio tanto para usuarios privados como para su uso comercial.

Turbo (antes Spoon)

Turbo constituye una opción alternativa a Docker con la cual se pueden empaquetar aplicaciones en contenedores e incluir cualquier dependencia como .NET, Java o bases de datos como SQL Server o MongoDB. Sin embargo, a diferencia de los contenedores de Windows Server, aquí el kernel de Windows no soporta los contenedores de forma nativa, lo que conlleva que sea necesaria una máquina virtual como ocurre en Docker for Windows para compensar las inconsistencias. Los contenedores Turbo se ejecutan en el motor de la máquina virtual Spoon (SVM), que actúa de interfaz al kernel de Windows. El intercambio de aplicaciones de los contenedores también funciona aquí con un Hub basado en la nube. Aun cuando el software está bien documentado, no encuentra tanta atención en la prensa especializada como Docker.

VMware ThinApp

La herramienta de virtualización de aplicaciones en el entorno de escritorio VMware ThinApp permite integrar aplicaciones en estructuras informáticas complejas sin conflictos. Para ello las aplicaciones se empaquetan, junto con todas las dependencias, en un archivo ejecutable EXE o MSI y se aíslan así del sistema operativo subyacente y de otras aplicaciones. Este archivo así creado por ThinApp se puede ejecutar sin instalación (y de esta forma sin derechos Admin) en cualquier sistema Windows, incluso también desde un dispositivo móvil de almacenaje como una memoria externa. ThinApp se erige como alternativa a Docker a la hora de migrar aplicaciones Legacy o aislar programas críticos.