LXD vs Docker

No todo lo nuevo es bueno y no todo es necesario. Con las tecnologías de contenedores, como con cualquier otra "próxima gran cosa", estamos viendo una invención desenfrenada de abstracciones de nivel superior seguido de despliegue en la producción, con una infraestructura completa de CD/CI dependiendo de él y DevOps no entiende lo que realmente hace.

Comencemos con lo que realmente eran los contenedores, históricamente. A principios de la década de 2000, FreeBSD introdujo el concepto de "cárceles" que ofrecía un nuevo entorno, como una nueva instalación del sistema operativo que ofrece toda la infraestructura de la biblioteca y kernel de FreeBSD que ya está en su lugar. Una pizarra limpia para que los desarrolladores prueben un nuevo software.

Esto está en marcado contraste con VMware, KVM o VirtualBox, como tecnologías, donde el hardware completo está virtualizado, donde, las disposiciones de su Host OS, un conjunto virtual de CPU, RAM y otros recursos. Su sistema operativo invitado se encuentra en la parte superior de esos recursos de hardware virtual. Casi todas las capas de abstracción se repiten dos veces y los recursos como RAM y CPU una vez asignados al invitado ya no están disponibles para el host (independientemente de si el invitado los usa por completo).

Contenedores Docker y Linux-Y

Con el sistema operativo virtualizado, los contenedores se pueden escasar con cuotas establecidas para su utilización de recursos. Por ejemplo, si configuramos un límite máximo de 2 GB de uso de RAM para contenedor, no podrá superarlo. Por otro lado, dado que solo hay un núcleo en el bucle, si el contenedor no usa la RAM completa, el núcleo puede poner el recurso restante para usarse en otro lugar.

El primer inconveniente de las personas que se realizan con el modelo de contenedor es que, dado que estamos virtualizando el sistema operativo y no el hardware, puede tener múltiples instancias del mismo sistema operativo y pierde la capacidad de hacer girar un sistema operativo arbitrario.

No existe un contenedor de Windows en contenedores de Linux o Linux en Windows. Docker en Windows, por ejemplo, usa Moby Linux que en realidad se está ejecutando en una VM dentro de su caja de Windows.

Sin embargo, cuando se trata de una distribución de Linux, puede hacer muchas cosas interesantes. Dado que lo que llamamos Linux es solo el núcleo y necesita una pila de bibliotecas GNU para proporcionar un entorno de sistema operativo completo, puede emular varias distribuciones como Centos, Ubuntu, Alpine en diferentes instancias de contenedores.

Esto es cierto tanto para LXD como para Docker.

Docker como mecanismo de embalaje

Docker hará a Apt, lo que APT le hizo al alquitrán. Es decir, todavía usará apt pero con una capa adicional de abstracción encima. Para entender cómo, considere el siguiente ejemplo.

Tiene una instancia de su sitio web que se ejecuta en un PHP5.6 y debe ejecutar otro servicio web en el mismo servidor utilizando PHP7.0. Ahora ejecutar dos versiones diferentes de PHP es una idea aterradora, no saber qué conflictos surgirían de ellos. Actualizar y actualizar pronto se convertirá en un esfuerzo sin esperanza.

Pero, ¿qué pasa si tuviéramos nuestra instancia web original ejecutándose dentro de un contenedor Docker?? Ahora, todo lo que necesitamos es un nuevo contenedor Docker dentro del cual podemos instalar PHP7.0 y nuestro segundo servicio web funcionará a partir de este contenedor recién hilado. Todavía usaremos APT en segundo plano, al igual que Apt usa alquitrán en segundo plano, pero Docker se aseguraría de que varias aplicaciones de diferentes contenedores no se confirmen entre sí.

Docker es especialmente útil para ejecutar aplicaciones sin estado y escuchará a las personas que dicen a menudo que no puede ejecutar más de un proceso en un contenedor. Aunque, eso es falso, ejecutar múltiples servicios de estado en una instancia de contenedor a menudo puede hacer que Docker dé resultados inconsistentes. Pronto te encontrarás reiniciando el mismo conjunto de contenedores una y otra vez.

LXD como hipervisor

Con los contenedores LXD, lo que obtiene está mucho más cerca de un sistema operativo independiente que lo que obtiene de Docker. Los contenedores de Docker comparten la misma pila de redes y almacenamiento.

Esto significa comandos básicos como silbido o ifconfig no están disponibles desde el interior de un contenedor Docker. De hecho, no puede saber casi nada sobre la red en la que se encuentra, desde el interior de ese contenedor. Docker Nat que se ejecuta en la pila de redes del host ofrece la mayor parte de la conectividad y las instalaciones como el reenvío de puertos.

Los contenedores LXD están muy por delante de la curva, admitiendo puentes de red, MacVlan y otras opciones. Sus contenedores LXD y su host forman una red privada propia y pueden comunicarse entre ellos como si estuvieran hablando con diferentes computadoras a través de una red.

Lo mismo es cierto con la pila de almacenamiento. A menudo es mucho más práctico usar LXD con grupos ZFS donde puede asignar conjuntos de datos con cuotas que limitan la utilización del almacenamiento. LXD es una competencia directa con VMware, KVM y otras tecnologías Hypervisor.

Utilizándolo, su proveedor de la nube ahora puede provocarle su contenedor personal que olería y se sentiría como un sistema operativo completo y sigue siendo barato y rápido para girar y matar, junto con todas las sutilezas de los datos persistentes que espera.

Desde la perspectiva del proveedor, las cosas también son económicas. Dado que no todos usan la carnero completa que solicitan, puede meter muchos más contenedores en el mismo metal que las máquinas virtuales.

Para los usuarios finales, puede sonar como hacer trampa al principio, pero también ganan al final, los contenedores LX son más rápidos para girar y matar, lo que hace que el proceso sea mucho más suave y "escalable" (como a las personas les gusta decir).

Puede girar contenedores en un nodo de cómputo donde reside sus datos, hacer el cálculo que desea hacer y luego destruir el contenedor dejando los datos intactos. Esto es mucho más rápido que obtener datos relevantes hasta su máquina virtual que se ejecuta en algún otro centro de datos. Esto funciona especialmente bien con ZFS en el bucle.

Tl; DR

Para resumir todo lo que sabemos, tanto LXD como Docker son tecnologías de contenedores. Docker es liviano, simplista y es adecuado para aislar aplicaciones entre sí, lo que lo hace popular entre DevOps y desarrolladores por igual. Una aplicación por contenedor de Docker.

LXD, por otro lado, está mucho mejor equipado y está mucho más cerca de un entorno de sistema operativo completo con interfaces de redes y almacenamiento. Puede ejecutar varios contenedores Docker anidados dentro de LXD, si lo desea.