¿Qué es LXD? Gestiona co­n­te­ne­do­res con Linux Container Daemon

LXD, forma abreviada de Linux Container Daemon, es una he­rra­mie­n­ta de gestión de los co­n­te­ne­do­res del sistema operativo Linux. Ha sido de­sa­rro­lla­do por Canonical, que también produce Ubuntu. Ac­tua­l­me­n­te la compañía continúa de­sa­rro­lla­n­do LXD y guía la dirección del proyecto.

LXD es una te­c­no­lo­gía hermana de LXC, forma abreviada de Linux Co­n­tai­ne­rs. LXC es una te­c­no­lo­gía de vi­r­tua­li­za­ción a nivel de sistema operativo basada en co­n­te­ne­do­res. LXC combina espacios de nombres aislados y los “cgroups” del kernel de Linux para crear entornos aislados para ejecutar código. Hi­s­tó­ri­ca­me­n­te, LXC también fue el origen de la popular te­c­no­lo­gía de vi­r­tua­li­za­ción Docker.

Uno de los objetivos básicos que había detrás el de­sa­rro­llo de LXD era hacer la gestión de co­n­te­ne­do­res LXC lo más cómoda posible, como es habitual en el caso de las máquinas virtuales. Sin embargo, el enfoque basado en co­n­te­ne­do­res ofrece un re­n­di­mie­n­to superior al de las máquinas virtuales.

Uti­li­za­n­do LXD, los co­n­te­ne­do­res del sistema operativo Linux pueden ser co­n­fi­gu­ra­dos y co­n­tro­la­dos con un conjunto de comandos pre­de­fi­ni­dos. Por lo tanto, es muy adecuado para au­to­ma­ti­zar la gestión de co­n­te­ne­do­res y, a menudo, es utilizado para so­lu­cio­nes cloud y data centers.

• Seguridad: los co­n­te­ne­do­res se ejecutan en espacios de nombres aislados y solo pueden acceder a de­te­r­mi­na­dos recursos pre­de­fi­ni­dos.
• Es­ca­la­bi­li­dad: con LXD, puedes gestionar co­n­te­ne­do­res in­di­vi­dua­les en tu propio ordenador o miles de co­n­te­ne­do­res re­pa­r­ti­dos en distintos entornos.
• Usa­bi­li­dad intuitiva: LXD pro­po­r­cio­na una API clara y sencilla y un cliente con línea de comandos.
• Basado en imágenes de Linux: LXD funciona con todas las imágenes de Linux y, por lo tanto, se beneficia de la gran cantidad de in­s­ta­la­cio­nes de Linux exi­s­te­n­tes.
• Control de recursos so­fi­s­ti­ca­do: se es­ta­ble­cen límites para la CPU, la memoria principal, el uso de la red, el al­ma­ce­na­mie­n­to masivo y los recursos del kernel.
• Acceso al hardware del sistema: si la co­n­fi­gu­ra­ción lo permite, los co­n­te­ne­do­res pueden acceder a di­s­po­si­ti­vos USB, GPU y medios de al­ma­ce­na­mie­n­to masivo.
• Gestión de red: la co­n­fi­gu­ra­ción permite crear puentes y túneles de red.
• Gestión de al­ma­ce­na­mie­n­to masivo: LXD admite varios backends de al­ma­ce­na­mie­n­to, grupos de al­ma­ce­na­mie­n­to y volúmenes de al­ma­ce­na­mie­n­to.

La principal ventaja de LXD es que permite la vi­r­tua­li­za­ción basada en co­n­te­ne­do­res de un sistema operativo Linux completo. De esta manera, une la comodidad de las máquinas virtuales con el re­n­di­mie­n­to de los co­n­te­ne­do­res.

A di­fe­re­n­cia de la mayoría de los casos de uso basados en Docker, el enfoque no está en vi­r­tua­li­zar una sola apli­ca­ción (vi­r­tua­li­za­ción de apli­ca­cio­nes). Por contra, la imagen del sistema Linux sirve de base para cada co­n­te­ne­dor LXD (vi­r­tua­li­za­ción del sistema). Esto es una gran ventaja para el ad­mi­ni­s­tra­dor, ya que le da acceso a una gran cantidad de di­s­tri­bu­cio­nes de Linux di­s­po­ni­bles de forma gratuita y le permite el uso de una gran variedad de he­rra­mie­n­tas ya exi­s­te­n­tes.

LXD tiene una de­s­ve­n­ta­ja en co­m­pa­ra­ción con otras te­c­no­lo­gías de vi­r­tua­li­za­ción: dado que todos los co­n­te­ne­do­res que se ejecutan en un host tienen acceso al mismo núcleo de Linux, el daemon LXD solo está di­s­po­ni­ble con Linux. Además, Linux es el único sistema operativo que se puede vi­r­tua­li­zar como sistema operativo invitado. Sin embargo, la línea de comandos continúa fu­n­cio­na­n­do en otros sistemas ope­ra­ti­vos que no son Linux.

Se puede acceder a la REST API del daemonLXD a través de la red, lo que significa que los co­n­te­ne­do­res se pueden copiar o mover entre dos or­de­na­do­res. Y lo que es más im­po­r­ta­n­te, LXD admite la creación de eco­si­s­te­mas de or­de­na­do­res que agrupan todas las unidades y las co­n­vie­r­ten en un súper ordenador virtual.

El co­m­po­ne­n­te clave de LXD es el daemon con pri­vi­le­gios que se ejecuta en el sistema anfitrión Linux (también sistema host). El daemon de LXD pro­po­r­cio­na una REST API a través de un socket Linux local. A través de los ajustes de co­n­fi­gu­ra­ción, también se puede acceder al daemon usando la red. LXD usa LXC como backend a través de la librería liblxc y de sus Go bindings.

Los clientes in­ter­ac­túan con el daemon uti­li­za­n­do la REST API. La API define un lenguaje que se puede utilizar para crear, controlar y cambiar co­n­te­ne­do­res. El cliente más simple es la he­rra­mie­n­ta de línea de comandos oficiales. El cliente de línea de comando pro­po­r­cio­na comandos para ope­ra­cio­nes ha­bi­tua­les y accede a la REST API in­te­r­na­me­n­te.

A co­n­ti­nua­ción, hemos agrupado algunos comandos básicos LXD. Presta atención a que el nombre de los comandos LXD es lxc, no lxd. Puedes probar los comandos sin instalar el cliente de línea de comandos en tu sistema. Si­m­ple­me­n­te utiliza la interfaz basada en la Web del proyecto li­nu­x­co­n­tai­ne­rs.org.

LXD ge­ne­ra­l­me­n­te se puede instalar en cualquier sistema Linux moderno. Se utiliza en or­de­na­do­res privados, así como en pla­ta­fo­r­mas de co­mpu­tación cloud y data centers. El objetivo principal es, a largo plazo, vi­r­tua­li­zar todo un sistema operativo Linux. Por lo tanto, LXD contrasta con Docker, donde el enfoque está más en co­n­te­ne­do­res de corta duración que contienen una sola apli­ca­ción. Según Stéphane Graber, de­sa­rro­lla­dor de LXD ,:

El cliente de línea de comandos incluido sirve para ad­mi­ni­s­trar un pequeño número de co­n­te­ne­do­res. No obstante, no está diseñado para gestionar una gran cantidad de co­n­te­ne­do­res en numerosos hosts di­s­tri­bui­dos. En este caso, re­co­me­n­da­mos recurrir a co­ne­xio­nes en las pla­ta­fo­r­mas OpenStack y Ope­n­Ne­bu­la.

Las partes pri­n­ci­pa­les de LXD son el ya me­n­cio­na­do daemon, la REST API pro­po­r­cio­na­da, y la línea de comandos. A co­n­ti­nua­ción, veremos los pri­n­ci­pa­les elementos que se utilizan con LXD.

El co­n­te­ne­dor es la principal ab­s­tra­c­ción que aporta LXD. Un co­n­te­ne­dor LXD incluye las si­guie­n­tes pro­pie­da­des:

• Un sistema de archivos de Linux
• Ajustes de co­n­fi­gu­ra­ción como límites de recursos, variables de entorno, opciones de seguridad, etc.
• Di­s­po­si­ti­vos de red y de al­ma­ce­na­mie­n­to masivo
• Perfil de co­n­fi­gu­ra­ción, del cual el co­n­te­ne­dor hereda los ajustes
• Pro­pie­da­des generales como la ar­qui­te­c­tu­ra del co­n­te­ne­dor, el nombre y la in­di­ca­ción de si el co­n­te­ne­dor es de corta o larga duración
• Estado de fu­n­cio­na­mie­n­to, como re­n­di­mie­n­to de la red, uso de memoria, etc.

Como es habitual con otras te­c­no­lo­gías de vi­r­tua­li­za­ción, las capturas se pueden crear desde un co­n­te­ne­dor. Una captura es idéntica al co­n­te­ne­dor su­b­ya­ce­n­te. Son in­mu­ta­bles, lo que significa que no se pueden cambiar. Solo se pueden cambiar de nombre y eliminar. Un co­n­te­ne­dor se puede restaurar de forma idéntica en función de una captura.

Aunque LXD es una te­c­no­lo­gía basada en co­n­te­ne­do­res, la imagen del sistema Linux está in­vo­lu­cra­da en la creación de co­n­te­ne­do­res. Cada co­n­te­ne­dor LXD deriva, por de­fi­ni­ción, de una imagen.

Las imágenes no­r­ma­l­me­n­te son di­s­tri­bu­cio­nes de Linux sin modificar, como es el caso de las máquinas virtuales o las in­s­ta­n­cias cloud. Una imagen puede ide­n­ti­fi­car­se por su hash SHA256 único. Para facilitar las cosas a los usuarios humanos, a las imágenes se les pueden asignar nombres de alias.

Las imágenes de Linux se pueden extraer de varias fuentes para su uso con LXD. Los si­guie­n­tes se­r­vi­do­res de imágenes están pre­de­fi­ni­dos en LXD:

• ubuntu: pro­po­r­cio­na imágenes estables de Ubuntu
• ubuntu-daily: pro­po­r­cio­na co­m­pi­la­cio­nes diarias de imágenes de Ubuntu
• images: pro­po­r­cio­na una variedad de imágenes de otras di­s­tri­bu­cio­nes de Linux y es ad­mi­ni­s­tra­do por la comunidad

Las imágenes de­s­ca­r­ga­das por el daemon se guardan au­to­má­ti­ca­me­n­te en una caché, de modo que en casos de uso repetido están di­s­po­ni­bles in­me­dia­ta­me­n­te. Si no está co­n­fi­gu­ra­do con otros pa­rá­me­tros, LXD ve­ri­fi­ca­rá la versión de las imágenes de­s­ca­r­ga­das y cargará nuevas versiones si es necesario. Similar al concepto de Vagrant box, un co­n­te­ne­dor existente se puede publicar como una nueva imagen con LXD.

Un perfil LXD agrupa varias opciones de co­n­fi­gu­ra­ción de co­n­te­ne­do­res. Se puede aplicar un perfil a varios co­n­te­ne­do­res; además, se pueden aplicar varios perfiles su­ce­si­va­me­n­te a un solo co­n­te­ne­dor. En el tra­n­s­cu­r­so de este proceso, se pueden so­bre­s­cri­bir los valores de co­n­fi­gu­ra­ción definidos. Así es como se pueden crear fá­ci­l­me­n­te familias de co­n­te­ne­do­res. LXD está di­s­po­ni­ble con dos perfiles:

• El perfil default se aplica au­to­má­ti­ca­me­n­te a los co­n­te­ne­do­res si no se ha es­ta­ble­ci­do un perfil al­te­r­na­ti­vo. Este perfil contiene ajustes de co­n­fi­gu­ra­ción básicos, como el di­s­po­si­ti­vo de red eth0 del co­n­te­ne­dor.
• El perfil docker sirve para co­n­fi­gu­rar un co­n­te­ne­dor LXD destinado a alojar un co­n­te­ne­dor Docker. El perfil solicita al co­n­te­ne­dor LXD que cargue los módulos del kernel ne­ce­sa­rios y es­ta­ble­z­ca la co­n­fi­gu­ra­ción del di­s­po­si­ti­vo. También activa el ani­da­mie­n­to de co­n­te­ne­do­res.

LXD es una red daemon, lo que significa que el cliente de línea de comandos puede co­mu­ni­car­se con varios se­r­vi­do­res LXD remotos y se­r­vi­do­res de imágenes. Se pueden co­n­fi­gu­rar varios se­r­vi­do­res como remotos. Así es como los co­n­te­ne­do­res exi­s­te­n­tes se pueden copiar y mover entre se­r­vi­do­res LXD; y es a través de controles remotos que se habilita el acceso al servidor de imágenes. Además de los se­r­vi­do­res de imágenes me­n­cio­na­dos an­te­rio­r­me­n­te, el cliente de línea de comandos también conoce el control remoto local. Esto facilita la co­mu­ni­ca­ción con el daemon local LXD uti­li­za­n­do un socket UNIX.

Hoy existe un amplio espectro de te­c­no­lo­gías de vi­r­tua­li­za­ción que, en teoría, podrían usarse como al­te­r­na­ti­vas a LXD. Se di­fe­re­n­cian en función de varios criterios y se pueden dividir en dos grupos pri­n­ci­pa­les: he­rra­mie­n­tas de vi­r­tua­li­za­ción tra­di­cio­na­les basadas en máquinas virtuales y te­c­no­lo­gías basadas en co­n­te­ne­do­res. LXD es una excepción a esta se­g­me­n­ta­ción, ya que es un enfoque híbrido que vi­r­tua­li­za todo un sistema operativo Linux mediante co­n­te­ne­do­res.

Algunas he­rra­mie­n­tas de vi­r­tua­li­za­ción requieren que Linux se utilice como sistema anfitrión (host); otros pueden eje­cu­tar­se en cualquier sistema operativo. Algunos solo admiten Linux como sistema invitado, mientras que otros admiten varios sistemas. Muchas te­c­no­lo­gías basadas en co­n­te­ne­do­res se centran pri­n­ci­pa­l­me­n­te en la vi­r­tua­li­za­ción de apli­ca­cio­nes, mientras que las máquinas virtuales siempre in­vo­lu­cran un sistema operativo completo.

Dado que LXD se basa en LXC, es posible utilizar una in­s­ta­la­ción LXC “desnuda” como al­te­r­na­ti­va a LXD. Sin embargo, es probable que la ex­pe­rie­n­cia sea menos cómoda. Al no existir un daemon sin LXD, la vi­r­tua­li­za­ción no se puede controlar en la red. Y tampoco habrá una REST API que sirva como interfaz uniforme.

Entre las he­rra­mie­n­tas de vi­r­tua­li­za­ción más conocidas, co­n­tai­ne­rd es más co­m­pa­ra­ble a LXD. También funciona como un daemon que pro­po­r­cio­na una API. Esto hace posible ad­mi­ni­s­trar co­n­te­ne­do­res en la red, igual que con LXD. La te­c­no­lo­gía está integrada en Docker y se utiliza ha­bi­tua­l­me­n­te.

En general, deberías elegir la te­c­no­lo­gía adecuada en función de tus ne­ce­si­da­des es­pe­cí­fi­cas. A co­n­ti­nua­ción, ofrecemos una de­s­cri­p­ción general de las te­c­no­lo­gías de vi­r­tua­li­za­ción más uti­li­za­das.