Canonical ha publicado una nueva versión de su sistema de gestión de contenedores, LXD 5.20, que destaca por cambiar la licencia del proyecto y requerir un Acuerdo de Liberación de Contenido (CLA) para transferir la propiedad del código al aceptar cambios en LXD. La licencia del código aportado a LXD por empleados de Canonical se ha cambiado de Apache 2.0 a AGPLv3, mientras que el código de terceros, del que Canonical no es propietario, se mantiene bajo Apache 2.0. Dado que Canonical no puede cambiar la licencia de todo el código base de LXD, el proyecto se distribuirá ahora bajo una licencia mixta: parte del código bajo AGPLv3 y parte bajo Apache 2.0. La transición a la nueva licencia se debe al deseo de armonizarla con otros productos de servidor de Canonical que utilizan AGPLv3.
El código de versiones anteriores sigue disponible bajo la licencia Apache 2.0, pero cualquier cambio realizado en los componentes relicenciados se publicará exclusivamente bajo la licencia AGPLv3. Esto impide que la bifurcación de Incus porte cambios desde LXD sin migrar su código base a la licencia AGPLv3. Las licencias Apache 2.0 y AGPLv3 son compatibles unidireccionalmente, lo que significa que el código con licencia Apache 2.0 puede incluirse en el código con licencia AGPLv3, pero no viceversa. Este cambio supone el fin total de la colaboración entre los proyectos LXD e Incus, ya que la nueva licencia impide que los cambios se porten de LXD a Incus, y el requisito de firmar un Acuerdo de Licencia de Cliente (CLA) de Incus a LXD impide que los cambios se porten a Incus, algo que los desarrolladores de Incus no tienen intención de firmar.
Una característica única de la licencia AGPLv3 es la introducción de restricciones adicionales para las aplicaciones que prestan servicios de red. Al utilizar componentes con licencia AGPL en servicios de red, el desarrollador debe proporcionar al usuario el código fuente de todos los cambios realizados en estos componentes, incluso si el software subyacente no se distribuye y se utiliza únicamente dentro de la infraestructura interna del servicio. La licencia AGPL también impone condiciones de copyleft, lo que significa que para incorporar código de LXD con licencia AGPL a un proyecto, el código base del proyecto debe relicenciarse bajo la AGPL.
LXD proporciona herramientas para la gestión centralizada de contenedores y máquinas virtuales desplegadas en un clúster de varios servidoresLXD se implementa como un proceso en segundo plano que acepta solicitudes de red a través de una API REST y admite varios sistemas de almacenamiento (árbol de directorios, ZFS, Btrfs, LVM), instantáneas con segmentos de estado, migración en vivo de contenedores en ejecución de una máquina a otra y herramientas para almacenar imágenes de contenedores. El kit de herramientas LXC se utiliza como entorno de ejecución para el lanzamiento de contenedores e incluye la biblioteca liblxc, un conjunto de utilidades (lxc-create, lxc-start, lxc-stop, lxc-ls, etc.), plantillas para la creación de contenedores y un conjunto de enlaces para diversos lenguajes de programación. El aislamiento se logra mediante mecanismos estándar del kernel. Linux (espacios de nombres, cgroups, Apparmor, SELinux, Seccomp). Además de LXC, LXD también utiliza componentes de los proyectos CRIU y QEMU.
Las características agregadas en LXD 5.20 incluyen:
- Al crear grupos de almacenamiento basados en Cephfs, ahora puede crear metadatos y datos para grupos OSD (Object Storage Daemon) mediante 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
- El paquete snap LXD agregó la capacidad de configurar la prioridad de arranque desde diferentes unidades cuando se usa el modo security.csm al firmware EDK2.
- Se ha añadido un modo de depuración (boot.debug_edk2=true) al firmware UEFI EDK2 para diagnosticar problemas de arranque. máquinas virtualesEl registro de depuración se guarda en el archivo $LXD_DIR/logs/ /edk2.log.
- El código de autorización se ha trasladado a una base modular, lo que permite la compatibilidad con OpenFGA además de la autorización mediante certificados TLS y Canonical RBAC.
- LXD ahora requiere al menos Go 1.20 para compilarse.
- Se ha eliminado la compatibilidad con Shiftfs. Para la asignación de ID de usuario, utilice los montajes idmap, compatibles con Ext4, XFS, Btrfs, ZFS y Cephfs.
- Se eliminó el soporte para firmware UEFI de tamaño de 2 MB (se debe utilizar firmware de 4 MB).
- Se ha incorporado la compatibilidad para crear almacenamiento basado en NVME desde el código base de la bifurcación de Incus. Se ha añadido un nuevo parámetro de configuración, "io.bus", para especificar el tipo de disco. De forma predeterminada, está configurado como "virtio-scsi". Al cambiar este parámetro a "nvme", la unidad aparecerá como un SSD NVME en la máquina virtual.
- La compatibilidad con la conexión y desconexión en caliente de rutas de archivos o particiones individuales asignadas desde el entorno host se ha portado desde el código base de la bifurcación de Incus. Anteriormente, dicha asignación mediante el controlador virtio-fs o 9p FS requería detener la máquina virtual. Para superar esta limitación, se utilizó la función de dispositivo PCI conectable en caliente de QEMU y el montaje de rutas dentro del sistema invitado mediante incus-agent.
- El identificador de dispositivo org.linuxcontainers.lxd ha sido renombrado a com.canonical.lxd (para mantener la compatibilidad con versiones anteriores, el identificador antiguo aún es compatible).
Fuente: opennet.ru
