Das Problem ist, die lokale Umgebung an die echte anzugleichen

In der Entwicklung muss regelmaessig das Verhalten eines Clusters auf dem Notebook nachgestellt werden: ein Abbild laufen lassen, um zu sehen, was es tut, pruefen, ob eine Konfiguration sich wirklich anwenden laesst, eine Kubernetes-Fassung ausprobieren, bevor das Update alle erreicht. Rancher Desktop sammelt das in einer einzigen Anwendung. Hinter dem Fenster startet eine schlanke virtuelle Maschine, darin laufen eine Container-Engine und ein Kubernetes-Cluster, und nach aussen bekommt man sowohl eine grafische Oberflaeche als auch die Kommandozeilenwerkzeuge, die mit demselben Ding sprechen.

Der Wert liegt nicht darin, dass es Container laufen laesst, das koennen mehrere Werkzeuge. Er liegt darin, dass die Umgebung etwas wird, das man einstellt und zuruecksetzt, statt etwas, das man zusammensetzt und dann pflegen muss. Wer je einen Nachmittag damit verbracht hat, einen lokalen Cluster zu reparieren, den ein verirrter Befehl in einen seltsamen Zustand gebracht hat, kennt den Unterschied.

Mehr Auswahl, als die Alternativen meist bieten

Zwei Dinge, die sonst festgelegt werden, bleiben hier dem Nutzer ueberlassen. Die Container-Engine ist entweder containerd mit nerdctl oder dockerd mit der vertrauten docker-Kommandozeile. Die Kubernetes-Fassung laesst sich aus einer Liste waehlen und wechseln, wann immer es noetig ist. Wer eine Produktivfassung nachstellt, die auf eine bestimmte Nebenversion festgelegt ist, fuer den entscheidet der zweite Punkt darueber, ob das Werkzeug ueberhaupt brauchbar ist.

Die Oberflaeche verwaltet Abbilder, Container und Datentraeger, richtet Portweiterleitung ein und zeigt, was der Cluster tut. Lokal gebaute Abbilder sind fuer den Cluster sichtbar, ohne vorher in eine Registry geschoben zu werden, was einen ganzen Durchlauf aus Markieren und Hochladen aus dem inneren Entwicklungszyklus entfernt. Kleine Sache, grosse Wirkung darauf, wie oft man etwas tatsaechlich ausprobiert.

Die Werkzeuge, und wie das Ganze gebaut ist

Aktuelle Fassungen der ueblichen Kommandozeilenwerkzeuge liegen bei: docker, nerdctl, kubectl, helm. Das klingt nach Bequemlichkeit und handelt in Wahrheit von Wiederholbarkeit, denn eine Maschine, deren Werkzeugfassungen zu den Erwartungen des Clusters passen, erzeugt keine Fehlschlaege mehr, die mit dem Code nichts zu tun haben.

Darunter ruht alles auf einer virtuellen Maschine: unter macOS und Linux ist das Lima, unter Windows die zweite Fassung des Linux-Subsystems. Diese Wahl erklaert Nutzen und Kosten zugleich. Eine virtuelle Maschine gibt eine saubere Grenze und eine Umgebung, die sich wegwerfen und neu bauen laesst, zum Preis von Plattenplatz und Speicher, die dem Wirt dann fehlen. Die Einstellungen bieten automatischen Start, Zuteilung der Ressourcen und ein Zuruecksetzen, das alles in den Ausgangszustand bringt.

Das Projekt ist unter der Apache-Lizenz offen und darf von Organisationen jeder Groesse kostenlos genutzt werden, was in einem Unternehmen mehr zaehlt als auf einem privaten Notebook.

Welche Linie man faehrt, und was man meidet

Die 1.x-Reihe ist die aktuelle stabile Linie und bewegt sich recht schnell, was fuer ein Werkzeug so nah an einem schnellen Oekosystem normal ist. Eine Vorschau der naechsten Hauptversion ist ebenfalls unterwegs, und ihre Bauweise aendert sich auf interessante Weise: die Kernarbeit wandert in einen Hintergrunddienst, der virtuelle Maschine, Container-Engine und Cluster besitzt, und dieser Dienst laesst sich ueber die standardisierten Kubernetes-Schnittstellen ansprechen. Auch das Gastsystem wechselt, auf eine andere offene Enterprise-Distribution.

Das Projekt kennzeichnet diese Vorschau als fruehe technische Vorschau, ungeeignet fuer den Produktivbetrieb, und ergaenzt einen Punkt, den man zweimal lesen sollte: Vorschaufassungen lassen sich nicht von einer zur naechsten aktualisieren, nur zuruecksetzen und neu installieren. Fuer die taegliche Arbeit bleibt man auf der stabilen Linie und beobachtet die Vorschau aus der Entfernung.

Die Anwendung macht aus der Frage, ob man eine Container-Umgebung wie in der Produktion hat, etwas Optionales und Beherrschbares. Der Tausch ist schlicht: ein wenig Platte und ein wenig Speicher gegen einen lokalen Cluster, der sich jederzeit zuruecksetzen laesst und dessen Fassung man selbst waehlt.