Firma Canonical opublikowała nową wersję systemu zarządzania kontenerami LXD 5.20, która jest istotna ze względu na zmianę licencji projektu oraz wprowadzenie obowiązku podpisania umowy CLA dotyczącej przeniesienia praw majątkowych do kodu przy wprowadzaniu zmian w LXD. Licencja na kod dodany do LXD przez pracowników Canonical została zmieniona z Apache 2.0 na AGPLv3, natomiast kod od zewnętrznych uczestników, którego Canonical nie posiada praw majątkowych, pozostaje na licencji Apache 2.0. Ponieważ Canonical nie ma możliwości zmiany licencji na cały kod LXD, projekt będzie teraz dostarczany na mieszanych warunkach - część kodu na AGPLv3, a część na Apache 2.0. Przejście na nową licencję jest uzasadnione chęcią unifikacji licencji z innymi produktami serwerowymi Canonical, które wykorzystują AGPLv3.
Kod wcześniejszych wydań nadal pozostaje dostępny na licencji Apache 2.0, jednak wszelkie zmiany wprowadzane w komponentach objętych nową licencją będą publikowane wyłącznie na licencji AGPLv3, co nie pozwoli forkowi Incus przenieść zmian z LXD bez zmiany swojej bazy kodu na licencję AGPLv3. Licencje Apache 2.0 i AGPLv3 mają jednostronną zgodność, co oznacza, że kod na licencji Apache 2.0 może być włączany do kodu na licencji AGPLv3, ale nie odwrotnie. Zmiana ta oznacza całkowite zaprzestanie współpracy między projektami LXD i Incus, ponieważ nowa licencja utrudnia przenoszenie zmian z LXD do Incus, a z Incus do LXD wymaga podpisania umowy CLA, co programiści Incus nie zamierzają robić.
Cechą charakterystyczną licencji AGPLv3 jest wprowadzenie dodatkowych ograniczeń dla aplikacji, które zapewniają działanie usług sieciowych. Przy korzystaniu z komponentów AGPL w działaniu usług sieciowych, deweloper ma obowiązek udostępnić użytkownikowi kod źródłowy wszystkich wprowadzonych zmian w tych komponentach, nawet jeśli podstawowe oprogramowanie nie jest dystrybuowane i jest używane wyłącznie wewnętrznej infrastrukturze do organizacji działania usługi. Licencja AGPL nakłada również warunki copyleft, tzn. w celu włączenia kodu AGPL z LXD do własnego projektu, baza kodu własnego projektu musi zostać zmieniona na licencję AGPL.
LXD zapewnia narzędzia do centralnego zarządzania kontenerami i maszynami wirtualnymi wdrożonymi w klastrze składającym się z wielu serwerów. LXD jest realizowany jako proces w tle, który przyjmuje żądania przez sieć za pośrednictwem REST API i wspiera różne backendy pamięci (drzewa katalogów, ZFS, Btrfs, LVM), migawki ze stanem, migrację na żywo działających kontenerów z jednej maszyny na drugą oraz narzędzia do przechowywania obrazów kontenerów. Jako czas wykonywania do uruchamiania kontenerów wykorzystuje się zestaw narzędzi LXC, który obejmuje bibliotekę liblxc, zestaw narzędzi (lxc-create, lxc-start, lxc-stop, lxc-ls itp.), szablony do tworzenia kontenerów oraz zestaw powiązań dla różnych języków programowania. Izolacja odbywa się przy użyciu wbudowanych mechanizmów jądra Linux (przestrzenie nazw, cgroups, Apparmor, SELinux, Seccomp). Oprócz LXC w LXD stosowane są również komponenty z projektów CRIU i QEMU.
Wśród nowych możliwości dodanych w LXD 5.20:
- Podczas tworzenia pul storage na bazie Cephfs dodano możliwość tworzenia metadanych i danych dla pul OSD (Object Storage Daemon), używając parametrów cephfs.create_missing, cephfs.meta_pool oraz cephfs.data_pool. Na przykład: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- W paczce snap LXD w firmware EDK2 dodano możliwość konfiguracji priorytetu bootowania z różnych dysków w trybie security.csm.
- W firmware EDK2 UEFI dodano tryb debugowania (boot.debug_edk2=true) do diagnozowania problemów podczas rozruchu maszyn wirtualnych. Dziennik debugowania jest zapisywany w pliku $LXD_DIR/logs//edk2.log.
- Kod autoryzacji został przeniesiony na modułową podstawę, co umożliwiło wsparcie dla OpenFGA, oprócz autoryzacji za pomocą certyfikatów TLS oraz Canonical RBAC.
- Do kompilacji LXD wymagana jest teraz przynajmniej wersja języka Go 1.20.
- Usunięto wsparcie dla Shiftfs. Do mapowania identyfikatorów użytkowników należy używać montowania za pomocą idmap, wspieranego dla Ext4, XFS, Btrfs, ZFS i Cephfs.
- Usunięto wsparcie dla firmware UEFI o rozmiarze 2MB (należy używać firmware o rozmiarze 4MB).
- Z kodu forka Incus przeniesiono wsparcie dla tworzenia magazynów opartych na technologii NVMe. Aby wskazać typ dysku, dodano nowy parametr konfiguracji „io.bus”, który domyślnie ustawiony jest na wartość „virtio-scsi”. Po zmianie wartości na „nvme” nośnik w maszynie wirtualnej będzie widoczny jako NVMe SSD.
- Z kodu forka Incus przeniesiono wsparcie dla gorącego podłączania i gorącego odłączania (hot-plug/hot-remove) ścieżek plików lub poszczególnych partycji przekazywanych z środowiska hosta. Wcześniej takie przekazywanie za pomocą sterownika virtio-fs lub systemu plików 9p wymagało zatrzymania maszyny wirtualnej. Aby obejść to ograniczenie, wykorzystano możliwość QEMU gorącego podłączania urządzeń PCI i montowania ścieżki wewnątrz systemu gościa za pomocą incus-agent.
- Identyfikator urządzenia org.linuxcontainers.lxd został przemianowany na com.canonical.lxd (aby zachować zgodność wsteczną, wsparcie dla starego identyfikatora zostało zachowane).
Źródło: opennet.ru
