© maya23k / 123RF.com

Im Cloud-Kontext geht es bei Tinkerbell nicht etwa um die Fee aus Peter Pans Wahlheimat Nimmerland, sondern um eine Lifecycle-Management-Lösung für physische Rechner.

Fragt man Admins, wodurch sich ihr heutiger Arbeitsalltag von jenem vor 20 Jahren unterscheidet, schildern sie meist ein Potpourri an Veränderungen. Ein Aspekt, der immer wieder zur Sprache kommt, bezieht sich auf die Verwaltung von Hardware. Mit Schrecken denkt der eine oder andere wohl noch an die Zeit zurück, als man Hardware im Rechenzentrum zu Fuß einrichtete – mit Anfahrt ins RZ, Installation per CD-ROM oder USB-Stick und anschließender Heimfahrt.

Immerhin: Dass es so nicht ewig weitergehen würde, war vielen Admins und Entwicklern seinerzeit durchaus schon klar. Der Debian-Installer etwa, dessen Entstehung grob in jene Zeit fällt, bot von Anfang an Preseeding an. Darunter verstehen die Debianer eine Möglichkeit, dem Installer per Textdatei eine Menge an Voreinstellungen mit auf den Weg zu geben.

Konfigurationseinstellungen aus der Preseeding-Datei fragt der Installer nicht mehr ab. Beantwortet man pauschal alle Installer-Fragen per Preseeding, lässt Debian sich komplett automatisch auf die Platte bringen. Die freie Distribution ist keineswegs die einzige, die Automation perfekt beherrscht: Red Hat hat Kickstart und Anaconda, Suse AutoYaST2. Obendrein gibt es externe Projekte wie FAI (Fully Automated Installer), die verschiedene Distributionen bespielen können.

Alle diese Ansätze beruhen jedoch auf diversen Annahmen über die vorhandene Infrastruktur. Eine davon ist, dass der Admin einen Weg findet, die Setup-Routine des jeweiligen Systems zu starten.

Die Herausforderung

In den kleinen, konventionellen Umgebungen früherer Jahre ging diese Annahme in Ordnung. Die Neuinstallation von Hardware im Rechenzentrum war keine wiederkehrende Aufgabe. War der Admin einmal vor Ort, konnte er über ein entsprechend vorbereitetes Image die Systeme nacheinander schnell automatisiert installieren.

Heute funktioniert dieser Ansatz allerdings nicht mehr. Die massiv skalierbaren Umgebungen der Gegenwart, die zum Beispiel dem Betrieb von Kubernetes-Flotten dienen, muss man des Öfteren und mit Dutzenden oder Hunderten Systemen erweitern. In den letzten Jahren hat sich deshalb das Prinzip des Bare Metal Lifecycles und des dazu passenden Managements herausgebildet. Die Idee: Sobald eine Maschine ausgepackt ist und verkabelt im Rack hängt, lässt sie sich per Mausklick automatisiert installieren, und zwar aus der Ferne. Im Rahmen dessen wird sie gleich auch mit der passenden Software betankt, und kurz danach steht sie bereits für produktive Aufgaben zur Verfügung.

Entsprechend ist das Thema Bare Metal Lifecycle Management heute ein riesiges Thema für die einschlägigen Anbieter. Red Hat, Canonical und Suse haben allesamt leistungsfähige Werkzeuge für diese Aufgabe an Bord. Auch Drittanbieter versuchen, ein Stück des Kuchens zu ergattern, wie etwa Foreman, das sich großer Beliebtheit erfreut.

Ein Anbieter, den man eher nicht erwarten würde, mischt mittlerweile ebenfalls mit: Equinix geht mit seinem Werkzeug Tinkerbell an den Start. Equinix, primär ein Anbieter von RZ- und Netzwerkinfrastruktur, will mit Tinkerbell eine Art Spagat schaffen: Das Werkzeug soll Kunden die Möglichkeit geben, in Equinix-Rechenzentren Bare-Metal-Knoten ebenso leicht zu provisionieren wie virtuelle Instanzen in Cloud-Umgebungen.

Tinkerbell ist Open Source

Mit dem Dienst Equinix Metal geht der Anbieter dabei schon seit mehreren Jahren auf Kundenfang. Die simple Idee: Früher griffen Kunden auf das Unternehmen nahezu ausschließlich als Hoster zurück. Wer also auf der Suche nach einer Colocation für das eigene Setup war, lag mit Equinix richtig. Der Kunde hat in dieser Konstellation allerdings einen ganzen Haufen verschiedener Aufgaben vor der Brust. Die Beschaffung der Hardware, deren Montage im Rack und die ordentliche Verkabelung sind nur ein paar davon.

Equinix Metal bietet dem Admin stattdessen Server in Form von echtem Blech per Knopfdruck: Server, die Equinix vorhält, werden automatisch so konfiguriert, dass sie einem Kunden exklusiv zur Verfügung stehen. Tinkerbell ermöglicht es, die Systeme mit exakt jener Grundausstattung zu versehen, die der Admin für seine Umgebung benötigt. Mittlerweile hat Equinix Tinkerbell unter eine freie Lizenz gestellt und auf Github veröffentlicht. Der Dienst lässt sich mithin auch außerhalb von Equinix Metal nutzen. Was die Lösung von anderen Systemen zur Bare-Metal-Verwaltung unterscheidet, zeigt dieser Artikel genauer.

Das gibt’s doch schon?

Bare Metal Lifecycle Management klingt sehr nach Marketing, lässt sich aber – auf das Wesentliche reduziert – schnell nachvollziehen. Im Kern geht es um die Möglichkeit, beliebige Infrastruktur (etwa Server) zu jedem beliebigem Zeitpunkt automatisiert (neu) installieren zu können. Obendrein spielt auch das automatische Entfernen einer Maschine aus einem Setup, die sogenannte Dekommissionierung, eine Rolle – allerdings eine merklich untergeordnete. Dass man ein System im laufenden Betrieb aufgrund einer Fehlkonfiguration neu installieren muss, passiert häufiger als die finale Abschaltung einer Komponente.

Tatsächlich handelt es sich bei Bare Metal Lifecycle Management um einen knackigen Begriff für ein Prinzip, das es seit Jahrzehnten gibt. Die Protokolle, die bis heute – übrigens auch bei Tinkerbell – zum Einsatz kommen, haben allesamt mehr als 30 Jahre auf dem Buckel. Ihre Kombination zum Erzielen einer vollautomatischen Installationsumgebung ist auch nicht neu. Als Admin begegnet man hier immer denselben alten Bekannten: DHCP, PXE, TFTP, HTTP oder FTP für den Dateitransfer, NTP zur Konfiguration der Systemzeit – fertig ist der Lack. Da stellt sich freilich die Frage, was Tinkerbell anders macht als etwa Foreman oder eine vom Admin händisch zusammengezimmerte Umgebung. Auch das ist ja durchaus eine Option und war im Linux-Magazin bereits Thema [1].

Ein bisschen Geschichte

Eine ausführliche Antwort auf diese Frage findet sich in einem Blog-Eintrag von Nathan Goulding [2]. Goulding gehört zum innersten Kern der Tinkerbell-Entwickler und hat vor ein paar Jahren auch Packet mitbegründet, jene Firma, die Tinkerbell ins Leben gerufen hat und heute als Teil von Equinix Equinix Metal heißt. Packet war ursprünglich unabhängig und bot eine Art globalen Dienst an, mit dem sich an beliebigen Standorten Systeme ausrollen ließen. Nach der Akquisition durch Equinix liegt der Fokus mittlerweile zwar auf deren Rechenzentren, nutzen lässt sich Tinkerbell jedoch noch immer völlig ohne Equinix-Anbindung.

Die ursprüngliche Motivation der Entwickler war es laut Goulding, ein generisches Werkzeug für Bare-Metal-Deployments zu schaffen, das so vielseitig wie möglich sein sollte. Dabei sollte es jedoch keineswegs zu einem multifunktionalen Moloch mutieren, wie es etwa bei Foreman der Fall ist. Letzteres kümmert sich längst nicht mehr nur um Bare-Metal-Deployments, sondern bindet stattdessen auch Automatisierer ein und erledigt diverse Zusatzaufgaben.

Dazu stellt Nathan Goulding trocken fest: Bare-Metal-Deployment ist in sich mehr als komplex genug, wenn man es richtig angehen will. Eine Motivation hinter Tinkerbell war seinen Aussagen nach eben auch der Umstand, dass bestehende Lösungen zu viele Kompromisse eingegangen waren und die anstehenden Aufgabe deshalb nicht perfekt erledigen konnten.

In Details verheddert

Die Basics seien dabei gar nicht das große Problem, meint Goulding. Einen Server aus der Schachtel zu nehmen, im Rack zu montieren und anschließend per PXE in einen Installer zu booten, sei nicht die Herausforderung. Dabei handele es sich in den meisten Fällen aber auch nur um einen kleinen Teil der zu erledigenden Arbeit.

Die Aussage, dass Commodity-Hardware sich stets gleich verhalte, sei schlicht nicht wahr. Jeder, der schon einmal mit unterschiedlichen Server-Modellen desselben Herstellers zu tun gehabt habe, könne das bestätigen. Bare Metal Lifecycle Management umfasse deshalb auch das Aktualisieren von Firmware, das Beachten unterschiedlicher Hardwarevoraussetzungen bei speziellen Servern sowie die Implementierung spezifischer Features auf bestimmten Systemen. Von spezieller Hardware, die beim Deployment beachtet werden will, ist da noch gar nicht die Rede.

Man stelle sich etwa ein Szenario vor, in dem ein Anbieter Spezial-Hardware wie NICs von Mellanox nutzt, für die der Treiber auch in die eigene Bare-Metal-Umgebung integriert ist (Abbildung 1). Gilt es, für eine Charge zusätzlicher Server ein Nachfolgemodell zu besorgen, weil es das ursprüngliche Modell nicht mehr gibt, hat der Admin ein Problem, das nicht selten einen Komplettumbau erfordert. Tinkerbell wollte genau solche Aufgaben von Anfang an leichter bewältigbar machen.

Abbildung 1: Besondere Hardware wie Connect-X6-Karten von Mellanox lässt sich in Tinkerbell über eigene Docker-Container in jeder Phase des Setups integrieren.

Besonders schmerzhaft vermisst die Tinkerbell-Community bei anderen Lösungen auch die Möglichkeit, in einzelne Teile des Deployment-Prozesses flexibel eingreifen zu können. Und tatsächlich: Red Hat, Debian und Suse lassen sich kaum noch steuern, wenn der Installer erst einmal läuft. Zudem entpuppt es sich als durchaus nicht trivial, den Installer im Sinne erweiterter Funktionalität zu verändern.

Eine Lösung, fünf Komponenten

Um diese Ziele zu erreichen, halten sich die Tinkerbell-Entwickler an praktisch alle Vorgaben der modernen Softwarearchitektur. Tinkerbell besteht unter der Haube aus fünf Komponenten, die dem Prinzip der Mikroarchitektur folgen; es hat also für jeden spezifischen Task einen eigenen Dienst an Bord (Abbildung 2).

Abbildung 2: Tinkerbell besteht aus diversen Einzelkomponenten wie Boots und Hegel, die jeweils nur eine Funktion bieten – die Architektur ist also typisch für eine Mikrokomponenten-Architektur.

Tinkerbell setzt dabei nicht auf bestehende Komponenten, sondern ist ein von Grund auf neu geschriebenes Konstrukt. Die Entwickler implementierten folglich die Dienste für grundlegende Protokolle wie DHCP oder TFTP ebenfalls neu. Erfahrene Administratoren reagieren darauf automatisch mit Skepsis – neue Räder sind schließlich selten bis nie runder als ihre Vorgänger. Sticht Tinkerbell hier heraus?

Eine Antwort auf diese Frage erfordert eine genauere Untersuchung der Architektur von Tinkerbell. Die Autoren der Lösung unterscheiden zwischen zwei Instanzen: dem Provisioner und dem Worker. Ersterer enthält die gesamte Logik zur Steuerung von Blech. Letzterer setzt diese Logik portionsweise in für die einzelnen Maschinen zugeschnittene Logik um, die er vor Ort ausführt.

Tink als zentrales Werkzeug

Wer sich schon einmal mit dem Ansatz von Mikroarchitekturapplikationen befasst hat, ist dabei mit hoher Wahrscheinlichkeit auch dem Begriff Workflow begegnet, der in schöner Regelmäßigkeit zusammen mit der Workflow Engine daherkommt. Viele Programme jüngeren Datums arbeiten mit solchen Workflows, die einzelne Arbeitsschritte definieren und die Reihenfolge festlegen, in der es die Arbeitsschritte zu absolvieren gilt.

Im Bare-Metal-Kontext könnte ein Workflow beispielsweise daraus bestehen, dass ein frischer Server zunächst per DHCP in eine PXE-Umgebung bootet, dort dann Kernel und RAM-Disk für eine Systeminventarisierung erhält und die Installation vornimmt. Bei der Transition von einer zur nächsten Phase, also von einem Element des Workflows zum nächsten, berichtet der Server jeweils, wo im Prozess er sich gerade befindet, und zwar direkt an die Workflow Engine. Die kann so bei Bedarf nachsteuern, Prozesse abbrechen oder erweitern.

Genau diesem Ansatz folgt auch Tink, eine der fünf Kernkomponenten in Tinkerbell. Als Workflow Engine von Tinkerbell dient es als Steuerzentrale der Lösung. Der Admin kommuniziert per CLI mit Tink und jubelt ihm auf diese Weise Templates unter. Ein Template enthält die Anweisungen, die es auf ein bestimmtes Stück Hardware – also einen Server – anzuwenden gilt – vulgo den Workflow, den der Server in Tinkerbell durchläuft. Obendrein enthält Tink die Datenbank, in der die Maschinen hinterlegt sind, mit denen Tinkerbell umgehen kann.

Zudem gehört zu Tink eine Container-Registry. Die wird später wichtig: Alle Arbeiten, die Tink auf den Zielsystemen ausführt, startet es in Form von Containern. Das erlaubt es dem Admin einerseits, eigene Arbeitsschritte zu definieren und diese in Form generischer Container zu hinterlegen. Andererseits macht es die Standard-Container-Abbilder der großen Distributoren nutzbar, auch wenn Tinker dafür einen kleinen Umweg vorsieht.

DHCP und iPXE per Boots

Um Tink herum gruppieren sich diverse Komponenten, die auf den Zielsystemen die eigentliche Arbeit erledigen. Dazu gehört unter anderem Boots, ein eigens für Tinkerbell verfasster DHCP- und iPXE-Server. Zur Erinnerung: Die PXE-Erweiterung iPXE bietet verschiedene Zusatzfeatures wie etwa das Chainloading, also das Ausführen mehrerer Boot-Kommandos nacheinander.

Die einzige Aufgabe von Boots besteht darin, eingehende DHCP-Requests von startenden Servern zu erkennen und die abfragende MAC-Adresse mit der gespeicherten Hardware in Tink abzugleichen. Erkennt es dabei eine Maschine, weist es ihr im nächsten Schritt eine IP-Adresse zu und schickt ihr danach ein iPXE-Abbild. Das sorgt dafür, dass der Server in die dritte Tinkerbell-Komponente bootet, das Operating System Installation Environment OSIE. Dabei handelt es sich um eine auf Arch Linux basierende Mini-Distribution, die verschiedene, im Template für den jeweiligen Server definierte Arbeitsschritte nacheinander abarbeitet. Dafür nutzt OSIE Docker, was es dem Admin erlaubt, unkomplizierte eigene Container beizusteuern, die OSIE in der vom Admin festgelegten Reihenfolge aufruft. Alternativ kann er aber auch auf Standard-Container der großen Hersteller setzen.

Zur Seite steht OSIE dabei ein Metadatendienst namens Hegel. Er hält die vom Admin per Template festgelegten Konfigurationsparameter für den jeweiligen Server bereit, sodass sie sich aus OSIE heraus unmittelbar abrufen lassen. Prinzipiell funktioniert das wie »cloud-init« in diversen Cloud-Umgebungen: Das Skript redet beim Systemstart per HTTP mit einer definierten API-Schnittstelle, über die es sämtliche für die Maschine definierten Parameter bezieht. Das kann etwa auch ein spezielles Skript sein, das die virtuelle Instanz oder im Tinkerbell-Beispiel den physischen Server beim Systemstart aufrufen soll.

Grundsätzlich setzt Hegel der Phantasie des Admins kaum Grenzen, auch wenn eine Mahnung angezeigt ist: Gerade im Kontext virtueller Instanzen lassen sich viele Administratoren dazu hinreißen, im Boot-Skript, das die VM über ihre Metadaten empfängt, ein halbes Ansible nachzuimplementieren. Gerade dafür sind die Skripte allerdings nicht geschaffen. Sie sollen tatsächlich nur die unmittelbar nötigen Aufgaben erledigen. Wenn später Zusatzarbeit anliegt, sollte der Admin diese von Komponenten erledigen lassen, die genau dafür gemacht sind.

Bare Metal nicht im Fokus

Die fünfte und jüngste Tinkerbell-Komponente ist der Power- und Boot-Service, der die Maschine per Out-of-Band-Management steuern kann. Diese Funktion war ursprünglich gar nicht Bestandteil des Tinkerbell-Designs. Schnell wurde aber klar, dass es eben auch zum Lifecycle-Management eines Systems gehört, es aus dem laufenden Betrieb heraus neu zu installieren. Das klappt nur dann komfortabel, wenn der Lifecycle-Manager die Hardware steuert.

Andernfalls müsste der Admin auf dem System per Ipmitool oder über das Managementwerkzeug für die jeweilige Out-of-Band-Schnittstelle zuerst die Boot-Reihenfolge auf PXE ändern und danach lokal einen Reboot initiieren. Das geht aber nur, wenn das betroffene System noch einen Login per SSH ermöglicht. Fällt der flach, muss der Admin selbst die jeweilige BMC-Schnittstelle nutzen. Der Power- und Boot-Service von Tinkerbell erlaubt das automatisiert und komfortabel über die ohnehin vorhandene Managementschnittstelle.

Einen Fokus legen die Entwickler dabei klar auf IPMI, was grundsätzlich nicht schadet: Alle BMC-Implementierungen der Hersteller bieten IPMI-Unterstützung, auch wenn man diese gegebenenfalls separat aktivieren muss. Die einzige Alternative zu IPMI wäre jedenfalls der Zugriff auf Dells Werkzeug Racadm. Tinkerbell implementiert diese Protokolle nicht selbst, sondern setzt im Hintergrund auf vorhandene Werkzeuge, was zweifelsohne viel Arbeit erspart.

Kommunikation per gRPC

Damit kennen Sie nun die relevanten Komponenten des Tinkerbell-Stacks. Wie es sich für eine Lösung im Jahr 2021 gehört, kommunizieren die einzelnen Dienste freilich nicht irgendwie miteinander, sondern nutzen das ursprünglich auf Googles Mist gewachsene gRPC-Protokoll. Das führt letztlich dazu, dass Tink als zentrale Komponente die anderen Dienste in gewisser Weise fernsteuert. gRPC ist sowohl auf Robustheit als auch auf Stabilität ausgelegt, die Entscheidung der Entwickler für das Protokoll lässt sich insofern nachvollziehen.

Tinkerbell ganz praktisch

Wer Tinkerbell als Administrator ausprobieren möchte, bekommt von den Autoren für diesen Zweck eigens Vagrant-Container zur Verfügung gestellt. Das Ziel des Beispiels ist es dabei ausdrücklich nicht, ein Betriebssystem auf einen Server zu bringen. Stattdessen soll die Vagrant-Umgebung zeigen, wie Tinkerbell grundsätzlich arbeitet und welche Möglichkeiten es bietet.

Die gelieferten Vagrant-Files bauen in kürzester Zeit eine Tinkerbell-Umgebung auf, ohne dabei irgendwelche Features zu deaktivieren. Dafür gibt es eine genaue Anleitung [3], im Kern ist der Ablauf aber nicht kompliziert: Zunächst rollen Sie per Vagrant den Provisioner aus. Der enthält alle zuvor beschriebenen Dienste: Tink, Boots, Hegel samt ihren Subservices und allem, was der Admin braucht.

Aus Vagrant heraus läuft Tinkerbell anschließend in Ubuntu-Containern, die Sie mittels einer Docker-Compose-Datei ausrollen. Die Tinker-CLI steht dadurch ebenfalls zur Verfügung. Damit es losgehen kann, fehlt zudem noch ein Image: Die Autoren gehen in ihrem Beispiel vom »hello-world«-Abbild aus, das die Docker-Entwickler selbst zur Verfügung stellen. Tinkerbell betreibt eine lokale Container-Registry: Sie laden das Abbild per Pull-Befehl also zunächst von Docker Hub und schieben es danach per Push-Kommando in die lokale Registry.

Danach spielen Sie die Konfiguration des physischen Servers in Tinkerbell ein. Das geschieht mit einer Datei im JSON-Format (Abbildung 3), die der Maschine neben einer ID auch ein paar Konfigurationsdetails und – ganz wichtig – ihre Netzwerkeinstellungen mit auf den Weg gibt. Hier legen Sie fest, welche IP-Adresse das System später von Boots erhält und ob es UEFI oder das konventionelle BIOS nutzt.

Abbildung 3: Hardware fügt der Admin in Tinkerbell per JSON-Datei ein, wobei der Dienst über das einzelne Blech gar nicht so viel wissen muss.

Das Template für den Server

Die Tinkerbell-Dienste laufen, und die Server-Konfiguration befindet sich dort, wo sie hingehört. Noch wüsste Tinkerbell aber nicht, was es mit dem Server tun soll, sobald dieser sich meldet. Es würde auf der Maschine zwar OSIE starten, dieses würde aber mangels Anweisung kein Betriebssystem installieren. Deshalb kommt im nächsten Schritt das erste Template zum Einsatz (Listing 1).

cat > hello-world.yml <<EOF
version: "0.1"
name: hello_world_workflow
global_timeout: 600
tasks:
  - name: "hello world"
    worker: "{{.device_1}}"
    actions:
      - name: "hello_world"
        image: hello-world
        timeout: 60
EOF

Ein Template verbindet in Tinkerbell eine bestimmte Maschine mit einer Reihe von Anweisungen (Abbildung 4). Es erinnert in Art und Form stark an Kubernetes-Pod-Beschreibungen, auch wenn es den Kubernetes-Standard letztlich nicht implementiert. Wichtig darin ist vor allem der Tasks-Abschnitt aus Listing 1: Er sorgt dafür, dass Tinkerbell auf dem System nach dem OSIE-Start das Abbild »hello-world« ausführt.

Abbildung 4: Das Bootstrapping in Tinkerbell funktioniert über Templates und Docker-Container. Im gezeigten Beispiel schreibt Tinkerbell ein Ubuntu-Image auf die Festplatte.

Wenn Sie im nächsten Schritt einen Tinkerbell-Worker starten und ihm die ID des Templates sowie die MAC-Adresse der Zielmaschine mit auf den Weg geben, läuft der Prozess los. Sobald der entsprechende Server in eine PXE-Umgebung bootet, stattet Tinker ihn mit dem OSIE-Abbild aus und ruft darin anschließend den Container auf, der “Hello World” ausgibt.

Die einzelnen Schritte des Vorgangs lassen sich in Tinkerbell unmittelbar per Workflow-Engine anzeigen (Abbildung 5). Hier sieht man auch, welche Teile des Workflows ausgeführt wurden und ob die Ausführung funktioniert hat. Das hilft beim Debugging.

Abbildung 5: Die einzelnen Arbeitsschritte innerhalb eines Templates lassen sich von außen nachvollziehen.

Ein Praxisbeispiel

Im Alltag macht das rudimentäre Vagrant-Beispiel den Administrator freilich nicht glücklich. Es zeigt aber, was grundsätzlich möglich ist. Die Dokumentation von Tinkerbell enthält zudem konkrete Beispiele für Templates, die am Ende Ubuntu oder RHEL auf Basis von deren offiziellen Container-Abbildern installieren.

Falls Sie jetzt denken: “Moment mal, die haben doch keine Kernel und installieren ab Werk auch kein Grub”, dann haben Sie völlig recht: Diese Arbeitsschritte müssen Sie einzeln im jeweiligen Template festlegen, und zwar so, wie Sie sie ausgeführt haben möchten. Wie bei anderen Lösungen gilt auch bei Tinkerbell, dass erhöhte Flexibilität mit erhöhtem Aufwand beim Festlegen dessen einhergeht, was man erreichen möchte.

Fazit

Tinkerbell mag auf manchen eingefleischten Admin sehr hip wirken – schließlich war es auch bisher möglich, Server ohne gRPC, Docker und anderen Krempel automatisch mit einem Betriebssystem zu versehen. Wer Tinkerbell deshalb verwirft, tut der Lösung aber unrecht. Ihre Stärken spielt sie nicht nur im Zusammenspiel mit Equinix Metal aus, sondern durchaus auch in Real-World-Setups. Ein Deployment-System, das so elementare Eingriffe in den Prozess während jeder Phase des Setups ermöglicht, sucht auf dem Markt jedenfalls seinesgleichen. Es schadet also nicht, Tinkerbell genauer zu betrachten und bei Bedarf auszuprobieren. (jcb/jlu)