Firma SUSE opublikowała drugi prototyp platformy ALP «Punta Baretti» (Adaptable Linux Platform), która jest postrzegana jako kontynuacja rozwoju dystrybucji SUSE Linux Enterprise. Kluczową różnicą ALP jest podział podstawy dystrybucji na dwie części: uproszczoną „host OS” do pracy na sprzęcie oraz warstwę aplikacyjną, skoncentrowaną na uruchamianiu w kontenerach i maszynach wirtualnych. Wersje są przygotowane dla architektury x86_64. ALP jest rozwijana od początku z wykorzystaniem otwartego procesu, w ramach którego pośrednie wersje i wyniki testów są publicznie dostępne dla wszystkich chętnych.
Architektura ALP opiera się na rozwoju w środowisku „host OS”, które jest minimalnie wymagane do wspierania i zarządzania sprzętem. Wszystkie aplikacje i komponenty przestrzeni użytkownika proponuje się uruchamiać nie w zmieszanym środowisku, ale w oddzielnych kontenerach lub w maszynach wirtualnych, uruchamianych na „host OS” i izolowanych od siebie. Tego rodzaju organizacja pozwoli użytkownikom skupić się na aplikacjach i abstrahować procesy robocze, oddzielając je od niskopoziomowego środowiska systemowego i sprzętu.
Jako bazę dla „host OS” wykorzystano produkt SLE Micro, oparty na osiągnięciach projektu MicroOS. Dla centralnego zarządzania oferowane są systemy zarządzania konfiguracją Salt (zainstalowany) oraz Ansible (opcjonalnie). Do uruchamiania izolowanych kontenerów dostępne są narzędzia Podman i K3s (Kubernetes). Wśród komponentów systemowych przeniesionych do kontenerów znajdują się yast2, podman, k3s, cockpit, GDM (GNOME Display Manager) i KVM.
W systemie domyślnie stosowane jest szyfrowanie dysku (FDE, Full Disk Encryption) z możliwością przechowywania kluczy w TPM. Główny podział montowany jest w trybie tylko do odczytu i nie zmienia się podczas pracy. W środowisku stosowany jest mechanizm atomowej instalacji aktualizacji. W przeciwieństwie do atomowych aktualizacji opartych na ostree i snap, stosowanych w Fedora i Ubuntu, w ALP zamiast budowania oddzielnych atomowych obrazów i wdrażania dodatkowej infrastruktury dostarczania używa się standardowego menedżera pakietów oraz mechanizmu migawkowego w systemie plików Btrfs.
Zaprojektowano konfigurowalny tryb automatycznej instalacji aktualizacji (np. możliwe jest włączenie automatycznej instalacji tylko poprawek krytycznych luk bezpieczeństwa lub powrót do ręcznego zatwierdzania instalacji aktualizacji). Wsparcie dla aktualizacji jądra Linux bez ponownego uruchamiania i zatrzymania działania systemu zapewniają łatwe poprawki. Aby zapewnić trwałość systemu (self-healing), ostatni stabilny stan jest zapisywany przy użyciu migawków Btrfs (w przypadku wykrycia anomalii po zastosowaniu aktualizacji lub zmianie ustawień, system automatycznie wraca do poprzedniego stanu).
Platforma wykorzystuje wielowersyjny stos oprogramowania — dzięki zastosowaniu kontenerów możliwe jest równoczesne korzystanie z różnych wersji narzędzi i aplikacji. Na przykład możliwe jest uruchamianie aplikacji, które używają w zależnościach różnych wersji Pythona, Javy i Node.js, oddzielając niekompatybilne ze sobą zależności. Podstawowe zależności dostarczane są w postaci zestawów BCI (Base Container Images). Użytkownik może tworzyć, aktualizować i usuwać stosy oprogramowania, nie wpływając na inne środowiska.
Główne zmiany w drugim prototypie ALP:
- Wykorzystano instalator D-Installer, w którym interfejs użytkownika jest oddzielony od wewnętrznych komponentów YaST oraz istnieje możliwość używania różnych front-endów, w tym front-endu do zarządzania instalacją za pomocą interfejsu webowego. Podstawowy interfejs do zarządzania instalacją zbudowano z użyciem technologii webowych i zawiera przetwornik zapewniający dostęp do wywołań D-Bus przez HTTP oraz bezpośredni interfejs webowy. Interfejs webowy został napisany w JavaScript z wykorzystaniem frameworka React oraz komponentów PatternFly. Aby zapewnić bezpieczeństwo, D-Installer obsługuje instalację na zaszyfrowanych partycjach i umożliwia wykorzystanie TPM (Trusted Platform Module) do odszyfrowania partycji rozruchowej, używając zamiast haseł kluczy przechowywanych w chipie TPM.
- Zapewniono uruchamianie niektórych klientów YaST (bootloader, iSCSIClient, Kdump, firewall itp.) w oddzielnych kontenerach. Zrealizowano dwa typy kontenerów — zarządzające do pracy z YaST w trybie tekstowym, w GUI oraz przez interfejs webowy, oraz testowe do automatyzacji testów. Szereg modułów został również dostosowany do użycia w systemach z aktualizacjami transakcyjnymi. Do integracji z openQA zaproponowano bibliotekę libyui-rest-api realizującą REST API.
- Zrealizowano uruchamianie w kontenerze platformy Cockpit, na podstawie którego zbudowano interfejs webowy konfiguracyjnego i instalacyjnego.
- Zagwarantowano możliwość stosowania pełnego szyfrowania dysku (FDE, Full Disk Encryption) w instalacjach na zwykłym sprzęcie, a nie tylko w systemach wirtualizacyjnych i chmurowych.
- Jako główny bootloader wykorzystano GRUB2.
- Dodano konfiguracje dla wdrażania kontenerów do budowy zapory sieciowej (firewalld-container) oraz do centralnego zarządzania systemami i klastrami (warewulf-container).
Źródło: opennet.ru
