A Canonical cég közzétette az LXD 5.20 konténerkezelő rendszer új verzióját, amelynek jelentősége a projekt licencének módosítása és a CLA megállapodás aláírásának szükségessége a LXD-ben végrehajtott módosítások bevételéhez. A Canonical alkalmazottai által hozzáadott kód licencét Apache 2.0-ról AGPLv3-ra változtatták, míg a harmadik fél résztvevők kódja, amelyre a Canonical-nak nincsenek tulajdonjogai, Apache 2.0 alatt marad. Mivel a Canonical nem tudja módosítani az LXD összes kódjának licencét, a projekt most vegyes feltételekkel fog megjelenni – egyes kódok AGPLv3 alatt, míg mások Apache 2.0 alatt. Az új licencre való áttérést az indokolja, hogy a Canonical más szervertermékeivel egységesebbé kívánja tenni a licencet, amelyek szintén AGPLv3-at használnak.
A régi kiadások kódja továbbra is rendelkezésre áll Apache 2.0 licenc alatt, de minden, a licencelt összetevőkben végrehajtott változtatás kizárólag AGPLv3 licenc alatt kerül közzétételre, ami megakadályozza, hogy az Incus fork módosításait átvihesse az LXD-ből anélkül, hogy a saját kódalapját AGPLv3 licencre kellene átkonvertálnia. Az Apache 2.0 és AGPLv3 licenc egyirányú kompatibilitását jelenti, amely azt jelenti, hogy az Apache 2.0 alatt álló kód beépíthető AGPLv3 alatt álló kódba, de fordítva nem. A változás a LXD és Incus projektek közötti együttműködés teljes megszüntetését jelenti, mivel az LXD-ből az Incus felé való módosítások átvitele megnehezedik az új licenc miatt, míg az Incus-ból az LXD felé a CLA megállapodás aláírásának szükségessége miatt, amelyet az Incus fejlesztői nem kívánnak aláírni.
Az AGPLv3 licenc sajátossága, hogy további korlátozások kerülnek bevezetésre a hálózati szolgáltatások működtetését biztosító alkalmazások számára. Az AGPL komponensek használatakor a hálózati szolgáltatások működtetésében a fejlesztő köteles a felhasználónak megadni az összes, ezekhez a komponensekhez végrehajtott módosítás forráskódját, még akkor is, ha a szolgáltatás alapjául szolgáló szoftver nem terjeszthető és kizárólag belső infrastruktúrában használják a szolgáltatás működtetésére. Az AGPL licenc kopyleft feltételeket is előír, azaz ha az LXD-ből származó AGPL kódot be kívánják vonni a saját projektjükbe, a saját projektük kódalapját AGPL licenc alá kell átkonvertálni.
Az LXD központosított eszközöket biztosít konténerek és virtuális gépek kezelésére, amelyeket több klaszterbe telepítettek. szerverekAz LXD egy háttérfolyamatként valósul meg, amely hálózaton keresztül REST API-n keresztül fogadja a kéréseket, és támogat különböző háttértárolókat (könyvtárfa, ZFS, Btrfs, LVM), állapotpillanatképeket, élő migrációt a működő konténerek között egyik gépről a másikra, valamint eszközöket a konténerképek tárolására. A konténerek futtatásához az LXC eszközkészlete használatos, amely tartalmazza a liblxc könyvtárat, egy sor segédprogramot (lxc-create, lxc-start, lxc-stop, lxc-ls stb.), konténerépítő sablonokat és különböző programozási nyelvekhez való kötéseket. Az elszigetelés a Linux kernel szabványos mechanizmusaival történik (névterek, cgroups, Apparmor, SELinux, Seccomp). Az LXD-ben az LXC mellett a CRIU és QEMU projektek komponensei is alkalmazásra kerülnek.
A LXD 5.20 verziójához hozzáadott új lehetőségek közé tartozik:
- A Cephfs alapú tárolási medencék létrehozásakor lehetőség nyílt OSD (Object Storage Daemon) tárolómedencék adatainak és metadatainak létrehozására a cephfs.create_missing, cephfs.meta_pool és cephfs.data_pool paraméterek használatával. Például: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- Az LXD snapcsomagjában az EDK2 firmware-be hozzáadva lett a különböző lemezekről való bootprioritás beállításának lehetősége a security.csm mód használatakor.
- Az EDK2 UEFI firmware-be egy hibakeresési módot is beillesztettek (boot.debug_edk2=true) a betöltési problémák diagnosztizálására. virtuális gépekhezA hibakeresési napló a $LXD_DIR/logs//edk2.log fájlba kerül mentésre.
- A hitelesítési kód moduláris alapra lett áthelyezve, lehetővé téve az OpenFGA támogatását a TLS tanúsítványok és a Canonical RBAC szerinti hitelesítés mellett.
- Az LXD összeállításához mostantól legalább a Go nyelv 1.20-as verziója szükséges.
- Eltávolították a Shiftfs támogatását. A felhasználói azonosítók leképezéséhez a idmap szerinti csatolást kell használni, amely támogatott az Ext4, XFS, Btrfs, ZFS és Cephfs esetében.
- Eltávolították a 2 MB méretű UEFI firmware-k támogatását (4 MB méretű firmware-ket kell használni).
- Az Incus fork kódalapjából átvették az NVME technológián alapuló tárolók létrehozásának támogatását. A lemeztípus megadásához új konfigurációs paraméter került bevezetésre, a "io.bus", ami alapértelmezés szerint "virtio-scsi" értékre van állítva. Ha az érték "nvme"-re változik, a virtuális gépben a tároló NVME SSD-ként fog megjelenni.
- Az Incus fork kódalapjából átvették a fájlútvonalak vagy egyes partíciók forró csatlakozásának és forró eltávolításának (hot-plug/hot-remove) támogatását, amelyek a gazda környezetből vannak átirányítva. Korábban az ilyen irányítás a virtio-fs illesztőprogram vagy a 9p fájlrendszer használatával a virtuális gép leállítását igényelte. E korlátozás megkerülésére a QEMU PCI-eszközök forró csatlakoztatásának lehetőségét és az útvonalak belső mappába történő csatlakoztatását használták az incus-agent segítségével.
- Az org.linuxcontainers.lxd eszközazonosítót com.canonical.lxd-ra nevezték át (a visszamenőleges kompatibilitás érdekében a régi azonosító támogatása megmaradt).
Forrás: opennet.ru
