Компания Canonical публикува нова версия на системата за управление контейнери LXD 5.20, която е забележителна с промените в лиценза на проекта и въвеждането на необходимостта от подписване на CLA споразумение за прехвърляне на имуществените права над кода при приемането на промени в LXD. Лицензията на кода, добавен в LXD от служителите на Canonical, е променена от Apache 2.0 на AGPLv3, докато кодът на външни участници, за който Canonical няма имуществени права, остава под Apache 2.0. Тъй като Canonical не може да промени лиценза на целия код на LXD, проектът сега ще бъде предлаган с комбинирани условия – част от кода под AGPLv3, а част под Apache 2.0. Преминаването към новия лиценз е обяснено с желанието да се унифицира лицензът с другите сървърни продукти на Canonical, в които се използва AGPLv3.
Кодът на старите версии, както и преди, остава достъпен под лицензията Apache 2.0, но всички изменения в прелицензираните компоненти ще бъдат публикувани само под лицензията AGPLv3, което ще попречи на форка Incus да пренася промени от LXD без да премине на лиценза AGPLv3. Лицензиите Apache 2.0 и AGPLv3 имат едностранна съвместимост, което означава, че кодът под лицензия Apache 2.0 може да бъде включен в код под лицензия AGPLv3, но не и обратно. Това изменение означава пълно прекратяване на сътрудничеството между проектите LXD и Incus, тъй като новият лиценз пречи на прехвърлянето на промени от LXD в Incus, а от Incus в LXD изисква подписване на CLA споразумение, което разработчиците на Incus не планират да подпишат.
Характеристика на лицензията AGPLv3 е въвеждането на допълнителни ограничения за приложения, осигуряващи функционирането на мрежови услуги. При използването на AGPL-компоненти в работата на мрежови услуги, разработчикът е задължен да предостави на потребителя изходния код на всички внесени в тези компоненти промени, дори ако основният софтуер на услугата не се разпространява и се използва изцяло във вътрешната инфраструктура за организиране на работата на услугата. Лицензия AGPL също така налага условия за копилефт, т.е. за включване на AGPL-код от LXD в своя проект, кодовата база на собствения проект трябва да бъде прелицензирана под лицензия AGPL.
LXD предоставява средства за централизирано управление на контейнери и виртуални машини, разположени в клъстър от няколко сървъри. LXD е реализиран като фонов процес, който приема заявки по мрежата чрез REST API и поддържа различни бекенди за съхранение (дърво от директории, ZFS, Btrfs, LVM), моментни снимки на състоянието, жива миграция на работещи контейнери от една машина на друга и инструменти за съхранение на образи на контейнери. Като runtime за стартиране на контейнери се използва инструментарият LXC, включващ библиотеката liblxc, набор от утилити (lxc-create, lxc-start, lxc-stop, lxc-ls и т.н.), шаблони за изграждане на контейнери и набор от свръзки за различни езици за програмиране. Изолацията се осъществява чрез стандартните механизми на ядрото на Linux (пространства от имена, cgroups, Apparmor, SELinux, Seccomp). Освен LXC, в LXD също се използват компоненти от проектите CRIU и QEMU.
Сред добавените в LXD 5.20 възможности:
- По време на създаването на хранилищни пулове на база Cephfs е добавена възможност за създаване на метаданни и данни за пуловете OSD (Object Storage Daemon), използвайки параметрите cephfs.create_missing, cephfs.meta_pool и cephfs.data_pool. Например: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- В snap-пакета на LXD в фърмуера EDK2 е добавена възможност за настройка на приоритета за зареждане от различни дискове при използване на режима security.csm.
- В фърмуера EDK2 UEFI е добавен режим на отстраняване на проблеми (boot.debug_edk2=true) за диагностика на проблеми при зареждане на виртуални машини. Логът за отстраняване на проблеми се запазва в файл $LXD_DIR/logs/<instance_name>/edk2.log.
- Кодът за авторизация е трансформиран в модулна основа, което позволява поддръжка на OpenFGA в допълнение към авторизация по TLS сертификати и Canonical RBAC.
- За компилиране на LXD вече е необходима минимално версия на езика Go 1.20.
- Поддръжката на Shiftfs е премахната. За мапиране на идентификатори на потребители следва да се използва монтиране с idmap, поддържано за Ext4, XFS, Btrfs, ZFS и Cephfs.
- Поддръжката на UEFI фърмуери с размер 2MB е премахната (необходимо е да се използват фърмуери с размер 4MB).
- От кодовата база на форка Incus е преместена поддръжката за създаване на хранилища с NVME технология. За указване на типа диск е добавен нов параметър в конфигурацията „io.bus“, който по подразбиране е зададен на „virtio-scsi“. При промяна на стойността на „nvme“, устройството във виртуалната машина ще бъде видимо като NVME SSD.
- От кодовата база на форка Incus е преместена поддръжката за горещо свързване и горещо премахване (hot-plug/hot-remove) на файлови пътища или отделни дялове, прокарани от хост-средата. По-рано подобно прокарване чрез драйвера virtio-fs или ФС 9p изискваше спиране на виртуалната машина. За заобикаляне на това ограничение е използвана възможността на QEMU за горещо свързване на PCI-устройства и монтиране на пътя вътре в гостуващата система чрез incus-agent.
- Идентификаторът на устройството org.linuxcontainers.lxd е преименуван на com.canonical.lxd (за запазване на обратната съвместимост, поддръжката на стария идентификатор остава).
Източник: opennet.ru
