Docker y otros container: más allá de la vi­r­tua­li­za­ción

Mientras que la vi­r­tua­li­za­ción co­n­ve­n­cio­nal se apoya en el llamado hi­pe­r­vi­sor (hy­pe­r­vi­sor), también llamado monitor de máquina virtual, que di­s­tri­bu­ye de forma pro­po­r­cio­nal el hardware del sistema de alo­ja­mie­n­to entre los sistemas ope­ra­ti­vos invitados, la vi­r­tua­li­za­ción mediante co­n­te­ne­do­res, por el contrario, no inicia ningún sistema operativo adicional. En su lugar, el sistema operativo en común forma eje­m­pla­res aislados de sí mismo, es decir, co­n­te­ne­do­res virtuales que crean un entorno de tiempo completo para las apli­ca­cio­nes.

Un co­n­te­ne­dor de software, en su co­n­ce­p­ción más básica, puede co­n­si­de­rar­se como apli­ca­ción para el servidor. Para poder instalar una apli­ca­ción, el co­n­te­ne­dor se carga en el ordenador en un formato portable o imagen (Image) que incluye todos los datos ne­ce­sa­rios para su fu­n­cio­na­mie­n­to y, en el ordenador, se inicia en un entorno virtual. Prá­c­ti­ca­me­n­te todos los sistemas ope­ra­ti­vos soportan la im­ple­me­n­ta­ción de co­n­te­ne­do­res de apli­ca­cio­nes: en Windows se utiliza el software Virtuozzo creado por Parallels, FreeBSD tiene el entorno de vi­r­tua­li­za­ción Jails y Linux soporta co­n­te­ne­do­res en la forma de OpenVZ y LXC (LinuX Co­n­tai­ne­rs). Para la gran mayoría de usuarios, sin embargo, no es sino a través de pla­ta­fo­r­mas como Docker o rkt como la vi­r­tua­li­za­ción de sistemas ope­ra­ti­vos comienza a ser factible, ya que añaden a esta te­c­no­lo­gía algunas funciones que facilitan el uso de estos co­n­te­ne­do­res.

Es in­e­vi­ta­ble haberse en­co­n­tra­do alguna vez con Docker si se trabaja en el ámbito de la vi­r­tua­li­za­ción de sistemas ope­ra­ti­vos. Este proyecto open source se ha co­n­ve­r­ti­do en pocos años y, gracias a una ex­trao­r­di­na­ria operación de marketing, en sinónimo de te­c­no­lo­gía de co­n­te­ne­do­res. Explicado bre­ve­me­n­te, Docker es una he­rra­mie­n­ta para iniciar, detener y gestionar co­n­te­ne­do­res mediante comandos y se basa en técnicas propias de Linux como Cgroups y Na­me­s­pa­ces para poder separar los recursos de cada co­n­te­ne­dor. Si al comienzo se usaba la interfaz LXC del kernel de Linux, hoy se ejecuta con Li­b­co­n­ta­nier, una interfaz de pro­gra­ma­ción de­sa­rro­lla­da por Docker.

Una ca­ra­c­te­rí­s­ti­ca de­s­ta­ca­ble de este co­n­te­ne­dor es el Docker Hub, un re­po­si­to­rio donde los usuarios de Docker pueden compartir las imágenes (co­n­te­ne­do­res) que han creado con otros usuarios. Para los usuarios de Linux, instalar uno de estos co­n­te­ne­do­res es tan fácil como descargar una apli­ca­ción desde la App Store. La descarga desde el Docker Hub se realiza mediante comandos y se ejecuta en el propio sistema.

La co­m­pe­te­n­cia de Docker container es la solución rkt, que soporta tanto las imágenes de Docker como el formato propio App Container Images (ACI).

Los co­n­te­ne­do­res de apli­ca­cio­nes “em­pa­que­tan” los recursos ne­ce­sa­rios para el fu­n­cio­na­mie­n­to de una apli­ca­ción para facilitar su uso a ad­mi­ni­s­tra­do­res y de­sa­rro­lla­do­res, si­m­pli­fi­ca­n­do tanto la in­s­ta­la­ción como la puesta en marcha de programas muy complejos. Sin embargo, las mayores ventajas de tales co­n­te­ne­do­res radican, sobre todo, en la gestión y en la au­to­ma­ti­za­ción de software basado en co­n­te­ne­do­res.

• In­s­ta­la­ción más sencilla: los co­n­te­ne­do­res de software se inician a partir de imágenes o re­pre­se­n­ta­cio­nes portables de un co­n­te­ne­dor, in­clu­ye­n­do un programa y todos los co­m­po­ne­n­tes re­que­ri­dos (como librerías, soporte o archivos de co­n­fi­gu­ra­ción). De esta forma se compensan las di­fe­re­n­cias entre sistemas ope­ra­ti­vos. Su in­s­ta­la­ción se reduce a la in­tro­du­c­ción de una línea de comando.

• In­de­pe­n­die­n­te de la pla­ta­fo­r­ma: las imágenes se pueden tra­n­s­po­r­tar có­mo­da­me­n­te de un sistema a otro y se ca­ra­c­te­ri­zan por una co­n­si­de­ra­ble in­de­pe­n­de­n­cia de la pla­ta­fo­r­ma. Lo único que se necesita para iniciar un co­n­te­ne­dor desde una imagen es un sistema operativo que soporte co­n­te­ne­do­res.

• Pérdidas por vi­r­tua­li­za­ción mínimas: con un Linux y Docker container, la in­s­ta­la­ción de co­n­te­ne­do­res requiere alrededor de 100 MB y unos pocos minutos, aunque no es solo esto a lo que se oponen los ad­mi­ni­s­tra­do­res de sistemas. Mientras que la vi­r­tua­li­za­ción de hardware trae consigo una pérdida de re­n­di­mie­n­to para el hi­pe­r­vi­sor y otros sistemas ope­ra­ti­vos, los co­n­te­ne­do­res, al pre­s­ci­n­dir de todo esto, reducen esta pérdida al mínimo. Aún más, si el arranque (booting) de una máquina virtual puede durar varios minutos, las apli­ca­cio­nes están di­s­po­ni­bles enseguida.

• Apli­ca­cio­nes aisladas: cada programa funciona in­de­pe­n­die­n­te­me­n­te de otros co­n­te­ne­do­res, de forma que apli­ca­cio­nes con re­que­ri­mie­n­tos opuestos pueden funcionar en paralelo en el mismo sistema.

• Ad­mi­ni­s­tra­ción y au­to­ma­ti­za­ción unitarias: debido a que en una pla­ta­fo­r­ma como Docker todos los co­n­te­ne­do­res son ge­s­tio­na­dos con las mismas he­rra­mie­n­tas, es posible au­to­ma­ti­zar todas las apli­ca­cio­nes de manera ce­n­tra­li­za­da. Por esto, estas so­lu­cio­nes están indicadas sobre todo para ar­qui­te­c­tu­ras de servidor en las cuales los co­m­po­ne­n­tes están di­s­tri­bui­dos en varios se­r­vi­do­res, de forma que se carga con los pesos de in­s­ta­n­cias di­fe­re­n­tes. En estos ámbitos de apli­ca­ción, el Docker container dispone de he­rra­mie­n­tas con las cuales co­n­fi­gu­rar au­to­ma­ti­s­mos. Esto po­si­bi­li­ta, por ejemplo, iniciar in­s­ta­n­cias nuevas de forma au­to­má­ti­ca en momentos puntuales de so­bre­ca­r­ga. Google ofrece Ku­be­r­ne­tes, un software a la imagen de Docker para la or­que­s­ta­ción de grandes clústers de co­n­te­ne­do­res.

Dejar de usar sistemas ope­ra­ti­vos separados implica una mejora en el re­n­di­mie­n­to de la vi­r­tua­li­za­ción con co­n­te­ne­do­res, pero significa también tener un nivel más bajo de seguridad. Si, en el caso de la vi­r­tua­li­za­ción co­n­ve­n­cio­nal de hardware, las vu­l­ne­ra­bi­li­da­des del sistema operativo ge­ne­ra­l­me­n­te afectan a una sola máquina virtual, en una vi­r­tua­li­za­ción del sistema operativo tienen efecto sobre todos los co­n­te­ne­do­res. Así pues, los co­n­te­ne­do­res no son tan he­r­mé­ti­cos como las máquinas virtuales con sistema operativo propio. Y, aunque en el primer caso un ataque al hi­pe­r­vi­sor puede ocasionar graves daños, al ser menos complejos, no logran tanto alcance como en el caso de un kernel de Linux. En co­n­se­cue­n­cia, aunque los co­n­te­ne­do­res co­n­s­ti­tu­yen una al­te­r­na­ti­va para la vi­r­tua­li­za­ción de hardware, de momento no la pueden sustituir por completo.