Das Unternehmen Canonical hat eine neue Version des Container-Management-Systems LXD 5.20 veröffentlicht, die durch die Änderung der Lizenz für das Projekt und die Einführung der Notwendigkeit zur Unterzeichnung einer CLA-Vereinbarung zur Übertragung der Eigentumsrechte an dem Code bei der Annahme von Änderungen in LXD bemerkenswert ist. Die Lizenz für vom Canonical-Personal in LXD hinzugefügten Code wurde von Apache 2.0 auf AGPLv3 geändert, während der Code von Drittanbietern, an dem Canonical keine Eigentumsrechte hat, unter Apache 2.0 bleibt. Da Canonical nicht die Möglichkeit hat, die Lizenz für den gesamten LXD-Code zu ändern, wird das Projekt nun unter gemischten Bedingungen angeboten – ein Teil des Codes unter AGPLv3 und ein Teil unter Apache 2.0. Der Übergang zur neuen Lizenz wird durch den Wunsch erklärt, die Lizenz mit anderen Serverprodukten von Canonical zu vereinheitlichen, die AGPLv3 verwenden.
Der Code älterer Versionen bleibt wie gewohnt unter der Lizenz Apache 2.0 verfügbar, aber alle Änderungen, die in die lizenzierten Komponenten eingebracht werden, werden nur unter der Lizenz AGPLv3 veröffentlicht, was es einem Fork von Incus unmöglich macht, Änderungen aus LXD zu übertragen, ohne die eigene Codebasis auf die Lizenz AGPLv3 zu übertragen. Die Lizenzen Apache 2.0 und AGPLv3 haben eine einseitige Kompatibilität, die besagt, dass Code unter der Lizenz Apache 2.0 in Code unter der Lizenz AGPLv3 eingebunden werden kann, aber nicht umgekehrt. Diese Änderung bedeutet das vollständige Ende der Zusammenarbeit zwischen den Projekten LXD und Incus, da die neue Lizenz die Übertragung von Änderungen aus LXD nach Incus erschwert und die Notwendigkeit, eine CLA-Vereinbarung zu unterzeichnen, die Entwickler von Incus nicht unterzeichnen wollen, die Übertragung aus Incus nach LXD behindert.
Eine Besonderheit der Lizenz AGPLv3 ist die Einführung zusätzlicher Einschränkungen für Anwendungen, die den Betrieb von Netzwerfdiensten gewährleisten. Bei der Verwendung von AGPL-Komponenten in Netzwerfdiensten ist der Entwickler verpflichtet, dem Benutzer den Quellcode aller an diesen Komponenten vorgenommenen Änderungen zur Verfügung zu stellen, selbst wenn die zugrunde liegende Software nicht verbreitet wird und ausschließlich in der internen Infrastruktur zur Organisation des Dienstes verwendet wird. Die AGPL-Lizenz legt auch Copyleft-Bedingungen fest, d.h. um AGPL-Code aus LXD in sein Projekt einzubeziehen, muss die Codebasis des eigenen Projekts unter die Lizenz AGPL umgeschrieben werden.
LXD bietet Mittel für das zentrale Management von Containern und virtuellen Maschinen, die in einem Cluster aus mehreren Server. LXD wird als Hintergrundprozess implementiert, der Anfragen über das Netzwerk über eine REST-API entgegennimmt und verschiedene Speicher-Backends (Verzeichnisbaum, ZFS, Btrfs, LVM) unterstützt, Schnappschüsse mit Zustandsaufnahmen, Live-Migration von laufenden Containern von einer Maschine auf eine andere sowie Mittel zur Speicherung von Container-Images. Zum Starten der Container wird das LXC-Toolkit verwendet, das aus der Bibliothek liblxc, einer Sammlung von Tools (lxc-create, lxc-start, lxc-stop, lxc-ls usw.), Vorlagen zum Erstellen von Containern und einer Reihe von Bindungen für verschiedene Programmiersprachen besteht. Die Isolation erfolgt durch die nativen Mechanismen des Linux-Kernels (Namenräume, cgroups, Apparmor, SELinux, Seccomp). Neben LXC verwendet LXD auch Komponenten aus den Projekten CRIU und QEMU.
Zu den in LXD 5.20 hinzugefügten Funktionen gehören:
- Beim Erstellen von Speichervorräumen auf Basis von Cephfs wurde die Möglichkeit eingeführt, Metadaten und Daten für OSD-Pools (Object Storage Daemon) zu erstellen, unter Verwendung der Parameter cephfs.create_missing, cephfs.meta_pool und cephfs.data_pool. Zum Beispiel: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- Im Snap-Paket von LXD wurde die Möglichkeit hinzugefügt, die Boot-Priorität von verschiedenen Disks im security.csm-Modus zu konfigurieren.
- In die EDK2 UEFI-Firmware wurde ein Debug-Modus (boot.debug_edk2=true) zur Diagnose von Boot-Problemen integriert. virtuelle Maschinen. Das Debug-Protokoll wird in die Datei $LXD_DIR/logs//edk2.log gespeichert.
- Der Authentifizierungscode wurde auf eine modulare Basis umgestellt, die die Unterstützung von OpenFGA zusätzlich zur Authentifizierung über TLS-Zertifikate und Canonical RBAC ermöglicht.
- Für die Kompilierung von LXD wird jetzt mindestens die Version 1.20 der Programmiersprache Go benötigt.
- Die Unterstützung für Shiftfs wurde entfernt. Für das Mapping von Benutzer-IDs sollte die Verwendung von Montage mit idmap erfolgen, das für Ext4, XFS, Btrfs, ZFS und Cephfs unterstützt wird.
- Die Unterstützung für UEFI-Firmware mit einer Größe von 2 MB wurde entfernt (es sollten Firmware mit einer Größe von 4 MB verwendet werden).
- Aus dem Code-Repository des Incus-Forks wurde die Unterstützung für die Erstellung von Speicherlösungen auf NVME-Basis übertragen. Um den Festplattentyp anzugeben, wurde ein neuer Konfigurationsparameter 'io.bus' hinzugefügt, der standardmäßig auf 'virtio-scsi' gesetzt ist. Bei einer Änderung des Wertes auf 'nvme' wird das Laufwerk in der virtuellen Maschine als NVME SSD angezeigt.
- Aus dem Code-Repository des Incus-Forks wurde die Unterstützung für das Hot-Plugging und Hot-Removing von Dateipfaden oder einzelnen Partitionen, die aus der Host-Umgebung durchgereicht werden, hinzugefügt. Zuvor erforderte ein solcher Durchschleifvorgang mittels des virtio-fs-Treibers oder des 9p-Dateisystems das Stoppen der virtuellen Maschine. Um dieses Einschränkung zu umgehen, wurde die Möglichkeit von QEMU zum Hot-Plugging von PCI-Geräten und zur Einbindung des Pfades innerhalb des Gastsystems über incus-agent genutzt.
- Die Gerätekennung org.linuxcontainers.lxd wurde in com.canonical.lxd umbenannt (um die Abwärtskompatibilität zu gewährleisten, wurde die Unterstützung der alten Kennung beibehalten).
Quelle: opennet.ru
