Компания 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), моментни снимки на състоянието, live-миграция на работещи контейнери от една машина на друга и средства за съхраняване на образи на контейнери. Като 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//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
