© Paolo De Santis, 123RF

Container-only-Distributionen florieren: Anders als die klassischen Systeme begnügen sie sich mit einer absoluten Software-Minimalausstattung, was die Wartung radikal vereinfacht.

Wer als Linux-Admin bereits ein paar Lenze hinter sich gebracht hat, stellt fest: Gerade im vergangenen Jahrzehnt hat sich in der IT zumindest dem Gefühl nach mehr verändert als jemals zuvor. Die Cloud mischte die Branche ab 2010 auf, und spätestens seit 2015 rücken Container zunehmend in den Fokus des Interesses.

Zwar frisst die Container-Revolution mittlerweile schon wieder ihre Kinder, doch ist an eine Rückkehr zum vorherigen Status quo aus heutiger Sicht nicht zu denken: Im Fahrwasser von Cloud und Containern haben sich ja noch etliche andere Ansätze etabliert. Automation etwa gilt heute nicht mehr als schickes Feature, sondern als schiere Notwendigkeit. Wo man vor 15 Jahren noch munter Sicherheitsupdates händisch auf Systemen einspielte, regieren heute automatische Installationsprogramme, Ansible oder andere Automatisierer.

Container-Automatisierung geht mittlerweile sogar noch einen Schritt weiter, in Form von Mikrobetriebssystemen. Das hat mit Mikrokerneln nichts zu tun, sondern bezieht sich auf die Software-Menge, die Teil des Produkts ist. Die erste Devise bei Container-Automation lautet heute, die auf den Systemen benötigte Software immer weiter zu reduzieren. Das soll Wartungsaufwand vermeiden, denn wo nichts ist, muss man auch nichts aktualisieren und warten.

Dieser Artikel erklärt zunächst das grundlegende Prinzip des Ansatzes und stellt im Anschluss K3OS [1] sowie Flatcar [2] vor, zwei Mikrodistributionen, die sich als Alternative zu den Systemen der etablierten Hersteller verstehen.

Worum es bei Mikrodistributionen geht

Die großen Hersteller haben Administratoren über Jahrzehnte hinweg konsequent darauf trainiert, mit immer komplexeren Systemen zurechtzukommen. Eine Distribution ist im Kern ja eigentlich nichts anderes als ein kompilierter Linux-Kernel, der zusammen mit einer riesigen Menge administrativer Werkzeuge den Weg auf die Festplatte eines Servers findet.

Gerade aktuelle Systeme sind mit erheblicher Komplexität verbunden. Ein typisches Beispiel dafür bieten die Paketmanager: Damit Admins nicht selbst jedes Programm kompilieren müssen, liefern die Distributoren viele Programme in paketierter Form aus. Damit die Möglichkeit besteht, diese zu aktualisieren, wenden Paketmanager eine ganze Menge Tricks und Kniffe an, die Ungemach verhindern sollen (Abbildung 1). Debian etwa geht in Dpkg viele Kompromisse ein, um das Überschreiben von Änderungen in »/etc« durch Pakete zu verhindern.

Abbildung 1: RPM und Dpkg dominieren klassische Distributionen und haben mit einer Mikrodistribution nicht viel zu tun: Über 1000 Pakete pro System sind eher die Regel als die Ausnahme.

Jeder Admin weiß allerdings aus Erfahrung, dass alle Magie beim Paketmanager nicht hilft: Updates von einer Major-Version auf eine andere bleiben eine Herausforderung. Im schlimmsten Fall geht etwas schief, und das System ist offline – Minuten, Stunden, manchmal Tage. Dass High Availability (HA) heute zum Standardumfang gängiger Distributionen gehört, tröstet nur wenig, denn die Komplexität, die HA-Software einführt, ist selbst gigantisch.

Beim Paketmanager hören die Probleme jedoch längst nicht auf. Vergleicht man etwa die Art und Weise, wie Linux-Systeme ihre Netzwerkkonfiguration noch vor ein paar Jahren erledigt haben, mit NetworkManager & Co., fällt auf: Die immer größere Funktionsvielfalt erkaufen Hersteller mit Komplexität, die am Ende der Admin handhaben muss.

Container eröffnen neue Möglichkeiten

Ein Teil der Komplexität lässt sich kaum beseitigen. Verfügen Systeme etwa über mehrere Bonding-Schnittstellen, auf denen dann VLANs liegen, die über eine Netzwerkbrücke angesteuert werden, ist die Konfiguration des Netzes auf diesem Server zwangsläufig komplex. An anderen Stellen lässt der Rotstift sich aber durchaus ansetzen – und Mikrodistributionen machen vor, wie das geht.

Schon als Docker vor ein paar Jahren Container-Virtualisierung unter Linux endlich salonfähig machte, herrschte bei den Distributoren Goldgräberstimmung: Docker bot seinerzeit eine realistische Perspektive, sich von Teilen des Paketmanagements zu verabschieden. Statt Software in Form von RPM-Paketen auf das System zu holen, würden Admins künftig einfach den passenden Container laden und starten. Weil jeder Container ein in sich geschlossenes System ist, liegen ihm sämtliche Abhängigkeiten der jeweiligen Applikation bei. Tatsächliche Nutzdaten werden dem Container zur Laufzeit ganz banal per Mount übergeben. Steht ein Update an, lädt der Anwender den neuen Container mit der neuen Programmversion, hängt das Volume vom alten Container ab und an den neuen an, und startet diesen – fertig.

In diesem Workflow ändern sich die Spielregeln allerdings gewaltig: Ein unter Linux laufendes System mutiert von einer komplexen Umgebung zu einem banalen Tool für den Betrieb von Containern. Dafür braucht es auf der Systemseite gar nicht mehr viel Software: Den Kernel, ein paar grundlegende Komponenten wie Systemd oder ein Cluster-Konsens-Werkzeug wie Etcd oder Consul, die Laufzeitumgebung für die Container selbst (heute also wahlweise Docker oder Podman), und damit ist man eigentlich schon fertig. Dass die Distributoren genau diesen Weg gehen, kann man schon daran erkennen, dass sowohl Red Hat als auch Canonical mittlerweile Paketmanager haben, die auf Container-Prinzipien fußen. Die Snaps bei Ubuntu (Abbildung 2) sowie die Flatpacks in Fedora sind nichts anderes als Werkzeuge, um Container-Abbilder wie herkömmliche Pakete zu laden und zu verwalten.

Abbildung 2: Canonical macht es mit Snaps vor: Das Grundsystem lässt sich mit dieser Technik auf eine Rumpfinstallation begrenzen.

Container-Orchestrierer helfen

Wobei zur Wahrheit auch gehört: Betriebskonzepte, bei denen der Admin einzelne Anwendungen in Container-Form auf Systemen händisch betreibt, sind zwar mit diesen Lösungen möglich. Im Fokus der Distributoren stehen aber ganz eindeutig die Container-Orchestrierer und allen voran Kubernetes.

Das ideale Szenario sieht dann so aus: Eine grundlegende Installation des OS umfasst nur noch die Laufzeitumgebung für Container und Kubelet, also den Steueragenten in Kubernetes. Sobald ein Knoten online geht, wird er automatisch Teil der Flotte, die Kubernetes verwaltet. Alle Veränderungen am System sowie das Starten und Stoppen von Diensten und Containern geschieht durch Kubernetes hindurch, von Hand erledigt der Administrator auf dem System also gar nichts mehr.

Dadurch sinkt der Infrastrukturaufwand pro Knoten für den Admin noch einmal erheblich, denn der Container-Orchestrierer läuft ja so oder so. Ohne Kubernetes oder eine entsprechende Alternative ist der Betrieb von Containern nicht nur ineffizient, sondern letztlich zwecklos.

K3OS und Flatcar: Ähnliche Methode, andere Ziele

Nun nachdem klar ist, worum es bei den Mikrodistributionen eigentlich geht, besteht die Gelegenheit, zwei Vertreter dieser Kategorie im Detail zu studieren. Die meisten Admins dürften schon einmal von JeOS (Abbildung 3) oder CoreOS gehört haben, denn das sind die Mikrodistributionen der etablierten Hersteller Suse und Red Hat.

Abbildung 3: Suses Mikrodistribution JeOS ist eine direkte Konkurrenz zu K3OS und Flatcar.

K3OS und Flatcar hingegen gehen als Underdogs ins Rennen und sind vielen Administratoren vermutlich kein Begriff. Die folgende Beschreibung will indes nicht die Produkte vergleichen, denn sie orientieren sich an unterschiedlichen Faktoren und sprechen zum Teil andere Zielgruppen an. Eher geht es also um einen kurzen Überblick jeweils zum Produkt selbst.

K3OS für Kubernetes-Liebhaber

K3OS richtet sich speziell an Anwender, die K3s [3] benutzen wollen. Wer K3s noch nicht kennt, aber regelmäßig im Kubernetes-Kontext unterwegs ist, kann sich zumindest denken, dass die Abkürzung wohl etwas mit Kubernetes zu tun hat: Das wird üblicherweise mit K8s abgekürzt. K3s versteht sich als eine vollständig zu Kubernetes kompatible Distribution des Orchestrierers, die leichter zu bedienen sein will, kleiner ist und mit weniger Abhängigkeiten daherkommt.

Außerdem ist K3s ab Werk mit Paketfilterregeln versehen, die laut Aussage der Entwickler die Sicherheit der gesamten Installation erhöhen. Zu guter Letzt greift K3s dem Admin an einer Stelle unter die Arme, wo es dem gut in den Kram passt: Eine der lästigsten Eigenschaften von Kubernetes besteht darin, auf jedem Kubernetes-Worker (“Kubelet”) eine Port-Freigabe für eben diesen Dienst einzurichten, damit der Kubernetes-Manager mit den Kubelets sprechen kann.

K3s exponiert die API-Schnittstelle stattdessen per Websocket-Tunnel, sodass Port-Freigaben kein Problem mehr sind. Wer sich in der Firma mit etwaigen Firewall-Konstrukten und Compliance-Regeln zu befassen hat, wird diesen Umstand mögen.

Viel unter der Haube

Zusätzlich bündelt K3s diverse Kubernetes-Erweiterungen so, dass sie ad hoc einsatzbereit sind. Containerd und Runc dienen als Laufzeitumgebungen für die Container, Flannel kümmert sich um das Netz dazwischen. CoreDNS, Helm und Kine sind ebenfalls ab Werk an Bord. Über selbst geschriebene Werkzeuge erleichtert K3s es dem Admin, benötigte SSL-Zertifikate zu pflegen sowie Etcd als Konsens-Algorithmus zu verwalten.

K3s musste allerdings Federn lassen, um ein leichteres Kubernetes zu werden: Die Storage-Treiber, die K8s ab Werk enthält, fehlen in K3s ebenso wie die Funktionalität zur Kommunikation mit Cloud-Anbietern. Weil Kubernetes aber selbst gerade an diesen Stellschrauben dreht und die vorhandenen Funktionen durch neue Wege ersetzt, dürfte dieser Punkt für die meisten Admins kein Problem darstellen.

K3OS ist kein Fork einer bestehenden Linux-Distribution. Das ist durchaus ungewöhnlich: Die meisten Projekte, die heute Mikrodistributionen bauen, nehmen dafür eine vorhandene Distribution und erleichtern sie um die Komponenten, die aus Sicht der Maintainer nicht notwendig sind. K3OS basiert im Kern auf einer Mischung aus einem Alpine-Userland und dem Kernel von Ubuntu 18.04. Dabei bauen die Entwickler die einzelnen Komponenten so zusammen, dass sie für K3OS so gut wie möglich harmonieren.

Klar ist aber auch: Die Bewertungskriterien, die bei klassischen Distributionen gelten, spielen bei Mikrodistributionen bloß noch eine untergeordnete Rolle. Im Grunde muss das System lediglich sämtliche Hardware des Servers unterstützen, und dafür ist ein aktueller HWE-Kernel von Ubuntu mit Sicherheit keine schlechte Idee.

Automation geht, ist aber seltsam

Etwas abenteuerlicher mutet da schon die Art und Weise an, wie K3OS den Weg auf die Festplatte findet – oder nach Meinung der Entwickler auf die Platte finden soll. Eines mächtigen Automations-Frameworks wie Preseedint, Anaconda oder AutoYaST bedienen die K3OS-Macher sich nämlich nicht.

Stattdessen gibt die Kommandozeile, die der Kernel beim Systemstart mit auf den Weg bekommt, die Art der gewünschten Installation an. Obendrein kann K3OS sich direkt aus einem laufenden Linux-System heraus auf die Platte bringen – dazu verändert es die Partitionierung der Platte und anschließend die Grub-Konfiguration. Die klassische Installation per ISO-Datei sehen die Entwickler allerdings ebenfalls vor.

Werkzeuge zum Konfigurieren von IP-Adressen und ähnlichen Einstellungen sucht der Admin indes vergebens. Diese Details bekommt ein mit K3OS laufender Host alle automatisch aus dem dafür zuständigen Operator in K3s. Sobald also der Kubelet-Agent auf dem Host läuft, erfährt er, wie er zu konfigurieren ist. Wie in Clouds üblich, kommen dafür zudem Protokolle wie DHCP zum Einsatz.

Im Grunde gilt: K3OS (Abbildung 4) ist so eng mit K3s verzahnt und auf den Einsatz damit ausgelegt, dass es kaum sinnvoll ist, sich das System ohne Interesse an K3s genauer anzusehen: In diesem Fall erhält man ein weitgehend nicht erweiterbares Basis-Linux. Selbst für den Einsatz mit anderen Kubernetes-Distributionen eignet K3s sich kaum, weil es einen Teil der dort üblichen Standard-Konfiguration nicht übernimmt. Der Umkehrschluss ist jedoch absolut zulässig: Wer K3s benutzen möchte, sollte sich K3OS auf jeden Fall genauer anschauen.

Abbildung 4: K3OS ist speziell auf die Bedürfnisse von Rancers Kubernetes-Distribution K3s abgestimmt. Quelle: Rancher

Den roten Hüten zum Trotz: Flatcar

Bei der zweiten Mikrodistribution im Vergleich handelt es sich eigentlich nicht um ein neues Projekt, sondern vielmehr um einen alten Bekannten. Red Hat hat erwiesenermaßen ein gutes Händchen dafür, Unternehmen aus dem Open-Source-Umfeld zu kaufen und sie groß herauszubringen. Dafür gibt es zahllose Beispiele. Erinnert sei etwa an Ceph, das seit der Übernahme durch Red Hat zur Quasi-Standardlösung für Software Defined Storage geworden ist.

Ein ähnlich glückliches Händchen dürfte der Hersteller mit CoreOS gehabt haben, das seit 2018 zu Red Hat gehört. CoreOS galt mit seiner Mikrodistribution als Vorreiter für die gesamte Branche. Nicht nur das Betriebssystem geht auf das Konto der gleichnamigen Firma, CoreOS erfand auch eine Reihe weiterer Komponenten, die im Container-Kontext heute praktisch unverzichtbar sind. Exemplarisch erwähnt seien der Cluster-Konsens-Algorithmus Etcd sowie Flannel und Prometheus, an denen CoreOS emsig mitgearbeitet hat.

Aus Sicht der roten Hüte war es folgerichtig – fast schon notwendig –, CoreOS zu kaufen: Einerseits konnte man so dessen Open-Source-Eigenschaften sichern, andererseits passten die CoreOS-Produkte hervorragend in Red Hats gerade auf links gedrehtes Kubernetes-Portfolio mit Open Shift. So tat Red Hat direkt nach der Akquisition, womit zu rechnen war: Red-Hat machte CoreOS zum Zentrum neuer Produkte, aus CoreOS wurde Red Hat CoreOS (RHCOS) und Fedora CoreOS.

Im Laufe dieser Entwicklung veränderte CoreOS sich allerdings kontinuierlich, mittlerweile ist es an vielen Stellen nicht mehr kompatibel zur ursprünglichen Variante.

Gerümpfte Nasen im CoreOS-Lager

Deshalb hat Red Hat die alte Stand-alone-Variante von CoreOS offiziell abgekündigt, spätestens ab Ende Oktober 2020 soll Schluss sein. Das indes schmeckt längst nicht jedem: Kritiker monieren zu viel Einfluss durch Red Hat und fürchten, dass CoreOS sich absehbar nicht mehr ohne den Segen aus Raleigh verwenden lässt.

Hinzu kommt der Frust darüber, auf ein neues Betriebssystem umsteigen und bestehende Workloads daran anpassen zu müssen. Wer schon ein komplettes Lifecycle-Management für seine Container-Flotte hat, sieht den Sinn für den Umstieg nicht. Dasselbe gilt für Drittanbieter, die Anwendungen für CoreOS entwickeln und durch Red Hats Schritt ebenfalls Mehraufwand leisten müssten, ohne dafür technische Gründe zu sehen.

Die Berliner Consulting- und Entwicklungsfirma Kinvolk ging daraufhin in die Offensive und forkte CoreOS auf Basis der letzten stabilen Version. Dieses Projekt trägt den Namen Flatcar Linux. Kinvolk verspricht, Flatcar als inoffiziellen Quasi-Nachfolger für CoreOS auf absehbare Zeit zu pflegen und kompatibel zu CoreOS zu halten. Auch nicht unwichtig für Firmenkunden: Das Unternehmen offeriert kommerziellen Support für das System.

Allerhöchste Eisenbahn für die Migration

Auf der Website des Projekts stellt das Team hinter Flatcar ISO-Abbilder für die Installation zur Verfügung. Alternativ lässt die Mikrodistribution sich mittels eines netzwerkbasierten Deployment-Werkzeugs ausrollen. Obendrein ist eine Migration von CoreOS auf Flatcar Linux möglich, um nicht zu sagen notwendig: Wenn der Hersteller für das alte System ab November keine Updates mehr liefert, ist es für eine Migration bereits allerhöchste Eisenbahn.

Eine Migration von CoreOS auf Flatcar Linux sollte man sich dabei jedoch nicht so vorstellen, wie man es bei einer klassischen Linux-Distribution etwa während eines Major-Updates erwarten würde. Das Projekt achtet wie beschrieben darauf, dass Flatcar Linux zu CoreOS kompatibel bleibt. Der Admin migriert ein System deshalb problemlos im laufenden Betrieb. Wer funktionierende Automation für das Lifecycle Management von Servern implementiert hat, kann alternativ bestehende Server leer migrieren und neu installieren.

Was davon schneller und bequemer funktioniert, hängt vom jeweiligen Einsatzszenario ab. Praktisch ist hierbei allerdings, dass man Flatcar Linux mit Matchbox und Ignition installieren kann, so wie es bei CoreOS der Fall war.

Eins-zu-eins-Nachfolger für CoreOS

Einmal ausgerollt, hält Flatcar Linux das Versprechen, ein Eins-zu-eins-Nachfolger für CoreOS zu sein. Sämtliche von CoreOS bekannten Dienste gehören ebenfalls zum Lieferumfang, wie etwa die gewohnte Kommandozeilenumgebung. Etcd lässt sich in wenigen Sekunden als zentraler Konfigurationsspeicher im Cluster-Modus zwischen den verschiedenen Flatcar-Instanzen etablieren. Erhalten bleiben sollen zudem die Mikro-Updates für die einzelnen CoreOS-Komponenten, die sich im laufenden Betrieb problemlos einspielen lassen.

Knapp zusammengefasst: Wer Flatcar Linux installiert, bekommt im Grunde ein CoreOS mit Update-Versprechen. Das kann dann als generische Basis etwa für Kubernetes dienen. Auf eine bestimmte Kubernetes-Distribution legt Flatcar den Nutzer dabei nicht fest – Kinvolk vertreibt sogar ein eigenes Kubernetes als Open-Source-Produkt namens Lokomotive, das sich auf Flatcar-Systemen nutzen lässt.

Als praktisch erweist sich zudem der Update-Service von Kinvolk. Dabei handelt es sich im Grunde um eine zentralisierte Patch-Verwaltung für eigene Flatcar-Linux-Instanzen, die eine gewisse Ähnlichkeit beispielsweise mit Ubuntus Landscape aufweist, aber auf dem Open-Source-Projekt Nebraska fußt (Abbildung 5)

Abbildung 5: Auf Basis von Nebraska bietet Kinvolk einen zentralen Update-Dienst für Flatcar Linux an. Quelle: Nebraska

Zumindest einen kleinen Stich hat das Flatcar-Linux-Glück jedoch. Wer als Maintainer oder im Rahmen eines Linux-Projekts schon einmal eine eigene Distribution gepflegt hat, der weiß um den Aufwand dahinter. Naturgemäß ist der bei Mikrodistributionen zwar kleiner als etwa bei einem ausgewachsenen Debian, ein gutes Stück Manpower ist nichtsdestotrotz nötig. Ob Kinvolk das langfristig zu stemmen vermag, muss sich noch herausstellen.

Ebenfalls wenige Informationen findet man hinsichtlich der Frage, ob und inwiefern Kinvolk neue Funktionen über Updates bereitstellen möchte. Dass man auf absehbare Zeit mit dem ursprünglichen CoreOS kompatibel bleiben will, ist für bereits existierende Produkte und Workloads sicher eine große Erleichterung. Die Erfahrung zeigt jedoch, dass Begehrlichkeiten nach neuen Features früher oder später nicht zu vermeiden sein werden. Wie Kinvolk damit umgeht, kann nur die Zeit zeigen.

Mahnende Worte

Am Ende dieses Artikels ist es nicht zu vermeiden, auf die Schattenseiten der Container-Manie einzugehen. Klar ist: Container erlauben dem Admin diverse Abkürzungen und machen die Wartung und den Betrieb von Linux-Systemen leichter als bisher.

Wer obendrein streng auf offizielle Container setzt und sie direkt von den jeweiligen Entwicklern, per Kubernetes Helm oder als Snap oder Flatpack bezieht, braucht sich um das Thema Sicherheit keine Sorgen zu machen – jedenfalls nicht mehr als bisher bei Paketen: Auch bei ihren Container-Abbildern machen die Distributoren einen guten Job und aktualisieren diese im Gleichschritt mit dem Bekanntwerden von Sicherheitslücken.

Keine gute Idee ist es hingegen, beliebige Container-Abbilder aus dem Netz zu fischen und auszurollen. Egal, ob man sich für K3OS, für Flatcar oder eine andere Mini-Distribution entscheidet: Deren Vorteile sind in der Regel für die Katz, wenn man sich dann eine Blackbox in Form einer Applikation ins Haus holt. Zwar sind Container für Docker & Co. schnell gebaut, “in VMware auf meinem MacBook Air läuft’s” ist aber kein funktionaler Maßstab für die Produktion.

Sinnvoller ist es da schon, eigene Container-Abbilder für die Anwendungen zu bauen, die man auf Flatcar & Co. betreiben möchte. Das allerdings bedingt einen funktionalen CI/CD-Ansatz, an dessen Ende ein Git-Commit dafür sorgt, dass aus einem Git-Verzeichnis ein lauffähiger Container wird. Ein solches System aufzusetzen ist zwar durchaus komplex, doch lässt die Arbeit sich gut automatisieren.

Im Gegenzug profitiert der Admin von schlanken Systemen und komplett automatisiert gebauten Containern, bei denen sich Bugs im Alltag schnell reparieren lassen. Dieses auch Immutable Underlay genannte Konzept sollte im Jahr 2020 für neue Umgebungen die Messlatte sein. Die Hersteller der großen Distributionen dürften jedenfalls ihr Möglichstes tun, ihre Nutzer in exakt diese Richtung zu drängen.

Fazit

Mikrodistributionen bilden den logischen nächsten Automationsschritt in einer Welt, in der Container immer mehr Relevanz erlangen. Bei allen großen Linux-Distributoren lässt sich klar erkennen, dass sie die Zukunft von Linux-Servern in der Container-Ecke sehen. Weil sich heute sehr viel Funktionalität, die früher klassisch auf dem System selbst lief, in Container verpacken lässt, bietet sich eine wunderbare Gelegenheit, Komplexität aus dem Setup zu entfernen.

Genau darauf zielen K3OS und Flatcar ab: Das laufende System soll so wenige lose Teile wie möglich haben. Die wenigen Komponenten, die man noch benötigt, gehören bei beiden Ansätzen bereits zum Lieferumfang. Dass K3Os sich auf die Kubernetes-Distribution K3s spezialisiert und Flatcar eher Nutzer des vorherigen CoreOS ansprechen möchte, ist da eigentlich nur ein Nebenaspekt.

Admins sollten das Thema Container jedenfalls verfolgen, und K3OS und Flatcar bieten gute Ansätze, um das Prinzip zu verstehen. Das dürfte in Zukunft nötiger werden denn je. RHEL 8 offeriert mittlerweile ja Paketverzeichnisse, die auf Containern basieren und die sich nahtlos in die Verwaltungswerkzeuge integrieren.

Gut möglich, dass Podman & Co. irgendwann das Ende von RPM und Dpkg einläuten: Aus Sicht der Distributoren bieten Programme, die in Container-Form ihren Weg zu den Nutzern finden, einen unschlagbaren Vorteil. Statt ein bestimmtes Programm für jede Version einer Distribution zu pflegen, genügt es bei Containern, genau einen Container mit dem passenden Programm für alle unterstützten Distributionen zu haben. Canonical hat diese Karte bei Ubuntu auf dem Desktop bereits gezogen, sodass Anwendungen wie Chromium ab Werk nur noch als Snap beiliegen.

Falls das Prinzip funktioniert – und danach sieht es momentan sehr aus – dürften sich die etablierten Hersteller mehrmals überlegen, ob sie nicht ausschließlich diesen Weg gehen. Es bleibt also spannend. (jcb)