La compañía Canonical ha publicado una nueva versión del sistema de gestión de contenedores LXD 5.20, que se destaca por el cambio de licencia del proyecto y la introducción de la necesidad de firmar un acuerdo CLA sobre la transferencia de derechos de propiedad del código al aceptar cambios en LXD. La licencia del código añadido a LXD por empleados de Canonical ha cambiado de Apache 2.0 a AGPLv3, mientras que el código de los colaboradores externos, sobre el cual Canonical no tiene derechos de propiedad, se mantiene bajo Apache 2.0. Dado que Canonical no puede cambiar la licencia de todo el código de LXD, el proyecto ahora se entregará bajo condiciones mixtas: parte del código bajo AGPLv3 y parte bajo Apache 2.0. La transición a la nueva licencia se explica por el deseo de unificar la licencia con otros productos de servidor de Canonical que utilizan AGPLv3.
El código de versiones anteriores sigue estando disponible bajo la licencia Apache 2.0, pero todos los cambios realizados en los componentes relicenciados se publicarán únicamente bajo la licencia AGPLv3, lo que impedirá que el fork Incus incorpore cambios de LXD sin trasladar su base de código a la licencia AGPLv3. Las licencias Apache 2.0 y AGPLv3 tienen compatibilidad unilateral, lo que significa que el código bajo licencia Apache 2.0 puede incluirse en código bajo licencia AGPLv3, pero no al revés. Este cambio significa el cese total de la colaboración entre los proyectos LXD e Incus, ya que la nueva licencia impide la transferencia de cambios de LXD a Incus, y la necesidad de firmar un acuerdo CLA impide la transferencia de cambios de Incus a LXD, lo que los desarrolladores de Incus no tienen intención de firmar.
Una característica de la licencia AGPLv3 es la introducción de restricciones adicionales para las aplicaciones que proporcionan servicios de red. Al usar componentes AGPL en el funcionamiento de los servicios de red, el desarrollador está obligado a proporcionar al usuario el código fuente de todos los cambios realizados en estos componentes, incluso si el software subyacente del servicio no se distribuye y se utiliza exclusivamente en la infraestructura interna para organizar el funcionamiento del servicio. La licencia AGPL también impone condiciones de copyleft, es decir, para incluir código AGPL de LXD en su proyecto, la base de código de su proyecto debe ser relicenciada bajo la licencia AGPL.
LXD ofrece herramientas para la gestión centralizada de contenedores y máquinas virtuales desplegadas en un clúster de varios servidores. LXD se implementa como un proceso en segundo plano que acepta solicitudes a través de la red mediante una API REST y admite varios backend de almacenamiento (árbol de directorios, ZFS, Btrfs, LVM), snapshots de estado, migración en vivo de contenedores en funcionamiento de una máquina a otra y herramientas para almacenar imágenes de contenedores. El runtime para ejecutar contenedores utiliza la herramienta LXC, que incluye la biblioteca liblxc, un conjunto de utilidades (lxc-create, lxc-start, lxc-stop, lxc-ls, etc.), plantillas para construir contenedores y un conjunto de vínculos para varios lenguajes de programación. La aislamiento se realiza mediante los mecanismos estándar del núcleo de Linux (namespaces, cgroups, Apparmor, SELinux, Seccomp). Además de LXC, LXD también utiliza componentes de los proyectos CRIU y QEMU.
Entre las nuevas funciones añadidas en LXD 5.20:
- Al crear grupos de almacenamiento basados en Cephfs, ahora es posible crear metadatos y datos para los grupos OSD (Object Storage Daemon), utilizando los parámetros cephfs.create_missing, cephfs.meta_pool y cephfs.data_pool. Por ejemplo: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- En el paquete snap de LXD, se añadió la opción de configurar la prioridad de arranque desde diferentes discos al utilizar el modo security.csm.
- Se añadió un modo de depuración (boot.debug_edk2=true) en el firmware EDK2 UEFI para diagnosticar problemas durante el arranque máquinas virtuales. El registro de depuración se guarda en el archivo $LXD_DIR/logs/<instance_name>/edk2.log.
- El código de autorización ha sido trasladado a una base modular, lo que permite soportar OpenFGA además de la autorización mediante certificados TLS y Canonical RBAC.
- Para compilar LXD, ahora se requiere al menos la versión 1.20 del lenguaje Go.
- Se ha eliminado el soporte para Shiftfs. Para el mapeo de identificadores de usuario, se debe utilizar el montaje con idmap, soportado para Ext4, XFS, Btrfs, ZFS y Cephfs.
- Se ha eliminado el soporte para firmware UEFI de 2MB (se deben utilizar firmware de 4MB).
- Del código base del fork de Incus se ha trasladado el soporte para la creación de almacenes basados en la tecnología NVME. Se ha añadido un nuevo parámetro de configuración «io.bus» para especificar el tipo de disco, que por defecto está establecido en «virtio-scsi». Al cambiar el valor a «nvme», el almacenamiento en la máquina virtual se verá como un NVME SSD.
- Del código base del fork de Incus se ha trasladado el soporte para la conexión y desconexión en caliente (hot-plug/hot-remove) de rutas de archivos o particiones individuales, pasadas desde el entorno host. Anteriormente, este tipo de conexión mediante el controlador virtio-fs o el sistema de archivos 9p requería detener la máquina virtual. Para sortear esta limitación, se ha habilitado la capacidad de QEMU de conectar en caliente dispositivos PCI y montar la ruta dentro del sistema huésped a través de incus-agent.
- El identificador del dispositivo org.linuxcontainers.lxd ha sido renombrado a com.canonical.lxd (para mantener la compatibilidad hacia atrás, se ha conservado el soporte para el antiguo identificador).
Fuente: opennet.ru
