Das Unternehmen SUSE hat den dritten Prototyp der Plattform ALP \u201ePiz Bernina\u201c (Adaptable Linux Platform) ver\u00f6ffentlicht, die als Fortsetzung der Entwicklung der Distribution SUSE Linux Enterprise positioniert ist. Das Hauptunterscheidungsmerkmal von ALP ist die Trennung der Basisversion der Distribution in zwei Teile: ein reduziertes \u201eHost OS\u201c zum Betrieb \u00fcber der Hardware und eine Schicht zur Unterst\u00fctzung von Anwendungen, die auf die Ausf\u00fchrung in Containern und virtuellen Maschinen ausgerichtet ist. ALP wird urspr\u00fcnglich mit einem offenen Entwicklungsprozess entwickelt, bei dem Zwischenversionen und Testergebnisse \u00f6ffentlich allen Interessierten zur Verf\u00fcgung stehen. <\/p>\n
Der dritte Prototyp umfasst zwei separate Versionen, die in ihrer aktuellen Form \u00e4hnlich sind, sich jedoch in Zukunft in unterschiedliche Anwendungsbereiche entwickeln und sich durch die bereitgestellten Dienste unterscheiden werden. F\u00fcr Tests steht der Branch Bedrock zur Verf\u00fcgung, der auf den Einsatz in Serversystemen ausgerichtet ist, und der Branch Micro, der auf den Aufbau von Cloud-Systemen (cloud-native) und den Betrieb von Mikrodiensten ausgelegt ist. Fertige Versionen sind f\u00fcr die Architektur x86_64 (Bedrock, Micro) verf\u00fcgbar. Zus\u00e4tzlich sind Build-Szenarien (Bedrock, Micro) f\u00fcr die Architekturen Aarch64, PPC64le und s390x verf\u00fcgbar. <\/p>\n
Die Architektur von ALP basiert auf der Entwicklung einer \u201eHost OS\u201c-Umgebung, die minimal erforderlich ist, um Hardware zu unterst\u00fctzen und zu verwalten. Alle Anwendungen und Komponenten des Benutzerraums sollen nicht in einer gemischten Umgebung, sondern in separaten Containern oder virtuellen Maschinen<\/a>, die \u00fcber der \u201eHost OS\u201c ausgef\u00fchrt werden und voneinander isoliert sind. Eine solche Organisation erm\u00f6glicht es den Nutzern, sich auf Anwendungen zu konzentrieren und Arbeitsabl\u00e4ufe zu abstrahieren, indem sie diese von der niedrigstufigen Systemumgebung und Hardware trennen. <\/p>\n Als Grundlage f\u00fcr das «host OS» wird das Produkt SLE Micro verwendet, das auf den Entwicklungen des MicroOS-Projekts basiert. F\u00fcr das zentralisierte Management werden die Konfigurationsmanagementsysteme Salt (vorinstalliert) und Ansible (optional) angeboten. F\u00fcr das Starten isolierter Container stehen die Werkzeuge Podman und K3s (Kubernetes) zur Verf\u00fcgung. Zu den systemischen Komponenten, die in Container ausgelagert wurden, geh\u00f6ren yast2, podman, k3s, cockpit, GDM (GNOME Display Manager) und KVM. <\/p>\n Zu den Besonderheiten der Systemumgebung geh\u00f6rt die standardm\u00e4\u00dfige Verwendung von Festplattenschl\u00fcsselung (FDE, Full Disk Encryption) mit der M\u00f6glichkeit, Schl\u00fcssel im TPM zu speichern. Die Root-Partition wird schreibgesch\u00fctzt gemountet und w\u00e4hrend des Betriebs nicht ver\u00e4ndert. In der Umgebung kommt ein Mechanismus f\u00fcr atomare Updates zur Anwendung. Im Gegensatz zu den atomaren Updates auf Basis von ostree und snap, die in Fedora und Ubuntu verwendet werden, verwendet ALP anstelle des Aufbaus separater atomarer Images und der Bereitstellung zus\u00e4tzlicher Lieferinfrastrukturen den standardm\u00e4\u00dfigen Paketmanager und den Snapshot-Mechanismus im Btrfs-Dateisystem. <\/p>\n Es ist ein konfigurierbarer automatischer Update-Modus vorgesehen (zum Beispiel kann die automatische Installation nur f\u00fcr kritische Sicherheitsupdates aktiviert werden oder es kann zur manuellen Best\u00e4tigung der Installation von Updates zur\u00fcckgekehrt werden). F\u00fcr das Aktualisieren des Linux-Kernels ohne Neustart und ohne Unterbrechung des Betriebs werden Live-Patches unterst\u00fctzt. Zur Aufrechterhaltung der Systemresilienz (Self-Healing) wird der letzte stabile Zustand mithilfe von Btrfs-Snapshots festgehalten (bei Erkennung von Anomalien nach der Anwendung von Updates oder \u00c4nderungen an den Einstellungen wird das System automatisch in den vorherigen Zustand zur\u00fcckversetzt). <\/p>\n Die Plattform verwendet einen mehrversionsf\u00e4higen Software-Stack \u2014 durch den Einsatz von Containern k\u00f6nnen gleichzeitig verschiedene Versionen von Tools und Anwendungen genutzt werden. Beispielsweise k\u00f6nnen Anwendungen, die in Abh\u00e4ngigkeiten unterschiedliche Versionen von Python, Java und Node.js verwenden, ausgef\u00fchrt werden, w\u00e4hrend inkompatible Abh\u00e4ngigkeiten voneinander getrennt bleiben. Die grundlegenden Abh\u00e4ngigkeiten werden in Form von BCI-Sets (Base Container Images) bereitgestellt. Der Benutzer kann Software-Stacks erstellen, aktualisieren und l\u00f6schen, ohne andere Umgebungen zu ber\u00fchren. <\/p>\n F\u00fcr die Installation wird der D-Installer verwendet, bei dem die Benutzeroberfl\u00e4che von den internen Komponenten von YaST getrennt ist und die M\u00f6glichkeit besteht, verschiedene Frontends zu verwenden, darunter ein Frontend zur Verwaltung der Installation \u00fcber eine Web-Schnittstelle. Die Ausf\u00fchrung von YaST-Clients (Bootloader, iSCSIClient, Kdump, Firewall usw.) in separaten Containern wird unterst\u00fctzt. <\/p>\n Die wichtigsten \u00c4nderungen im dritten Prototyp von ALP: <\/p>\n\n