Die Firma 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 von Eigentumsrechten an Code bei der Annahme von Änderungen in LXD auffällt. Die Lizenz für Code, der von Mitarbeitern von Canonical in LXD hinzugefügt wurde, wurde von Apache 2.0 auf AGPLv3 geändert, während der Code von Dritten, für den Canonical keine Eigentumsrechte hat, unter Apache 2.0 bleibt. Da Canonical nicht die Möglichkeit hat, die Lizenz für den gesamten Code von LXD zu ändern, wird das Projekt nun unter gemischten Bedingungen bereitgestellt – ein Teil des Codes unter AGPLv3 und der andere Teil unter Apache 2.0. Der Übergang zur neuen Lizenz wird mit dem Wunsch erklärt, die Lizenz mit anderen Serverprodukten von Canonical zu vereinheitlichen, die AGPLv3 verwenden.
Der Code der alten Versionen bleibt wie gewohnt unter der Lizenz Apache 2.0 verfügbar, jedoch werden alle Änderungen an den lizenzierten Komponenten nur unter der Lizenz AGPLv3 veröffentlicht. Dies wird es dem Fork Incus nicht ermöglichen, Änderungen aus LXD zu übernehmen, ohne seine 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 integriert werden kann, jedoch 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 von LXD nach Incus behindert. Zudem erfordert die Übertragung von Incus nach LXD die Unterzeichnung eines CLA-Vereinbarungs, den die Entwickler von Incus nicht unterzeichnen möchten.
Das Besondere an der AGPLv3-Lizenz ist die Einführung zusätzlicher Einschränkungen für Anwendungen, die Netzwerkdienste bereitstellen. Bei der Verwendung von AGPL-Komponenten in Netzwerkdiensten ist der Entwickler verpflichtet, den Benutzern den Quellcode aller vorgenommenen Änderungen an diesen Komponenten 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 Bedingungen für den Copyleft fest, d.h. wenn AGPL-Code aus LXD in Ihr Projekt integriert wird, muss der Code Ihres eigenen Projekts unter der AGPL-Lizenz neu lizenziert werden.
LXD bietet Mittel zur zentralisierten Verwaltung von Containern und virtuellen Maschinen, die in einem Cluster aus mehreren Server. LXD wird als Hintergrundprozess implementiert, der über das Netzwerk Anfragen über die REST-API entgegennimmt und verschiedene Speicher-Backends (Verzeichnisbaum, ZFS, Btrfs, LVM) unterstützt, Schnappschüsse des Systemzustands, die Live-Migration laufender Container von einer Maschine zur anderen und Mittel zur Speicherung von Container-Images bereitstellt. Als Runtime für die Ausführung von Containern wird das LXC-Toolkit verwendet, das die liblxc-Bibliothek, eine Reihe von Utilities (lxc-create, lxc-start, lxc-stop, lxc-ls usw.), Vorlagen zum Erstellen von Containern und ein Set von Bindings für verschiedene Programmiersprachen umfasst. Die Isolation erfolgt durch eingebaute Mechanismen des Linux-Kernels (Namensräume, cgroups, Apparmor, SELinux, Seccomp). Neben LXC werden in LXD auch Komponenten der Projekte CRIU und QEMU verwendet.
Zu den neuen Funktionen, die in LXD 5.20 hinzugefügt wurden, gehören:
- Beim Erstellen von Speicherm Pools auf Basis von Cephfs wurde die Möglichkeit hinzugefügt, Metadaten und Daten für OSD-Pools (Object Storage Daemon) zu erstellen, indem die Parameter cephfs.create_missing, cephfs.meta_pool und cephfs.data_pool verwendet werden. 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 LXD wurde in die EDK2-Firmware die Möglichkeit zur Konfiguration der Boot-Priorität von verschiedenen Festplatten im security.csm-Modus aufgenommen.
- In die EDK2 UEFI-Firmware wurde der Debug-Modus (boot.debug_edk2=true) zur Diagnose von Problemen beim Booten hinzugefügt. virtuellen MaschinenDas Debug-Log wird in der Datei $LXD_DIR/logs//edk2.log gespeichert.
- Der Autorisierungs-Code wurde auf eine modulare Basis umgestellt, die die Unterstützung von OpenFGA zusätzlich zur Authentifizierung durch TLS-Zertifikate und Canonical RBAC ermöglicht.
- Für die Kompilierung von LXD wird nun mindestens Version 1.20 der Programmiersprache Go benötigt.
- Die Unterstützung von Shiftfs wurde entfernt. Für das Mapping von Benutzer-IDs sollte die Montage mit idmap verwendet werden, die für Ext4, XFS, Btrfs, ZFS und Cephfs unterstützt wird.
- Die Unterstützung für UEFI-Firmware mit einer Größe von 2MB wurde entfernt (es muss Firmware mit einer Größe von 4MB verwendet werden).
- Die Unterstützung für die Erstellung von Speicherlösungen auf Basis der NVME-Technologie wurde aus dem Code des Incus-Forks übernommen. Um den Festplattentyp anzugeben, wurde ein neuer Konfigurationsparameter 'io.bus' eingeführt, der standardmäßig auf 'virtio-scsi' gesetzt ist. Wenn der Wert auf 'nvme' geändert wird, wird das Laufwerk in der virtuellen Maschine als NVME SSD angezeigt.
- Aus dem Code-Repository des Forks Incus wurde die Unterstützung für das Hot-Plugging und Hot-Removing (Hot-Plug/Hot-Remove) von Dateipfaden oder einzelnen Partitionen, die aus der Host-Umgebung durchgereicht werden, übernommen. Zuvor erforderte eine solche Durchleitung über den Virtio-FS-Treiber oder das 9p-Dateisystem das Anhalten der virtuellen Maschine. Um diese Einschränkung zu umgehen, wurde die Möglichkeit von QEMU zur Hot-Plug-Anbindung von PCI-Geräten und die Montage des Pfades innerhalb des Gastsystems über incus-agent genutzt.
- Die Geräte-ID org.linuxcontainers.lxd wurde in com.canonical.lxd umbenannt (um die Abwärtskompatibilität zu wahren, bleibt die Unterstützung der alten ID erhalten).
Quelle: opennet.ru
