Contenedores virtuales

El auge de la virtualización en la década pasada dió cabida a la abstracción «contenedor», entendido como un sistema más o menos autónomo que comparte los recursos del servidor real de toda la vida. Esa abstracción ofrece muchas ventajas: mejor aprovechamiento del servidor, poder migrar más fácilmente un sistema de un servidor a otro, aislar aplicaciones y/o servicios dentro del contenedor…

Como ya sucedió con la dualidad proceso-hilo, en este panorama se hacían necesarios contenedores cada vez más ligeros. Las contenedores implementados como máquinas virtuales eran un fiel reflejo se los servidores clásicos, emulando sus componentes hardware. Pero, en muchas ocasiones más que tanta fidelidad resultaba preferible más agilidad.

En 2008 surgió la primera iniciativa en esa linea: los contenedores Linux (LxC). La tecnología estaba ahí, pero igual que en su día fue necesario el empujón de VMware para hacer más accesible la virtualización clásica, no fue hasta la entrada en escena de Docker que estos contenedores Linux llegaron a las masas.

Con lo cual, hoy por hoy dispnemos de múltiples opciones de virtualización. Dentro de las de código abierto, las más apetecibles son VirtualBox, Xen y Docker. Leamos una pequeña comparativa de las dos últimas.

Xen

El supervisor corre en un «contenedor maestro», dom0, el cual gestiona a los demás «contenedores de usuario», domU. Cada uno ejecuta su propio kernel y el aislamiento entre ellos es casi total. Con las xen-tools es fácil crear un domU: se especifican los recursos (CPU, RAM), los discos virtuales y la configuración de red y automáticamente se inicia la instalación desatendida del sistema operativo (típicamente Debian). Dependiendo de los recursos, el contenedor domU está disponible en el orden de minutos.

De entrada, los recursos del dom0 y los domU son independientes, con lo cual conviene planificar un poco durante la instalación inicial. Existen opciones como el ballooning que otorgan mayor flexibilidad en este punto.

Para clonar o migrar el contenedor, basta replicar los discos virtuales y el fichero de configuración del domU. Normalmente los discos virtuales son del orden de gigas, con lo cual el proceso de copia está en el orden de minutos (con hardware estándar)

Nuevo: LightVM promete dar a la virtualización basada en Xen la agilidad de la basada en contenedores.

Docker

En Docker, se comparten muchas cosas. En primer lugar, los contenedores comparten el kernel del servidor donde corre Docker (que a su vez, puede ser también un contenedor, por ejemplo una máquina VirtualBox)

Docker comparte la imagen (que contiene los ficheros del sistema operativo) entre los contenedores que usen el mismo sistema operativo, lo cual contribuye a la ligereza generalizada de Docker.

Docker también comparte la filosofía de git, ofreciendo un repositorio de imágenes con el que aplicar las operaciones estrella: commit, diff, push, pull. El concepto repositorio tiene otra gran ventaja competitiva: resulta fácil poner en marcha una imagen sobre casi cualquier servidor. Si el servidor tiene instalado Docker, basta con descargar la imagen con una operación pull y ejecutarla. Otras soluciones como VMware o Virtualbox definen formatos de imagen estándar, pero en la práctica pueden resultar poco prácticos. Por ejemplo, en Amazon AWS (basado en Xen) no se puede ejecutar VMWare.

Esta filosofía git supone que lo habitual sea «descargar» un contenedor y personalizarlo si es necesario, más que crearlo de cero. El tiempo necesario para tener disponible el «contenedor primigenio» ronda los minutos, igual que en Xen. Pero a partir de ahí, cada nuevo contenedor es cuestión de segundos.

Aunque se podría aprovechar el repositorio para gestionar las configuraciones, resulta más conveniente continuar utilizando herramientas específicas como salt stack, puppet o chef. Aspectos del sistema operativo como las cuentas de usuario «viven» en la propia imagen y no resulta práctico «contaminar» el repositorio de imágenes con commits que vayan registrando esos cambios. De hecho, el modelo va más en la linea de descargar (o construir) una imagen «de sólo lectura» y guardar el estado aparte, aprovechando el mapeo del sistema de ficheros del servidor subyacente.

En el caso de los logs, la cosa se complica. Una solución es usar Portable Services

Gracias al espíritu de compartir, «clonar» un contenedor es casi instántaneo. Una migración aprovechando el repositorio puede ser rápida, cuando sólo hay que transferir las diferencias. En el caso de que se lleve a cabo exportando e importando la imagen, nos encontraríamos en el mismo escenario que en Xen (copiar «todo»).

Por defecto, también se mapean puertos a fin de economizar direcciones IP. No obstante, si un contenedor necesita una IP propia es posible configurarlo.

La única «pega» es que Docker necesita kernel 3.8 (o más reciente). Muchas distribuciones cumplen este requisito. En el caso de Debian 7, aún va por la 3.2, con lo cual habría que actualizarlo vía backports o similar.