Virtualización con contenedores Docker: alternativas
Equipo editorial de IONOS
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.
Tecnología de virtualización con Linux
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.
Chroot equivale a “change root”, un comando que se utiliza en sistemas operativos unix-like para modificar el directorio Root y los procesos hijo de un proceso en ejecución. Una aplicación que se ejecuta en un entorno modificado de esta forma (se habla aquí entonces de un chroot jail) ya no puede acceder a ningún otro fichero externo al directorio seleccionado. Chroot no ha sido desarrollado como una característica de seguridad, por lo que es relativamente fácil penetrar un blindaje de este tipo.
Docker
Cuando se trabaja con contenedores de software tarde o temprano se tropieza con Docker. En muy poco tiempo, el proyecto open source de la firma homónima de software Docker Inc. ha logrado posicionarse en un lugar relevante en los sectores de despliegue de software, de DevOps (creación de entornos de pruebas para aplicaciones) y de entrega continua (Continuous Delivery) de software.
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:
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | Versión 3.10 o superior |
|---|---|
| Distribuciones de Linux compatibles | Docker Community Edition (CE): Ubuntu, Debian, CentOS y Fedora, Docker Enterprise Edition (EE): Ubuntu, Red Hat Enterprise Linux, CentOS, Oracle Linux y SUSE Linux Enterprise Server |
| Otras plataformas | Docker Community Edition (CE): Microsoft Windows 10 (Pro, Enterprise o Education con 64 Bit), macOS (Yosemite 10.10.3 o superior), Microsoft Azure, Amazon Web Services (AWS), Docker Enterprise Edition (EE): Microsoft Windows Server 2016, Microsoft Windows 10 (Pro, Enterprise o Education con 64 Bit), Microsoft Azure, Amazon Web Services (AWS) |
| Formato del contenedor | Docker container |
| Licencia | Apache 2.0 |
| Lenguaje de programación | Go |
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.
| Ventajas | Inconvenientes |
|---|---|
| Docker soporta diversos sistemas operativos y plataformas en la nube. | El motor de Docker solo es compatible con su propio formato de contenedor. |
| Con Swarm y Compose, la plataforma Docker ya ofrece herramientas de gestión de clústeres. | El software está disponible como archivo monolítico que contiene todas sus características. |
| Con el Hub de Docker los usuarios cuentan con un registro central de recursos. | Los contenedores Docker solo aíslan procesos entre sí, pero no virtualizan sistemas operativos (full system container). |
| El ecosistema Docker, en constante crecimiento, pone a disposición de sus usuarios diversas herramientas, plugins y componentes de infraestructura. |
La tecnología de contenedores se se desarrolló originalmente con la finalidad de poder ejecutar varios sistemas operativos virtuales en entornos aislados en un mismo núcleo. En este caso se habla de “full system containers” (contenedores de sistema operativo). La plataforma Docker, por el contrario, se fundamenta en los denominados contenedores de aplicaciones, en los que cada aplicación se ejecuta en su propio entorno virtual. Y mientras que los contenedores full system están diseñados de tal forma que en ellos puedan ejecutarse varios procesos, un contenedor de aplicaciones solo contiene un único proceso. Como consecuencia, en Docker las aplicaciones más complejas han de realizarse como aplicaciones multicontainer.
rkt (rocket)
El mayor competidor de Docker en el mercado de la virtualización basada en contenedores es el entorno de ejecución rkt del distribuidor de Linux CoreOs, presentado en 2014. Según Alex Polvi, CEO de la compañía, el motivo para desligarse de la plataforma Docker, que hasta entonces contaba con el apoyo del equipo de desarrollo de CoreOs, fue la insatisfacción con el desarrollo del proyecto: Docker se habría desviado de su objetivo, que en su origen era desarrollar una tecnología estándar de virtualización con contenedores, para, en su lugar, concentrarse en la comercialización de una plataforma monolítica de desarrollo de aplicaciones.
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.
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | Cualquier núcleo amd64 moderno |
|---|---|
| Distribuciones de Linux compatibles | Arch Linux, CentOS, CoreOS, Debian, Fedora, NixOS, openSUSE, Ubuntu, Void |
| Otras plataformas | macOS o Windows con Vagrant Virtual Machine |
| Formato de contenedor | appc, Docker Container; con Quay se pueden convertir otros formatos de imagen al formato rkt |
| Licencia | Apache 2.0 |
| Lenguaje de programación | Go |
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.
Desde la versión 1.11, el demonio de Docker ya no ejecuta los contenedores directamente. En lugar de ello utiliza un programa-demonio denominado Containerd.
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.
| Ventajas | Inconvenientes |
|---|---|
| Además de su propio formato, rkt también soporta imágenes de Docker y gracias a Quay convierte cualquier imagen en el formato ACI de rkt. | Existen muchas menos integraciones de proveedores externos para rkt que para Docker. |
| Tecnologías como KVM y Clear Container de Intel® facilitan separar contenedores de software entre sí de forma segura. | rkt está optimizado para operar contenedores de aplicaciones, pero no soporta contenedores de sistemas operativos (full system container). |
LXC (Linux Containers)
La siguiente alternativa a los contenedores Docker es un juego de herramientas, plantillas, bibliotecas y bindings de lenguaje que, en conjunto, constituye una User Space Interface para las funciones nativas de virtualización con contenedores del núcleo de Linux. LXC ofrece a los usuarios de Linux una forma sencilla de crear y administrar contenedores para aplicaciones y sistemas.
Los bindings de lenguaje son adaptadores denominados wrapper (to wrap: empaquetar) que construyen puentes entre diferentes lenguajes de programación permitiendo de esta manera relacionar diferentes partes del programa entre sí.
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.
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | Versión 2.6.32 o superior |
|---|---|
| Distribuciones de Linux compatibles | LXC está incluida en la mayoría de distribuciones Linux, Se requieren las siguientes bibliotecas: Biblioteca C: glibc, musl libc, uclib o bionic, Otras bibliotecas: libcap, libapparmor, libselinux, libseccomp, libgnutls, liblua, python3-dev |
| Otras plataformas | Ninguna |
| Formato de contenedor | Linux Container (LXC) |
| Licencia | GNU LGPLv2.1+ |
| Lenguaje de programación | C, Python 3, Shell, Lua |
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.
| Ventajas | Inconvenientes |
|---|---|
| LXC está optimizado para operar contenedores full system. | No se utiliza de forma estándar para operar contenedores de aplicaciones. |
| A excepción de Linux, no cuenta con ninguna implementación nativa para otros sistemas operativos. |
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.
Nova es el componente central de cálculo de OpenStack, sistema operativo de código abierto en la nube que se utiliza para disponer y administrar sistemas virtuales en arquitecturas en la nube. OpenStack Nova soporta diversas tecnologías de virtualización basadas en hipervisores y en el nivel del sistema operativo.
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.
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | Como LXC |
|---|---|
| Distribuciones de Linux compatibles | Cliente de líneas de comando (lxc): Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, nova-compute-lxd: Ubuntu 16.04 LTS |
| Otras plataformas | Ninguna |
| Formato de contenedor | Linux Container (LXC) |
| Licencia | Apache 2.0 |
| Lenguaje de programación | Go |
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.
| Ventajas | Inconvenientes |
|---|---|
| LXD está optimizado para operar contenedores full system. | No se utiliza de forma estándar para operar contenedores de aplicaciones. |
| El cliente LXD puede configurarse para Windows y macOS y permite el control remoto del demonio LXD por medio de la REST-API. | El demonio LXD solo funciona en un núcleo de Linux. |
Linux-VServer
Linux-VServer consiste en una técnica de virtualización en el nivel del sistema operativo que recurre a características de aislamiento del núcleo de Linux de forma similar a los contenedores de software. Varias unidades virtuales comparten un único núcleo, cuyos recursos (sistema de archivos, CPU, direcciones de red y memoria) se subdividen en particiones independientes gracias a un mecanismo Jail. En la terminología de Linux-VServer estas particiones se conocen como “Security Context” y se generan mediante técnicas estándar como Segmented Routing, Chroot y Quota. Un sistema virtualizado en uno de estos contextos de seguridad se denomina Virtual Private Server (VPS).
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.
No se debe confundir la virtualización en el nivel del sistema operativo con Linux-VServer con el proyecto Linux Virtual Server, en el cual se desarrolla una técnica de balance de carga para clústeres Linux.
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | Versión 2.6.19.7 o superior |
| Distribuciones de Linux compatibles | Todas |
| Otras plataformas | Ninguna |
| Formato de contenedor | Linux-VServer utiliza Security Context, un concepto similar a los contenedores |
| Licencia | GNU GPL v.2 |
| Lenguaje de programación | CC |
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.
| Ventajas | Inconvenientes |
|---|---|
| Mientras que en Docker los cambios en un contenedor solo se pueden guardar si se crea una imagen nueva de un contenedor en funcionamiento, Linux-VServer ofrece un sistema de ficheros en el anfitrión para todos los VPS en el que se pueden guardar todos los estados actuales. | Linux-VServer requiere modificar el núcleo de Linux. |
| El último lanzamiento data de 2007. |
OpenVZ/Virtuozzo 7
Desde julio de 2016 los usuarios tienen a su disposición la versión 7 de la plataforma de virtualización OpenVZ de Parallels como distribución de Linux autónoma. El software está basado en Red Hat Enterprise Linux 7 (RHEL) y facilita administrar sistemas huésped implementados como máquinas virtuales o como contenedores. Con esta nueva base de código OpenVZ se acerca a Virtuozzo 7, que Parallels distribuye como producto Enterprise comercial. En la wiki de openVZ puedes comparar ambas soluciones de virtualización.
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.
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | RHEL7 (3.10) |
|---|---|
| Distribuciones de Linux compatibles | Virtuozzo Linux, RHEL7 |
| Otras plataformas | Ninguna |
| Formato de contenedor | Virtuozzo Containers |
| Licencia | OpenVZ: GNU GPL v.2, Virtuozzo 7: licencia propietaria |
| Lenguaje de programación | C |
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.
| Ventajas | Inconvenientes |
|---|---|
| Con OpenVZ y Virtuozzo, Parallels presenta una distribución de Linux optimizada para escenarios de virtualización. | OpenVZ y Virtuozzo crean contenedores para operar sistemas operativos completos. Si se busca una alternativa profesional a Docker para aislar procesos independientes, es mejor recurrir a otra plataforma. |
| Con OpenVZ y Virtuozzo se pueden operar máquinas virtuales y contenedores de sistemas con la mínima sobrecarga. | El empleo de OpenVZ y Virtuozzo solo es posible con las distribuciones Linux RHEL7 y Virtuozzo Linux. |
runC
En el caso de runC no se trata tanto de una alternativa a Docker como de un desarrollo lateral que se desvía del entorno de ejecución para contenedores desarrollado por Docker para acabar convirtiéndose en un proyecto open source independiente bajo la tutela de la Open Container Initiative (OCI).
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:
Requisitos del sistema y sistemas compatibles
| Núcleo de Linux necesario | Todos |
|---|---|
| Distribuciones de Linux compatibles | Todas las distribuciones normales de Linux |
| Otras plataformas | Ninguna |
| Formato del contenedor | OCI Bundle |
| Licencia | Apache 2.0 |
| Lenguaje de programación | Go |
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.
| Ventajas | Inconvenientes |
|---|---|
| runC está basado en el estándar de facto de la Open Container Initiative (OCI). | Necesita herramientas externas para poder generar imágenes de los contenedores. |
Tabla comparativa de alternativas a Docker
La siguiente tabla permite cotejar las soluciones presentadas como alternativas a Docker en función de sus características más destacadas:
| Docker | rkt | LXC | LXD | |
|---|---|---|---|---|
| Tecnología de virtualización | En el nivel del sistema operativo | En el nivel del sistema operativo, hipervisor | En el nivel del sistema operativo | En el nivel del sistema operativo |
| Full system container | No | No | Sí | Sí |
| Contenedor de aplicaciones | Sí | Sí | No | No |
| Licencia | Apache 2.0 | Apache 2.0 | GNU LGPLv2.1+ | Apache 2.0 |
| Formato del contenedor | Docker Container | appc, DockerContainer | Linux Container (LXC) | Linux Container (LXC) |
| Plataformas compatibles | Linux, Windows, macOS, Microsoft Azure, Amazon Web Services (AWS) | Linux, Windows, macOS | Linux | Linux |
| Último lanzamiento | Abril de 2017 | Febrero de 2017 | Enero de 2017 | Marzo de 2017 |
| El núcleo de Linux requiere un parche | No | No | No | No |
| Lenguaje de programación | Go | Go | C, Python 3, Shell, Lua | Go |
| Linux-VServer | OpenVZ | runC | |
|---|---|---|---|
| Tecnología de virtualización | En el nivel del sistema operativo | En el nivel del sistema operativo, hipervisor | En el nivel del sistema operativo |
| Full system container | Sí | Sí | No |
| Contenedor de aplicaciones | No | No | Sí |
| Licencia | GNU GPL v.2 | GNU GPL v.2 | Apache 2.0 |
| Formato del contenedor | Security Context | Virtuozzo Containers | OCI Bundle |
| Plataformas compatibles | Linux | Linux (solo Virtuozzo Linux, RHEL7) | Linux |
| Último lanzamiento | Abril de 2007 | Julio de 2016 | Marzo de 2017 |
| El núcleo de Linux requiere un parche | Sí | Distribucion autónoma | No |
| Lenguaje de programación | C | C | Go |
La tecnología de contenedores en otros sistemas operativos
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.
FreeBSD Jail
El principio de las “prisiones” (Jails) constituye una de las características de seguridad más destacadas del sistema operativo unix-like FreeBSD. Una prisión consiste en un entorno Chroot extendido que instala una instancia completa del sistema operativo en un directorio separado y que, en comparación con las jails de Chroot en Linux, demuestran un alto grado de aislamiento. Cada prisión dispone de su propia estructura de archivos y, en él, se limitan tanto el espacio para los procesos como los accesos a grupos de usuarios, interfaces de red y mecanismos IPC. De esta forma los procesos que tienen lugar en una prisión no pueden acceder a otros directorios o archivos externos a su entorno ni obstaculizar otros procesos en el sistema anfitrión. A cada prisión puede asignarse un nombre propio y una dirección IP propia.
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.
FreeBSD es una versión de código abierto de la Berkeley Software Distribution (BSD), una variante del sistema operativo Unix que ve la luz en 1997 en la Universidad de California en Berkeley.
| Ventajas | Inconvenientes |
|---|---|
| Optimizado para la virtualización de sistemas completos. | No soporta el aislamiento de procesos individuales como Docker. |
| Para virtualizar con prisiones se necesita un sistema BSD (NetBSD, FreeBSD y OpenBSD). |
Oracle Solaris Zones
Solaris también permite instalar varios entornos de ejecución protegidos en un sistema operativo, que aquí se denominan “zonas”, que comparten el núcleo del sistema operativo. Estas zonas pueden diferenciarse en globales y no globales:
- Zonas globales: cada instalación de Solaris contiene una zona global que actúa de sistema operativo estándar y se usa para el control administrativo del sistema. En la zona global se ejecutan todos los procesos del sistema, siempre y cuando no se hayan desplazado a zonas no globales.
- Zonas no globales: como zonas no globales se entienden los entornos virtuales independientes que se crean dentro de la zona global de Solaris. Cada una de estas zonas no globales se aísla utilizando una prisión Chroot modificada de forma similar a FreeBSD, asignándoles un nombre de host propio y una tarjeta de red virtual. Los recursos de hardware se distribuyen por Fair Share Scheduling o se reparten en el marco de la administración de recursos.
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.
| Ventajas | Inconvenientes |
|---|---|
| La implementación nativa de las zonas de Solaris permite operar entornos virtuales eficientemente con una mínima sobrecarga. | Las zonas de Solaris solo se pueden ejecutar en el sistema operativo propietario Oracle Solaris o en su variante de código abierto OpenSolaris. |
Virtualización con contenedores en sistemas Windows
Desde que se integró un puerto Docker nativo en Windows Server 2016, los contenedores han hecho su entrada en el universo Microsoft. Para ello, el núcleo del SO se amplió con nuevas funcionalidades en estrecha colaboración con el equipo de desarrollo de la famosa tecnología de contenedores. Estas funciones, similares a los Control Groups y a los espacios de nombres en Linux, permiten una virtualización en el nivel del sistema operativo con un uso moderado de los 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.
