Die gegenwärtige Generation von Linux-Systemadministratoren ist mit ein paar Gewissheiten aufgewachsen, die quasi in Stein gemeißelt scheinen: Wer Linux im Rechenzentrum betreiben möchte, baut sich sein Setup entweder selbst und auf Grundlage von Debian GNU/Linux oder geht den kommerziellen Weg und kauft ein System mitsamt dem nötigen Support bei einem der großen Hersteller. Die "Enterprise-Distributionen" genügen dabei vor allem dem menschlichen Bedürfnis nach Sicherheit – wer ein Rechenzentrum auf Grundlage von Red Hat Enterprise Linux, SUSE Linux Enterprise Server oder einem vergleichbaren Produkt errichtet, bekommt einen festen Supportzeitraum und mithin vor allem Planungssicherheit.

Das gilt zumindest nach außen hin. Dass in den gängigen Enterprise-Distributionen nämlich oft mehr Schein als Sein steckt, merken Profis, wenn sie unter die Haube schauen. Dort haben einzelne Pakete dann zwar Versionsnummern, die jenen zum Zeitpunkt der ursprünglichen Veröffentlichung des Systems entsprechen. Das im Paket eigentlich enthaltene Programm aber ist deutlich aktueller. Den Kunden muss das allerdings nicht interessieren. Und auch der "Frankenstein"-Kernel, der in diesen Distributionen oft enthalten ist, gibt aus Sicht des Administrators kaum Grund zur Sorge. Denn auch für diese Komponenten verspricht der Hersteller lange Unterstützung.

Aus diesem System heraus hat sich ein gewisser Rhythmus in der gesamten Szene etabliert. Unternehmen schlagen sich häufig nicht mehr mit dem Thema Upgrades herum. Stattdessen wird ein Setup auf Grundlage einer spezifischen Enterprise-Distribution und deren jeweils aktuellster Version aufgebaut und abgewartet, bis die für die Hardware geltende Garantie ausläuft. Dann landet der gesamte Aufbau in der Tonne und das Spiel beginnt quasi von vorne, dann aber natürlich mit der dann jeweils aktuellsten Version der gewählten Enterprise-Distribution. Gelegentliches Murren der eigenen Anwenderschaft ob der zum Teil sehr altertümlichen und fast schon prähistorischen Software bügeln Admins gekonnt ab: Es ginge eben nicht anders, so die häufige Antwort, denn anders sei das Setup kaum sinnvoll plan- und wartbar.

Die Hersteller lassen sich den Zirkus obendrein fürstlich vergüten: Für jedes einzelne System in einem solchen Konstrukt kassieren sie eine Subskriptionsgebühr. Wer erweiterten Support für technisch komplexe Probleme möchte, legt noch mehr Geld auf den Tisch. Und wer es nicht schafft, seine Umgebung zu aktualisieren, bevor die Unterstützung für die dort genutzte Linux-Distribution offiziell ausläuft, zahlt sich dumm und dämlich, um trotzdem weiterhin Support für die eigene Installation zu bekommen. Wenn der jeweilige Hersteller sich auf das Spiel überhaupt einlässt. Gerade bei kleineren Kunden heißt es dann ganz oft einfach "Pech gehabt". Für SUSE, Red Hat und Co. sind die so eingenommenen Subskriptions- und Supportgebühren noch immer das kommerzielle Rückgrat.

Vor dem Hintergrund dieses Wissens geschieht in der Welt der Linux-Distributionen seit einer Weile etwas eher Unverständliches: Sowohl SUSE als auch Red Hat haben an ihre klassischen Enter-prise-Distributionen längst die Axt angelegt und arbeiten an neuen Minisystemen (Bild 1), die RHEL und Co. einst den Garaus machen sollen. Der Grund dahinter liegt in der aufwendigen Pflege von Linux-Distributionen. Schon das Zusammenstellen des Grundsystems und dessen nötigen, kontinuierlichen Aktualisierungen kosten die großen Hersteller Unmengen an Aufwand.

Hinzu kommt, dass Kunden dieser Systeme ja nicht nur Unterstützung für die integralen Komponenten einer Distribution wünschen, sondern auch für deren Anwenderbestandteile. Geht auf einem SLES-System in MariaDB oder PostgreSQL etwas schief, ist der Distributor die erste Anlaufstelle für den Kunden. Die Anbieter müssen also nicht nur ihr Grundsystem im Griff haben, sondern auch die damit ausgelieferten externen Komponenten mit Support und Entwicklung versorgen. Und schon das Bereitstellen der jeweiligen Programme in Form von Paketen für verschiedene Versionen der eigenen Enterprise-Distribution frisst einiges an Kapazität. Von PostgreSQL etwa muss Red Hat im Augenblick mindestens drei Versionen unterstützen, nämlich jene von RHEL 7, 8 und 9. Bei SUSE sieht es mit den verschiedenen SLES-Versionen kaum besser aus.

Und hier kommt die seit Mitte der 2010er-Jahre immer erfolgreichere Container-Virtualisierung ins Spiel: Container bieten schließlich die Möglichkeit, Anwendungen mit dem gesamten von ihnen benötigten Userland im Block auszuliefern. Alles, was dann noch benötigt wird, ist ein abgespecktes Linux-Grundsystem, das außer eines Kernels, ein paar Anwendungsprogrammen sowie einer Laufzeitumgebung für den Betrieb von Containern quasi nichts enthält. Der Clou aus Sicht der Hersteller: Ein solches Linux-System lässt sich viel leichter erstellen und warten als die komplexen Enterprise-Systeme der Gegenwart. Es reduziert den internen Aufwand zudem ganz erheblich. Eigene Software muss zwar immer noch gepflegt werden, das aber wenigstens nur noch einmal.

Red Hat macht es bei der Objektspeicherlösung Ceph vor: Da stehen dieselben Ceph-Container jeweils für RHEL 7, 8 und 9 zur Verfügung. Zu pflegen ist also bloß noch ein Satz an Containern anstelle von drei Sätzen an Paketen. Auch der Aufwand für Fremdsoftware reduziert sich erheblich. Weil es von MariaDB, PostgreSQL und Co. ohnehin fertige Container für die eigenen Anwendungen gibt, verweisen Linux-Anbieter einfach auf diese, anstatt sie selbst zu erstellen. Indirekt wird also ein erheblicher Teil der zuvor selbst erledigten Arbeit ausgelagert und an die Hersteller der Programme zurückgespielt. Freilich wollen die kommerziellen Distributionsanbieter auch weiterhin für die Mikrodistributionen mitsamt Container-Umgebung Geld sehen. Gerade wer auf Support für die Hardware angewiesen ist, wird also auch künftig zur Kasse gebeten. Sorgen im Hinblick auf einen drohenden Bankrott müssen SUSE, IBM als Eigentümer von Red Hat und Canonical sich also eher nicht machen.

Aus Sicht des geneigten Systemadministrators fühlt sich das, was sich am Horizont abzeichnet, schon fast wie die Vertreibung aus dem Paradies an. Denn nach Lage der Dinge ist nicht einmal sicher, ob SUSE, Red Hat oder Canonical ihre Mikrodistributionen in den üblichen Supportzyklen anbieten werden, also mit Unterstützung über einen Zeitraum wie bisher. Es ist durchaus nicht ausgeschlossen, dass die großen Hersteller stattdessen Kompatibilität nur noch für die Laufzeitumgebung der Container in Aussicht stellen. Die Garantie wäre dann, dass sich Container in einem bestimmten Format garantiert über einen Zeitraum von einer bestimmten Anzahl an Jahren betreiben lassen, aber eben nicht das gesamte System.

Administratoren sollten aber ohnehin nicht davon ausgehen, dass sich eine Minidistribution für den Container-Betrieb so verwenden lässt wie die klassischen Enterprise-Distributionen der Gegenwart. Sollten sich findige Entwickler daran machen, die wichtigsten Pakete für diese anzubieten, wird das zumindest ohne Support von Red Hat und Co. sein, sodass sich Admins selbst um Support kümmern müssen. Möglich, dass freie Anbieter in die Bresche springen. Die "Alles aus einem Guss"-Erfahrung gehört aber spätestens dann, wenn die Minidistributionen der Anbieter fertig sind, endgültig der Vergangenheit an. Red Hat hat mit der Transition dorthin bereits in RHEL 9 begonnen, auch weil das Unternehmen einen leichten Entwicklungsvorsprung gegenüber der Konkurrenz hat. In Form von CoreOS haben sich die Rothüte schließlich einen fertigen "Container Player" eingekauft. SUSE arbeitet aktuell noch an der eigenen Interpretation des Prinzips, und Canonical bewegt sich bei Ubuntu mit seinem Beharren auf Snap in exakt dieselbe Richtung.

Aller Ärger hilft aber nichts, denn auch in Zukunft müssen Systemadministratoren ja irgendwie mit Linux in seinen verschiedenen Darreichungsformen arbeiten. Kluge Unternehmen tun gut daran, vor diesem Hintergrund die "schöne neue Welt" bereits heute in ihre Überlegungen einzubeziehen. Dann können sie die strategischen Weichen stellen, um sich auf die neue Situation einzustellen – und derer sind einige nötig, die beinahe alle Aspekte des Admin-Alltags betreffen.

Der erste Schritt zum Erfolg ist dabei so einleuchtend wie unbeliebt bei Admins und Unternehmen gleichermaßen: Es gilt, sich mit der neuen Situation anzufreunden oder diese zumindest zu akzeptieren. Von einer Ausnahme im Hinblick auf Debian GNU/Linux (Bild 2) abgesehen, die wir später noch genauer betrachten, ist davon auszugehen, dass Container und Container-Management etwa mit Kubernetes bei den großen Herstellern nach und nach zum Standard werden. Die beschriebenen kommerziellen Vorteile, die dieses Konzept mit sich bringt, sind viel zu attraktiv für die Hersteller, um sie nicht auszukosten. Das möchten Nutzer eines der großen Systeme schlecht finden, es ist aber nicht zu ändern.

Zumindest im Moment vertreten viele Admins auf Stammtischen und bei Konferenzen noch die Meinung, sie würden sich mit dem "modernen Container-Kram" nicht befassen, weil es sich dabei um eine Laune der Zeit handele. Wer so an die Sache herangeht, läuft allerdings Gefahr, eine große Menge an Arbeit und Migration ad hoc investieren zu müssen, wenn die klassischen Enterprise-Distributionen dann wirklich vom Markt verschwinden. Wer stattdessen jetzt akzeptiert, dass es dem althergebrachten SLES oder RHEL sukzessive an den Kragen gehen wird, kann sich sinnvoll auf die neue Situation einstellen und entsprechende Vorbereitungen angehen. Auch bei den Herstellern verschwinden die bestehenden Systeme schließlich nicht von heute auf morgen, sondern sukzessive. Entsprechende Anzeichen dafür gibt es allerdings schon jetzt.

Wer sich mit den Tatsachen abfindet, schafft das Fundament für die eigene Vorbereitung. Und die ist einigermaßen umfangreich. Ein zentraler Punkt dabei ist die Schulung des eigenen Personals. Wissen rund um Container und deren Flottenorchestrierung ist in der Branche insbesondere hierzulande immer noch recht rar gesät. Das mag daran liegen, dass vielerorts das Prinzip "Kennen wir nicht, brauchen wir nicht, weg damit" gilt, aber das hilft nicht weiter. Unternehmen tun stattdessen gut daran, ihre Sysadmins früh für den Umgang mit Containern und Kubernetes zu schulen. Unterschiede im Alltag der Systemadministration gibt es dabei durchaus. Das geht bei den Basics los: Zwar verpacken viele Distributoren ihre Container auch wieder in Start- und Stop-Units für Systemd. Arbeitet ein Container aber nicht wie erwünscht, hilft Systemd nur bedingt weiter.

Das reine Starten und Stoppen der Container genügt dann nicht. Stattdessen gilt es, die Grundlagen des Containerbetriebs zu erlernen, zumindest also den Umgang mit den Laufzeitumgebungen von Docker und Podman. Auch schadet es nicht, die innere Struktur eines Containers zu kennen und Container selbst bauen zu können. Denn diese bringen durchaus Vorteile mit sich, gerade im Hinblick auf den Betrieb. Wer eigene Anwendungen ausrollen möchte, erledigt das in einer Container-basierten Umgebung idealerweise ebenfalls auf Grundlage von Containern und schafft sich damit die Notwendigkeit vom Hals, Debian- und RPM-Pakete zu erzeugen. An ihre Stelle tritt im besten Fall eine Umgebung für Continuous Integration und Continuous Development (CI/CD), die Container basierend auf Quelltext in Git nicht nur baut, sondern auch gleich kontrolliert im Produkt ausrollt. Wer sich Gedanken darüber macht, den eigenen Workflow im Unternehmen auf DevOps auszurichten, hat hier also die sehr gute Gelegenheit dazu.

Obendrein bilden Container im Gespann mit Lifecycle-Management-Lösungen für die Hardware ein hervorragendes Team. Wenn die gesamte Konfiguration eines Hosts in Git liegt, also als Infrastructure as Code (IaC), lässt sich jedes System auf Knopfdruck neu ausrollen. Dadurch entfällt ein langes und mühsames Debugging einzelner Systeme nach fehlerhaften Konfigurationsänderungen. Container, CI/CD, Lifecycle Management und Automation bilden sozusagen einen Dreiklang der modernen Systemadministration.

Darüber hinaus unterscheidet sich der Umgang mit Containern im Alltag auch an anderen Stellen von dem mit Anwendungen, die direkt im System installiert sind. Kommandozeilenwerkzeuge etwa, die zuvor per Paket auf das System gekommen sind, liegen dann nur noch in Containern vor. Das mag wie eine Lappalie klingen, treibt viele Administratoren gerade anfangs aber in den Wahnsinn. Hier ist etwas Umgewöhnung nötig, um gerüstet zu sein, wenn der Übergang wirklich ansteht.

Für viele Unternehmen mag obendrein Kubernetes ein deutlich interessanteres Thema sein, als es eingangs den Anschein hat. Bei allen Horrorgeschichten, die über K8s kursieren, ist das Werkzeug für basale Aufgaben der Containerorchestrierung noch immer nützlich und funktional. Wer etwa ein Setup bauen muss, bei dem Apps in spezifischer Reihenfolge auszurollen sind und anschließend miteinander reden müssen, spart sich durch K8s im günstigsten Fall viel Aufwand und Mühen. Verschlüsselte Verbindungen zwischen den einzelnen Apps lassen sich mit Lösungen wie Istio beispielsweise viel leichter erreichen als in klassischen Umgebungen. Dasselbe gilt für Loadbalancer, die Kubernetes automatisiert ausrollen kann. Es schadet also nicht, wenn Administratoren auch von Kubernetes grundlegend Ahnung haben.

Hat das eigene Personal die grundlegenden Unterschiede erlernt, gilt es, das gesammelte Wissen konkret im Alltag zu trainieren und zu erweitern. Das kann beispielsweise bedeuten, das eigene bestehende Setup im Labor auf Container-Basis neu zu bauen und dabei so gut wie möglich zu automatisieren. Hier wird die laufende Produktion nicht gestört und es ist letztlich ein fließender Übergang machbar. Der eigentliche Umstieg von klassischem Enterprise-Linux auf das Container-Modell ist dann gar nicht mehr die große Sache. Auch die Konstruktion eigener Container sollte in diesem Kontext auf der Liste der Aufgaben stehen, die der Administrator regelmäßig übt. Der Vorteil: Geht etwas schief, entsteht durch das Debugging der Umgebung ein zusätzlicher Lerneffekt. Der hilft gerade in Problemsituationen später noch einmal.

Ist absehbar, dass das aktuelle Setup das Ende seines Lebenszyklus erreicht, sollte beim nächsten großen Update die Migration hin zu Containern im Fokus stehen. Wer, wie vorgeschlagen, ohnehin schon mit Containern arbeitet und mit diesen auch experimentiert, wird sich hier deutlich leichter tun als jemand, der auf der grünen Wiese erst dann mit der Lernerei beginnt. Möglichst lange im Vorfeld sollten die wesentlichen Faktoren dann aber auch klar sein, ganz konkret:

- Welche Hardware kommt zum Einsatz und soll diese mit einem automatischen Lifecycle-Management verwaltet werden?

- Falls ja, welches Werkzeug findet dabei Verwendung?

- Welche Automationslösung kommt zur Anwendung, um Systeme nach der Installation mit einer grundlegenden Konfiguration zu betanken?

- Wer installiert und steuert die Container, wie erhalten diese ihre Konfiguration?

Es hat sich eingebürgert, die Containerkonfiguration ganz normal in Dateien in "/etc" des Host-Systems zu installieren und in die Container mittels Bind-Mount einzubinden. Dafür müssen etwa entsprechende Units für Systemd aber fertig bereitliegen, um einen möglichst glatten Übergang zu ermöglichen. Soll Kubernetes zum Einsatz kommen, muss auch dieses in den Planungen enthalten sein.

Eine Sonderrolle nimmt beim Umstieg auf containerbasierte Setups das Thema Vertrag ein. Wie beschrieben werden die großen Distributoren wohl irgendwann dazu übergehen, anstelle selbst konzipierter Container für die klassischen Anwendungen auf die Container der jeweiligen Hersteller zu verweisen. Gut möglich, dass in den dann zu kaufenden Supportverträgen zwar noch eine grundsätzliche Unterstützung für diese enthalten ist. Denkbar ist aber auch, dass Kunden künftig für spezielle Anwendungen anstelle des umfassenden Supportvertrages des Herstellers einzelne Supportverträge mit den jeweiligen Anbietern brauchen.

Hier befindet sich aktuell noch zu viel in der Schwebe, um bereits jetzt verlässliche Aussagen treffen zu können. Möglich ist etwa auch, dass die großen Linux-Anbieter entsprechende Supportpakete der Anwendungshersteller wiederverkaufen werden und dass Firmen nominal also weiterhin nur einen Vertrag haben, der dann aber im Hintergrund auf mehrere Supportverträge etwa bei MariaDB, PostgreSQL und Co. zeigt. Das allerdings dürften sich die Anbieter dann auch wieder entsprechend vergüten lassen. Hier kommt IT-Verantwortlichen die Aufgabe zu, die Entwicklungen am Markt zu beobachten und frühzeitig entsprechende Vorkehrungen zu treffen.

Wer sich mit Containern überhaupt nicht anfreunden möchte, kann womöglich noch eine kleine Hintertür nutzen, die zumindest etwas zeitlichen Aufschub gewährt. Denn während die Marschrichtung bei den großen, etablierten Herstellern von Linux-Distributionen klar ist, gilt auch Debian als ausgezeichnete Wahl für Setups mit relativ langem Support. Dass die Debian-Entwickler sich allerdings recht bald dazu durchringen werden, die etablierte Distribution einzustampfen und bloß noch einen Containerabspieler anzubieten, darf als äußerst unwahrscheinlich gelten. Schließlich haben die Verantwortlichen bei Debian mehrere Jahre gebraucht, bis sie sich auch nur auf die Einführung von Systemd einigen konnten – eine Änderungen, die zum Zeitpunkt der Debian-Entscheidung bei allen anderen großen Distributoren schon ein ganzes Weilchen zurücklag.

Dem geneigten Debian-Entwickler, zu deren Riege auch der Autor dieses Artikels gehört, gehen Stabilität und Planbarkeit praktisch über alles. Gut möglich, dass eine Mikrodistribution auf Debian-Basis parallel zum existierenden klassischem System entsteht. Dass sie dieses verdrängt, scheint im Moment aber ausgeschlossen. Wer mit der Containerei der etablierten Anwender nichts anzufangen weiß, kann vorerst also auch auf Debian ausweichen, für das sogar kommerzieller Support zur Verfügung steht. Vielerorts ist das ein entscheidender Faktor hinsichtlich der Frage, ob eine Software überhaupt zum Einsatz kommen darf.

Überspannen sollten Admins diesen Bogen aber auch nicht. Denn Debian ist auf die Mithilfe von Freiwilligen angewiesen – und auch die werden künftig in eine Linux-Welt hineingeboren werden, in der Container allerorten den Ton angeben. Spätestens wenn die Anbieter klassischer Anwendungen beginnen, ihre Entwicklungsprozesse auf Container hin zu optimieren und den Bau von Paketen selbst nicht mehr vollziehen oder entstören, wird Debian kaum die Ressourcen aufbringen können, um parallel trotzdem klassische Pakete zu pflegen.

Für das Gros der Anwender sind Container eine unvermeidliche Komponente der Gegenwart. Es ist daher ratsam, sich schon jetzt mit deren Handling anzufreunden, auch Kubernetes nicht links liegen zu lassen und ein wachsames Auge auf die Container-Entwicklungen beim eigenen Lieblingsdistributor zu haben. Wer sich etwas Zeit verschaffen möchte, kann vorerst auf Debian ausweichen. Eine sichere Wette auf die Zukunft ist das aber nicht. Wie üblich gilt: Wer nicht mit der Zeit geht, muss mit der Zeit gehen.