Mencione el nombre una compañía tecnológica, cualquier compañía, y seguro que está invirtiendo en contenedores. Google, por supuesto. Microsoft, claro. IBM, compruébelo. Pero, sólo porque los contenedores son extremadamente populares no significa que las máquinas virtuales hayan pasado de moda.
Sí, los contenedores pueden ayudar a su empresa a empaquetar un montón de aplicaciones en un único servidor físico, igual que una máquina virtual (VM). La tecnología de contenedores, como Docker, supera a las máquinas virtuales en lo que se refiere a la nube o los centros de datos. Las máquinas virtuales ocupan gran cantidad de recursos del sistema. Cada VM no sólo necesita una copia completa del sistema operativo, sino también una copia virtual de todo el hardware que el sistema operativo necesita para ejecutarse. Esto se suma rápidamente a una gran cantidad de RAM y de ciclos CPU. En contraste, todo lo que requiere un contenedor es un sistema operativo, programas y bibliotecas de soporte y los recursos del sistema para ejecutar un programa específico.
En la práctica, esto significa que se pueden poner dos o tres veces más aplicaciones en un único servidor con los contenedores que con las máquinas virtuales. Además, con los contenedores se puede crear un ambiente operativo consistente y portátil para el desarrollo, la prueba y el despliegue.
Si esto fuera todo lo que tienen que ofrecer los contenedores frente a las máquinas virtuales, estaríamos escribiendo un obituario de éstas. Pero hay mucho más que cuántas apps se pueden poner en una caja.
Problema número 1 de los contenedores: La seguridad
El principal problema, que a menudo se pasa por alto, es la seguridad. Como comentó Daniel Walsh, ingeniero de seguridad en RedHat, que trabaja principalmente en Docker: los contenedores “no contienen”. Tomemos a Docker, por ejemplo, que utiliza libcontainers como su tecnología de contenedores. Los libcontainers dan acceso a cinco espacios de nombres –procesos, red, montaje, nombre de equipo y memoria compartida– para trabajar con Linux. Esto, dentro de lo que cabe, está bien, pero hay un número importante de subsistemas del núcleo de Linux fuera del contenedor.
Esto incluye dispositivos, SELinux, Cgroups y todos los sistemas de archivos /sys. Lo que significa que si un usuario o aplicación tiene privilegios de superusuario dentro del contenedor, el sistema operativo subyacente podría, en teoría, ser crackeado.
Ahora, existen muchas maneras de proteger Docker y otras tecnologías de contenedores. Por ejemplo, usted puede montar un sistema de archivos sys como de sólo-lectura, forzando a los procesos del contendor a escribir sólo en algunos sistemas de archivos del contenedor específicos, y configurar el espacio de nombres de red sólo si se conecta con una intranet privada especificada y así sucesivamente. Sin embargo, este proceso no se construye de forma predeterminada, se necesita sudar para proteger los contenedores.
La regla básica es que ha de tratar a los contenedores como lo haría con cualquier otra aplicación de servidor, tal y como explica Walsh: reducir los privilegios lo más rápidamente posible; ejecutar sus servicios como no-root siempre que sea posible; y tratar los root de dentro del contenedor como si fuera un root de fuera de éste.
Otro problema de seguridad es que mucha gente está lanzando aplicaciones en contenedores, algunas peores que otras. Si, por ejemplo, se es perezoso y se instala el primer contenedor que le cae en las manos, es posible que traigan un Troyano a sus servidores. Es necesario que el equipo entienda que no pueden descargar aplicaciones de Internet como si se estuvieran descargando juegos en su smartphone.
Otras preocupaciones sobre los contenedores
Si podemos solucionar el problema de la seguridad, ¿los contenedores lo dominarán todo? Pues no. Hay que considerar otros aspectos sobre los contenedores. Rob Hirschfeld, CEO de RackN y miembro fundador de la OpenStack Foundation, observó que: “El empaquetado es difícil todavía: crear una caja cerrada ayuda a resolver parte de los problemas de la superficie (los que sabemos que tenemos), pero no resuelve los problemas más profundos (los que no sabemos de qué dependen)”.
A todo esto me gustaría añadir que, si bien éste es un problema de seguridad, también es un problema de control de calidad. Es verdad que el contenedor X puede ejecutar el servidor web NGINX, pero, ¿acaso es la versión que usted quiere? ¿Incluye la actualización TCP Load Balancing? Es fácil implementar una app en un contenedor, pero si la instala en el equivocado, habrá perdido mucho tiempo.
Hay que recordar que el punto central de un contenedor es ejecutar una única aplicación. Cuantas más funcionalidades se coloquen en el contendor, más seguro es que debería estar utilizando en primer lugar una máquina virtual.
Es cierto que muchas tecnologías de contenedores, como Linux Containers (LXC) se pueden usar en lugar de las máquinas virtuales. Por ejemplo, podría usar LXC para ejecutar aplicaciones específicas para Red Hat Enterprise Linux (RHEL) 6 en lugar de RHEL 7. En general, se debería utilizar contenedores para ejecutar una sola aplicación y máquinas virtuales para ejecutar múltiples aplicaciones.
Decidir entre contenedores y máquinas virtuales
Entonces, ¿cómo decidirnos entre contenedores y máquinas virtuales? Scott S. Lowe, arquitecto de Ingeniería de VMware, sugiere que nos fijemos en el alcance de nuestro trabajo. En otras palabras, si queremos ejecutar múltiples copias de una misma app, debemos usar un contenedor. Si queremos flexibilidad o ejecutar múltiples aplicaciones debemos utilizar máquinas virtuales.
Además, los contenedores suelen “encerrarnos” en una versión particular del sistema operativo. Esto puede ser bueno: usted no debe preocuparse por las dependencias una vez las aplicaciones se estén ejecutando adecuadamente en un contenedor. Pero esto también le limita.
Con las máquinas virtuales no importa qué hipervisor esté utilizando –KVM, Hyper-V, Xen o cualquier otro–, usted puede utilizar cualquier sistema operativo. ¿Qué se necesita para ejecutar una aplicación oscura que sólo se ejecuta en QNX? Es fácil con una máquina virtual, pero no es tan simple con la actual generación de contenedores. Así que permítanme explicárselo.
¿Necesita ejecutar la máxima cantidad de aplicaciones particulares con el mínimo número de servidores? Si ese es su caso, entonces use contenedores –recuerde que deberá vigilar sus sistemas ejecutados en contenedores antes hasta que asegure la seguridad de su contenedor. En cambio, si lo que hace falta es ejecutar múltiples aplicaciones en servidores y tiene gran variedad de sistemas operativos, debería usar máquinas virtuales. Y si la seguridad es importante para su compañía, usted debería utilizar máquinas virtuales desde este momento.
En el mundo real, supongo que la mayoría de nosotros utilizaremos tanto contenedores como máquinas virtuales en nuestras nubes y centros de datos.
La economía de los contenedores a escala tiene demasiado sentido financiero para ser ignorada. Al mismo tiempo, las máquinas virtuales también tienen sus virtudes.
A medida que la tecnología de los contenedores madure –algo que espero realmente suceda,– los contenedores y las máquinas virtuales se unirán para crear un nirvana de portabilidad en la nube. Aún no estamos en ese punto, pero llegaremos.
-Steven J. Vaughan-Nichols, CIO
