La société Canonical a publié une nouvelle version du système de gestion de conteneurs LXD 5.20, qui se distingue par un changement de licence pour le projet et l'introduction de la nécessité de signer un accord CLA sur le transfert des droits de propriété sur le code lors de l'acceptation de modifications dans LXD. La licence pour le code ajouté à LXD par les employés de Canonical a été modifiée de l'Apache 2.0 à l'AGPLv3, tandis que le code des participants extérieurs, sur lequel Canonical n'a pas de droits de propriété, reste sous Apache 2.0. Étant donné que Canonical n'a pas la possibilité de modifier la licence de l'ensemble du code LXD, le projet sera désormais distribué sous des conditions mixtes — une partie du code sous AGPLv3 et l'autre sous Apache 2.0. Le passage à la nouvelle licence s'explique par le souhait d'unifier la licence avec d'autres produits serveurs de Canonical, qui utilisent l'AGPLv3.
Le code des anciennes versions reste disponible sous la licence Apache 2.0, mais toutes les modifications apportées aux composants re-licenciés seront publiées uniquement sous la licence AGPLv3, ce qui empêchera le fork Incus d'intégrer les modifications de LXD sans transférer sa base de code à la licence AGPLv3. Les licences Apache 2.0 et AGPLv3 ont une compatibilité unidirectionnelle, ce qui signifie que le code sous la licence Apache 2.0 peut être inclus dans le code sous la licence AGPLv3, mais pas l'inverse. Ce changement signifie la fin complète de la coopération entre les projets LXD et Incus, car le transfert de modifications de LXD vers Incus est entravé par la nouvelle licence, tandis que de Incus vers LXD, la nécessité de signer un accord CLA, que les développeurs d'Incus ne souhaitent pas signer.
La particularité de la licence AGPLv3 est l'introduction de restrictions supplémentaires pour les applications fournissant des services réseau. Lorsqu'il utilise des composants AGPL dans des services réseau, le développeur est tenu de fournir à l'utilisateur le code source de toutes les modifications apportées à ces composants, même si le logiciel sous-jacent ne est pas distribué et utilisé uniquement dans l'infrastructure interne pour organiser le fonctionnement du service. La licence AGPL impose également des conditions de copyleft, c'est-à-dire que pour intégrer le code AGPL de LXD dans son projet, la base de code de son propre projet doit être re-licenciée sous la licence AGPL.
LXD fournit des outils pour la gestion centralisée des conteneurs et des machines virtuelles déployés dans un cluster de plusieurs serveurs. LXD est mis en œuvre sous la forme d'un processus en arrière-plan qui reçoit des requêtes via le réseau via une API REST et prend en charge divers backend de stockage (arborescence de répertoires, ZFS, Btrfs, LVM), des instantanés avec prise d'état, la migration en direct des conteneurs en cours d'exécution d'une machine à une autre et des outils pour le stockage d'images de conteneurs. Le runtime utilisé pour exécuter les conteneurs est l'outil LXC, qui comprend la bibliothèque liblxc, un ensemble d'utilitaires (lxc-create, lxc-start, lxc-stop, lxc-ls, etc.), des modèles pour la création de conteneurs et un ensemble de bindings pour différents langages de programmation. L'isolation est effectuée à l'aide des mécanismes standard du noyau Linux (espaces de noms, cgroups, Apparmor, SELinux, Seccomp). En plus de LXC, LXD utilise également des composants des projets CRIU et QEMU.
Parmi les nouvelles fonctionnalités ajoutées dans LXD 5.20 :
- Lors de la création de pools de stockage basés sur Cephfs, il est possible de créer des métadonnées et des données pour les pools OSD (Object Storage Daemon) en utilisant les paramètres cephfs.create_missing, cephfs.meta_pool et cephfs.data_pool. Par exemple : lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- Le paquet snap de LXD inclut dans le firmware EDK2 la possibilité de configurer la priorité de démarrage à partir de différents disques lors de l'utilisation du mode security.csm.
- Un mode de débogage a été ajouté au firmware EDK2 UEFI (boot.debug_edk2=true) pour diagnostiquer les problèmes de démarrage machines virtuelles. Le journal de débogage est enregistré dans le fichier $LXD_DIR/logs//edk2.log.
- Le code d'autorisation a été traduit sur une base modulaire, permettant d'assurer la prise en charge d'OpenFGA en plus de l'autorisation par certificats TLS et de Canonical RBAC.
- Pour compiler LXD, il est maintenant nécessaire d'utiliser au moins la version 1.20 du langage Go.
- La prise en charge de Shiftfs a été supprimée. Pour le mapping des identifiants utilisateurs, il faut utiliser le montage avec idmap, pris en charge pour Ext4, XFS, Btrfs, ZFS et Cephfs.
- La prise en charge des firmwares UEFI de 2 Mo a été supprimée (il est nécessaire d'utiliser des firmwares d'une taille de 4 Mo).
- Le support de la création de stockages basés sur la technologie NVME a été transféré depuis le code source du fork d'Incus. Un nouveau paramètre de configuration « io.bus » a été ajouté pour spécifier le type de disque, avec la valeur par défaut réglée sur « virtio-scsi ». Lorsque la valeur est modifiée en « nvme », le stockage dans la machine virtuelle sera visible comme un SSD NVME.
- Le support du branchement à chaud et du retrait à chaud (hot-plug/hot-remove) des chemins de fichiers ou des partitions individuelles passés de l'environnement hôte a été transféré depuis le code source du fork d'Incus. Auparavant, un tel passage à travers le pilote virtio-fs ou le système de fichiers 9p nécessitait l'arrêt de la machine virtuelle. Pour contourner cette limitation, la fonctionnalité de QEMU permettant le branchement à chaud des périphériques PCI et le montage du chemin dans le système invité via incus-agent a été utilisée.
- L'identifiant de l'appareil org.linuxcontainers.lxd a été renommé en com.canonical.lxd (le support de l'ancien identifiant a été conservé pour maintenir la compatibilité descendante).
Source : opennet.ru
