Seit selbst einzelne 1HE-Server so leistungsstark sind, dass ihre Hardware sich durch den Betrieb einzelner Programme kaum mehr sinnvoll ausreizen lässt, hat sich die IT-Industrie fundamental verändert. Seit beinahe 20 Jahren ist Virtualisierung der Goldstandard, ganz gleich, ob in Form von VMs oder Containern. Für Unternehmen haben sich die Spielregeln nicht zuletzt durch die Prinzipien des Cloud Computings und die "Cloud Native"-Architektur fundamental geändert: Immer häufiger erwarten Kunden von IT-Dienstleistern heute, vor allem Plattformbetreiber zu sein. Kunden konsumieren CPU und RAM heute viel dynamischer, als es noch vor fünf Jahren der Fall war, und machen dabei von der Möglichkeit Gebrauch, hochspezialisierte Dienstleister etwa beim Erstellen von Umgebungen zu beauftragen, die dann auf beliebigen Plattformen laufen können.

Das wiederum sorgt dafür, dass sich die alltäglichen Herausforderungen von Plattformanbietern fundamental von jenen unterscheiden, mit denen sie es in der Vergangenheit zu tun hatten. Aus heutiger Sicht sind große IT-Plattformen zuerst eine Materialschlacht mit dem ständigen Bedarf des Skalierens in die Breite. Wer sein Rechenzentrum regelmäßig schrankweise erweitert, kann das aber unmöglich mit denselben Werkzeugen tun, mit denen er die Mini-Setups zuvor beackert hat. Längst bestimmen deshalb Automation und Orchestrierung den IT-Alltag der Gegenwart.

Das ideale Szenario: Wird ein Server geliefert, sind nur noch der Einbau ins Rack und die korrekte Verkabelung händisch zu erledigende Aufgaben. Ist die Maschine erstmal an, installiert sie sich automatisch das benötigte Betriebssystem mitsamt der gewünschten Software und wird automatisch funktionaler Teil der bestehenden Installation. Nicht zuletzt die großen Anbieter sind längst auf den Zug aufgesprungen und propagieren ihre automatischen Installationslösungen. Ganz gleich ob Red Hat mit Kickstart und Anaconda, SUSE mit AutoYaST, Ubuntu mit Metal-as-a-Service oder Debian mit Preseeding – alle großen Hersteller bieten heute Möglichkeiten, Server automatisiert zu installieren und zu konfigurieren.

Wer sich allerdings nicht an den Anbieter einer Distribution binden möchte, stößt schnell auf große Probleme. Fernab der Herstellerlösungen sucht der Admin Werkzeuge für Bare-Metal-Deployments nämlich vergeblich. Klar, Foreman ist der Klassiker und Nischenlösungen wie Orcharhino bieten ebenfalls viel Funktionalität. Von echter Konkurrenz kann trotzdem keine Rede sein. Denn viele der überhaupt verfügbaren Anwendungen sind entweder sehr eng auf einzelne Einsatzbereiche ausgelegt oder über die Jahre so umfangreich geworden, dass ihre Einführung beinahe einem Ding der Unmöglichkeit gleicht.

Die Entwickler von Tinkerbell [1] wollen das ändern und bringen eine Sammlung von Werkzeugen an den Start, die modernes Bare-Metal-Deployment versprechen. Die Toolsuite, die ihren Namen der guten Fee aus der Peter-Pan-Reihe verdankt, ist nach eigener Darstellung nicht nur beim Namen märchenhaft. Stattdessen, so der Anspruch, wolle Tinkerbell in generischen und gerade auch in heterogenen Umgebungen Admins alle nötigen Werkzeuge an die Hand geben, um beliebige Server automatisiert so weit zu installieren, dass danach eine vorhandene Automationsumgebung den Rest erledigen kann.

Vor dem Hintergrund der Geschichte Tinkerbells klingt das durchaus plausibel. Denn ursprünglich entstammt die Software der Feder von Packet, einem Metal-as-a-Service-Anbieter in den USA, der zwischenzeitlich vom RZ-Anbieter Equinix übernommen worden ist. Packets Geschäftsmodell war denkbar einfach: Ähnlich wie AWS oder Azure stellte es Kunden autarke System zur Verfügung, die allerdings keine virtuellen Instanzen waren, sondern eben echtes Blech. Per Knopfdruck konnten IT-Verantwortliche also einen Server buchen, den Tinkerbell dann mit dem geforderten Betriebssystem betankte und dem Kunden anschließend vorkonfiguriert zur Verfügung stellte. Böse Zungen würden an dieser Stelle behaupten, hiesige Hoster wie Hetzner praktizierten seit Jahren auch kaum etwas anderes. Der Vergleich hinkt jedoch gewaltig.

Richtig ist zunächst, dass sich die Art und Weise, wie Server automatisiert zu installieren sind, bis heute kaum geändert hat. Die genutzten Protokolle etwa entsprechen dem, was auch vor 25 und mehr Jahren bereits zum Einsatz kam: PXE, DHCP und TFTP servieren einem vom Netz startenden System das Image mit der Installationsroutine des Betriebssystems. Die läuft durch, lädt auf dem Weg weitere Software nach und bügelt sie schließlich auf die Speichergeräte des Rechners.

Anders als Tools von früher setzt Tinkerbell das gesamte Konzept jedoch in Form von Mikroarchitekturkomponenten um, die ineinander greifen und über eine zentrale API verbunden und steuerbar sind. Das liegt auch daran, dass bestehende Komponenten Packet seinerzeit nicht modern genug waren und die Entwickler vor allem Probleme im Hinblick auf deren Architektur befürchteten. Wer ein Framework zur automatischen Installation von Systemen schonmal auf Basis eines althergebrachten DHCP-Servers, TFTPd & Co. ausgerollt hat, kennt die Problematik.

Zumal die genannten Protokolle auch noch kein vollständiges Framework ermöglichen. Fast so wichtig wie die Art und Weise, wie ein Server an seine Software gelangt, ist die Frage, wie er ad hoc ein Konfiguration erhält, die erlaubt, eben jene Software überhaupt zu empfangen. Praktisch jeder moderne Server im Rechenzentrum kann heutzutage zwar vom Netzwerk starten. Oft haben Systeme aber mehrere Anschlüsse an verschiedene lokale Netze, und alle involvierten Netzwerkkarten unterstützen PXE. Dann gilt es, die richtige Netzwerkkarte auszuwählen, auf der der zuständige DHCP-Server und infolge alle anderen für das Deployment benötigten Dienste auch tatsächlich antworten.

Das Problem stellt sich darüber hinaus nicht nur im Kontext der Erstinstallation eines Systems. Frei nach der Automationsmaxime "Wenn sich jemand einloggen musste, muss eine Neuinstallation folgen" kommt es heute fast häufiger vor, Systeme aus dem laufenden Betrieb heraus neu zu installieren, etwa weil es ein Problem mit ihnen gab.

Vielerorts gilt die Regel, dass nach dem Login auf einem System zuerst ein Ticket für das interne Engineering zu eröffnen ist, weil wahlweise die Automation oder das zentrale Logging nicht gut genug waren, um das System danach in eine Neuinstallation zu schicken. Nur so, das ist die Idee hinter dem Ansatz, lassen sich Probleme durch lokale, händisch herbeigeführte Differenzen in der Systemkonfiguration umgehen.

Damit sich ein System aus dem laufenden Betrieb heraus allerdings neu installieren lässt, muss das Deployment-Framework administrativen Zugriff auf die Hardware haben. Das geht nur über die gängigen Remote-Management-Protokolle, üblicherweise also IPMI. Nur dieses findet sich auf den BMC-Boards praktisch aller aktuellen Server und ermöglicht es, einen Neustart des Systems mit festgelegtem Stargerät zu erzwingen – im Fall der Neuinstallation also mit Start vom Netz. Für die Steuerung eines Servers im Zusammenhang mit den anderen genannten Diensten ist allerdings eine eigene Software notwendig, und eben diese fehlt im Kontext klassischer Deployment-Umgebungen häufig. Packet wollte Flick- und Stückwerk vermeiden und entschied sich entsprechend, Tinkerbell als Umgebung inklusive der passenden Funktion zu konzipieren.

Der Faktor, dass Tinkerbell sich vollständig über API-Aufrufe steuern lässt, ist aus Sicht der Entwickler eine Hauptfunktionalität. Das Konzept passt in die Zeit: APIs haben sich als eine Art Königsweg der Steuerung großer Plattformen erwiesen, besonders jene auf Basis von ReST und HTTP. Mithin präsentiert Tinkerbell sich als moderne Software auf der Höhe der Zeit, die ein eigentlich sehr altes Problem mit einer aktuellen Werkzeugkiste angeht.

Ein Blick auf die Tinkerbell-Architektur zeigt als zentrale Dreh- und Angelpunkte Tink Server, Tink Controller, Tink Worker, das Installationsbetriebssystem Hook sowie Boots. Wie beschrieben folgt die Software den Anforderungen einer Mikroarchitekturanwendung, jeder einzelnen der beschriebenen Komponenten kommt also die Verantwortung für einen spezifischen Arbeitsschritt im Deployment-Prozess zu.

So etwas wie die zentrale Klammer um alle anderen Dienste herum ist dabei der Tink Controller. Dieser enthält das Wissen um alle durchgeführten und durchzuführenden Aktionen im Hinblick auf die Umgebung, zu der er gehört. Er leiert also die durchzuführenden Aufgaben an, etwa die Installation eines Servers oder das Löschen (Dekommissionierung) eines bestehenden Systems. Er pflegt auch die Metadaten von Tinkerbell, etwa spezifische Konfigurationseinstellungen für einzelne Systeme. Zur Tat schreitet der Tink Controller selbst aber nicht, denn das widerspräche dem Prinzip der Mikroarchitektur.

Stattdessen kommt zwischen den Tinkerbell-Komponenten eine Kommunikationsinfrastruktur auf Grundlage des gRPC-Protokolls zum Einsatz, über das der Tink Controller Arbeitsaufträge an den Tink Server schickt. In diesem steckt vor allem eine Art Scheduler – der Tink Server nimmt eingehende Aufträge ("Maschine 123 soll mit Debian GNU/Linux 12 installiert werden") also entgegen, ordnet und validiert sie und erstellt aus ihnen konkrete Arbeitsanweisungen. Die fertigen und nach Priorität geordneten Arbeitsaufträge arbeitet der Tink Server dann aber eben wieder nicht selber ab.

Zur Seite steht ihm stattdessen eine Komponente namens Tink Worker, die den eigentlichen Installationsprozess anstößt. Wie alle Komponenten von Tinkerbell ist auch der Worker nahtlos in die Breite skalierbar. In einem Setup können also beliebig viele Tink Worker zur selben Zeit laufen. Sie kommunizieren regelmäßig mit dem Tink Server und fragen bei diesem ab, ob Aufgaben zur Erledigung anstehen. Der Server verteilt die anliegenden Arbeitsaufträge dann an die verschiedenen Tink-Worker-Instanzen, die zur Tat schreiten.

Wieder dem Prinzip der Mikrokomponentenarchitektur entspricht, dass der Tink Worker selber keinerlei Funktionalität für die eigentliche Installation des Betriebssystems enthält. Die Vorbereitung einer passenden PXE/DHCP/TFTP-Umgebung übernimmt stattdessen die vierte Komponente im Bunde, nämlich Boots.

Boots ist vor allem ein DHCP-Server, der IP-Adressen an Server herausgibt und diese per iPXE so konfiguriert, dass sie in ein Installationsabbild starten. Praktisch: Boots ist ab Werk so konzipiert, dass es in bestehenden Netzwerken nur auf Anfragen von jenen MAC-Adressen reagiert, deren Verwaltung Tinkerbell offiziell anvertraut ist. Fragt stattdessen ein Server an, der in dem Tool nicht angelegt ist, antwortet Boots gar nicht erst auf dessen DNS-Anfrage. Das bietet die Möglichkeit, Tinkerbell in bestehenden Netzen nachträglich und parallel zu einem bestehenden DHCP-Server einzuführen; dieser ist dann allerdings so zu konfigurieren, dass er die MAC-Anfragen von Servern und Tinkerbell-Ägide ebenso ignoriert.

Bleibt noch die Frage, was Boots einem startenden System serviert, um die OS-Installation anzustoßen. Hier stehen grundsätzlich zwei Möglichkeiten offen: Boots liefert einerseits ein Installationsabbild direkt von Red Hat, SUSE, Ubuntu, Debian oder einer anderen Distribution aus. Auf der Platte fände dann jedoch freilich auch nur die jeweilige OS-Installation, die Konfiguration benötigt, im Anschluss eine Automation. Stattdessen hat sich Packet seinerzeit für einen anderen Weg entschieden und beschlossen, fertige Abbilder auf die laufenden Server zu kopieren. Dafür notwendig ist lediglich ein kleines Betriebssystem auf dem Zielsystem während der Installation, das ein passendes Abbild herunterladen und auf den lokalen Datenträger kopieren kann.

Genau hier kommt Hooks ins Spiel: Denn es ist eben jenes Betriebssystem in Form einer kleinen, eigenständigen Linux-Distribution, das zusätzlich als Grundlage für den Betrieb der anderen Tinkerbell-Komponenten gedacht ist. Es läuft "in-memory", liegt nach dem Start des Systems also vollständig im RAM der laufenden Maschinen und ist entsprechend flott. Obendrein kann der Administrator Hooks und dessen integrale Komponente "linuxkit" auch verwenden, um eigene Abbilder von RHEL, SLES, Ubuntu, Debian & Co. zu erstellen, die sich im Anschluss unmittelbar auf den Servern in der eigenen Umgebung nutzen lassen.

Da im Rahmen einer laufenden Hook-Instanz sämtliche regulären Kommandozeilenwerkzeuge zur Verfügung stehen, ist es viel flexibler als die Installation direkt vom PXE-Bootprompt aus. Auf Systemen eventuell benötigte Spezialfunktionen lassen sich in Hook also relativ leicht implementieren, während ansonsten die Installationsroutinen anderer Distributionen für vergleichbare Funktionalität ordentlich zu verbiegen wären.

Den aufmerksamen Lesern wird aufgefallen sein, dass wir das zuvor beschriebene Tool zum Steuern von Systemen per BMC-Schnittstelle bislang nicht erwähnt haben. Die in Tinkerbell zuständige Komponente PBnJ ("Power, Boot etc."), gehört nicht zu dessen Kernfunktionen und ist laut der Entwickler optional. Deployments lassen sich mit Tinkerbell also ohne PBnJ durchführen. Sonderlich viel Sinn ergibt das aber nicht, denn will ein Administrator einen Server neu installieren, müsste er diesen zuvor händisch so neu starten, dass er vom Netzwerk bootet und sich mithin in die Obhut von Boots begibt. Entsprechend kommt PBnJ in praktisch jedem Tinkerbell-Setup mit zum Einsatz und steuert auf Zuruf des Tink Workers nach Weisung vom Controller durch den Server hindurch die jeweilige Maschine.

Ebenfalls noch offen ist die Frage, wie sich fertige Konfigurationsdaten möglichst sinnvoll an von Tinkerbell ausgerollte Server weitergeben lassen. Das könnte freilich mittels des Automatisierungstools der Wahl geschehen, nachdem die gesamte OS-Installation abgeschlossen und das jeweilige Abbild dort komplett auf die Platte geschrieben ist. Je nach Situation kann es aber notwendig sein, ein System schon im Vorfeld zu konfigurieren. Das gilt beispielsweise, wenn für das eigene Automationswerkzeug auf dem fertig installierten System erst die Konfiguration anzulegen ist, weil es andernfalls gar nicht zugreifen könnte.

Das Problem ist nicht neu und virtuelle Instanzen in der Cloud stehen vor ähnlichen Herausforderungen. Hier hat sich Amazons Ansatz etabliert, während des Starts der Instanz den Dienst "cloud-init" aufzurufen. Der holt sich über eine spezielle IP-Adresse dann mittels HTTP/ HTTPS seine Metadaten ab, die auch unmittelbar Code enthalten können, etwa auszuführende Shell-Skripte (Bild 3). Das gesamte Prinzip hat Packet bei Tinkerbell nachgebaut; die zuständige Komponente heißt Hegel. Hegel ist ein Rewrite des eigenen Vorgängers Kant und heißt so, weil Hegel (wie Kant) viel wusste. Aus einer mit Tinkerbell ausgerollten Umgebung heraus lässt sich per Aufruf von curl IP-Adresse:50061/metadata der Metadatensatz für die gerade laufende Instanz jederzeit auslesen. Auf dem System selbst können Dienste wie "cloud-init" oder andere Skripte diese Metadaten dann verwerten.

Möchten Sie direkt "cloud-init" verwenden, können Sie die Metadaten über eine spezielle URL alternativ auch in exakt jenem Format abrufen, das kompatibel zum Metadatenformat von AWS ist, statt in Tinkerbell-Syntax. Das bietet Ihnen die Möglichkeit, Instanzen ad hoc einzurichten statt Konfigurationsdaten in OS-Abbilder zu packen. Deren Aktualisierung ist im Bedarfsfall ungleich aufwendiger als das Ändern der Metadaten einer Instanz in Tinkerbell.

Wie erwähnt, ist Packet als eigenständiges Unternehmen längst Vergangenheit, heute operieren seine Reste als Bestandteil von Equinix unter dem Namen Equinix Metal. So ganz scheint Equinix den Wert eines mächtigen Open-Source-Werkzeuges wie Tinkerbell allerdings nicht verstanden zu haben. Denn kürzlich hat es die Software als Projekt in die Obhut der Cloud Native Computing Foundation (CNCF) übergeben, nachdem sich in der Weiterentwicklung seit der Equinix-Übernahme von Packet bloß noch relativ wenig getan hatte.

Mittlerweile hat das Projekt einen neuen Haupt-Maintainer, interessanterweise einen Entwickler, der bei seine Brötchen bei AWS verdient – Chris Doherty. Das liegt wohl nicht zuletzt daran, dass Tinkerbell mittlerweile integraler Bestandteil von "AWS EKS Anywhere" ist, dem AWS-Angebot für Kubernetes auf Bare-Metal-Servern. Doherty ist auch kein Unbekannter, seit 2022 beteiligt er sich aktiv an Tinkerbell. Und er hat gleich zu Beginn seiner Laufbahn als "Tinkerbell Maintainer" klargestellt, dass es mit den ruhigen Zeiten vorerst vorbei ist. Sein Fokus liegt dabei weniger auf den Bestandskomponenten, vielmehr sieht er seine Aufgabe darin, Tinkerbell fit für die Zusammenarbeit mit Kubernetes zu machen.

Bisher war die Kubernetes-Integration von Tinkerbell eher bescheiden. Zwar ließen sich Komponenten wie der Kubernetes-Agent Kubelet auf fertig installierten Knoten problemlos ausrollen. Eine echte Integration zwischen Kubernetes und Tinkerbell bestand allerdings nicht. Entsprechend war es nicht möglich, Tinkerbell aus Kubernetes heraus zu steuern. Genau das ist im Kontext der beiden Umgebungen aber so etwas wie der heilige Gral. Gelänge es, beide so zu verbinden, dass Tinkerbell für eine laufende Kubernetes-Instanz auf Zuruf neues Blech bereitstellt, ergäbe sich ein sich quasi ganz allein verwaltender, automatisch skalierender Kubernetes-Cluster. Genau das ist die Aufgabe von Rufio [2]: Es exponiert eine Kubernetes-ähnliche API und erlaubt so die Steuerung durch Kubernetes, leistet im Hintergrund aber ähnliche Funktionalität wie PBnJ. Die Möglichkeiten, Tinkerbell in modernen Umgebungen auf Kubernetes-Basis einzusetzen, vergrößern sich damit erheblich. Die Entwickler stellen allerdings auch klar, dass die bestehenden Tinkerbell-Komponenten weiterhin gepflegt und, falls nötig, mit neuen Features versorgt werden.

Dass es so lange gedauert hat, bis Tinkerbell und Kubernetes miteinander sprechen konnten, ist durchaus bemerkenswert. Als hauptsächliches Deployment-Werkzeug für Tinkerbell haben seine Entwickler schließlich schon vor einiger Zeit eben jenes Kubernetes ausgemacht. Wer Tinkerbell also produktiv ausrollen möchte, hat dazu idealerweise zunächst einen laufenden Kubernetes-Cluster. In diesem lassen sich die nötigen Komponenten dann in Form von Helm-Charts auf der Kommandozeile schnell ausrollen. Die Konfiguration erfolgt über die Kubernetes-API.

Aber auch konventionelle Installationen sind möglich, die Basis bildet dann Vagrant in Kombination mit VirtualBox oder Libvirt. Die Entwickler begleiten alle Infrastrukturen mit einer ausgezeichneten Dokumentation: Den schnellen Einstieg bilden die Quick-Start-Guides [3] und alles weitere liefern die offiziellen Docs-Seiten [4].

Tinkerbell ist durchaus besonders: Kein anderes Managementwerkzeug für Bare Metal setzt so konsequent auf offene Standards und moderne Technologien wie das einstige Packet-Produkt. Dass der offiziell empfohlene Weg zur Installation Kubernetes voraussetzt, mag manchem Administrator sauer aufstoßen. Letztlich ist diese Entscheidung aber nur konsequent: Außerhalb skalierbarer Umgebungen ist es kaum möglich, die vielen Vorzüge der Software umfassend zu nutzen. Wer also zum Plattformanbieter werden möchte, sollte sich Tinkerbell unbedingt genauer ansehen. Ein Selbstläufer ist das zwar nicht, doch letztlich profitieren Unternehmen, die Tinkerbell einsetzen, aber massiv von der Economy of Scale: Einmal aufgesetzt ermöglicht sie Bare-Metal-Verwaltung wie sonst kaum ein anderes Tool.