© Kittipong Jirasukhanont, 123RF

Virtualisierung ist überall. Damit steigt der Bedarf an angepassten Betriebssystem-Abbildern. Anwender haben immer weniger Lust, Betriebssysteme per Hand zu installieren – FAI.me baut Images auf Kommando.

Die älteren Semester unter den Admins erinnern sich noch gut an die Zeit, in der das Installieren eines Betriebssystems eine regelmäßig wiederkehrende Aufgabe war. Zwar breitet sich die Virtualisierung im Rechenzentrum seit mehr als zehn Jahren ständig aus, doch während eines beachtlichen Teils dieser Zeit war es üblich, eine virtuelle Maschine etwa in VMware oder im »virt-manager« anzulegen und ihr danach zu Fuß ein Betriebssystem zu verpassen.

Aus heutiger Sicht ist das allerdings eine leicht automatisierbare Aufgabe. Die händische Installation von Betriebssystemen ist also in jeder Hinsicht ein Anachronismus, der sich allerdings erstaunlich lange hat halten können.

Automatisierung unabdingbar

Spätestens das Cloud Computing hat der manuellen Linux-Installation den Garaus gemacht. Clouds richten sich nicht nur an passionierte Sysadmins, die mit Linux kein Problem mehr haben. Wer etwa Apps für den Betrieb in Clouds entwickelt, dem ist das Betriebssystem unter der Haube im Grunde egal – solange dort die Komponenten laufen, die für die App nötig sind. Obendrein frisst jede händische Linux-Installation viel Zeit.

Wer eine Cloud-Orchestrierung etwa in Form von AWS Cloud Forms oder Open Stack Heat nutzt, startet mit einem Klick oder einem CLI-Befehl womöglich Dutzende virtuelle Maschinen (Abbildung 1). Es ist undenkbar, sich in jede dieser VMs per VNC-Konsole einzuloggen, um händisch das Betriebssystem aufzuspielen oder einzurichten.

Abbildung 1: Wer in der Cloud eine VM startet, wählt dabei immer auch ein fertiges Betriebssystem-Abbild als Grundlage aus, etwa bei AWS.

Glücklicherweise bieten die gängigen Clouds auch eine funktionale Alternative an, die auf Betriebssystem-Abbildern basiert. Die Idee dahinter ist klar: Innerhalb einer virtualisierten Umgebung – etwa in KVM – sind alle Parameter und Schnittstellen bekannt. Eine KVM-VM sieht in einem Setup von innen nicht anders aus als in einem anderen Setup, weil KVM seit Jahr und Tag dieselben Schnittstellen in die VM hineinexponiert.

Aus Sicht eines Imagebauers ist es also problemlos möglich, solche Abbilder vorzubereiten und jederzeit zur Verfügung zu stellen. Genau so funktioniert das Ausrollen einer VM in Amazon oder Open Stack und praktisch jeder anderen Cloud ebenfalls. Die Frage ist nur: Wo kommen die Images her?

Der Weg des Distributors

In den gängigen Clouds rollen die Anbieter meist die Standard-Abbilder der Distributoren aus. Suse, Red Hat und Canonical bieten solche explizit an, und grundsätzlich spricht auch nichts dagegen, sie zu verwenden. Doch gibt es möglicherweise die eine oder andere Eigenschaft dieser Abbilder, die den Admin nervt – fehlende Pakete, falsche Konfigurationen oder andere alltägliche Schwierigkeiten.

Es ist aber nicht trivial, ein fertiges Abbild mal eben zu verändern. Stattdessen fangen viele Admins an, das Image aus den Quellen neu zu bauen, und geben früher oder später entnervt auf. Denn meist gelingt es nicht, die Qualität der Abbilder der Distributoren zu erreichen. Entweder sind die Images Marke Eigenbau aufgebläht und viel zu groß oder sie funktionieren nicht gut.

Genau hier kommt FAI.me ins Spiel: Das Tool ist eine Erweiterung des Fully Automated Installers (FAI) und baut auf Zuruf Betriebssystem-Abbilder sowohl für echtes Blech als auch für die Verwendung in der Cloud. Im Folgenden stellt dieser Artikel FAI.me vor und erläutert, was im Hintergrund passiert. So viel sei vorab verraten: Wer auf der Suche nach einer Möglichkeit ist, schnell und unkompliziert Images zu bauen, ist bei FAI.me auf der richtigen Fährte.

Rückblick auf FAI

Um FAI.me zu verstehen, ist ein kurzer Rückblick nötig: Erst kürzlich hat das Linux-Magazin FAI vorgestellt, den Fully Automatic Installer. Der ist zwar nicht neu, bekommt durch seinen Upstream-Autor Thomas Lange aber immer wieder neue Funktionen spendiert. Obendrein hat sich rund um das Werkzeug eine kleine, aber feine Community gebildet, die es aktuell hält und dafür sorgt, dass es nicht nur Debian installieren kann. Auch Ubuntu und Centos sind mittlerweile auf der Liste der unterstützten Distributionen.

Der ursprüngliche Einsatzzweck von FAI ist klar umrissen: Neue Server sollen sich nach dem Auspacken möglichst automatisch und ohne viel händisches Zutun installieren. Was durchaus bemerkenswert ist: FAI entstand bereits Ende der 90er, also lange bevor Automatisierer wie Puppet oder Ansible existierten.

FAI bot früh die Möglichkeit, ein OS automatisch auszurollen. Dazu kombiniert es in der Standardkonfiguration eine Vielzahl verschiedener Protokolle: Einem DHCP-Server steht ein TFTP-Server zur Seite. Clients nutzen das PXE-Protokoll, um zunächst eine IP zu erhalten und anschließend einen Bootloader per TFTP zu laden. Der enthält Kernel, üblicherweise eben jenen der Installationsroutine – und genau die ist dann verantwortlich, sich um den Rest zu kümmern.

Das Programm braucht PXE, um in eine Custom-Bootumgebung zu starten, in der es seine verschiedenen Betriebssysteme ausrollen kann. Dafür haben Thomas Lange und freiwillige FAI-Entwickler viele Features implementiert: In unterschiedlichen Stages der Installation sind Skripte ausführbar, die dann bestimmte, in FAI nicht ab Werk vorgesehene Funktionen realisieren. Alle FAI-Komponenten lassen sich dazu von einem zentralen Netzwerkserver nachladen.

Der Clou: FAI hängt nicht von der Installationsroutine eines Installers ab. Möchte der Admin Automation für Suse, Centos und Debian implementieren, dann müsste er theoretisch drei Boot-Umgebungen schaffen: für Autoyast, für Kickstart und für Preseeding.

FAI bietet dem Admin eine größtenteils generische Schnittstelle. Lediglich bei lokalen Modifikationen wie etwa der Auswahl der automatisch zu installierenden Pakete lauern Fallen. Denn längst nicht alle Pakete für dieselben Komponenten haben über die Distributionen hinweg identische Namen.

Kein Netz, kein Spaß

Früh hat Thomas Lange allerdings auch erkannt, dass die Abhängigkeit vom Netzwerk durchaus nachteilig sein kann. Denkbar ist etwa, dass zwar ein DHCP-Server existiert, der dann aber erst mühsam mit FAI zu integrieren ist. Oder DHCP ist gar nicht erlaubt. Vielleicht können auch die Systeme, die installiert werden sollen, einfach kein PXE – längst nicht alle Netzwerkkarten kommen mit Unterstützung für dieses Protokoll. Ohne Netz funktioniert aber auch der Netzwerkboot in FAI nicht.

Seit vielen Jahren unterstützt FAI deshalb auch die Möglichkeit, sich aus einer vorbereiten FAI-Konfiguration ein statisches Image generieren zu lassen. Das brennt der Admin dann auf eine CD-ROM oder DVD oder er schreibt es auf einen USB-Stick. Das lokale Bootmedium verhält sich danach exakt so, wie es auch ein Netzwerk-basiertes FAI getan hätte, doch mit ein paar systembedingten Einschränkungen: Ändert der Admin die Konfiguration von FAI, muss er im Anschluss die Abbilder neu erstellen.

War diese Funktion in den ersten Jahren der FAI-Existenz auf das Generieren von Images für echtes Blech beschränkt, gibt es in FAI mittlerweile auch Funktionen, um Images für Cloudumgebungen zu bauen. Beispiel Debian: Das Kommando

fai-diskimage -u cloudhost -S900M

-cDEFAULT,DEBIAN,AMD64,FAIBASE,DEMO,

GRUB_PC,CLOUD /tmp/disk

legt in »/tmp/disk« ein Abbild eines installierten Debian-Systems an, das für die AMD64-Architektur gebaut ist, den Grub-Bootloader enthält und in Summe 900 MByte Speicherplatz mitbringt (Abbildung 2). Hat der Admin auf dem System, auf dem er das Kommando aufruft, ein flottes Internet, geht auch »fai-diskimage« flott zu Werke: Kaum eine Minute dauert es, bis das fertige Image vorliegt. Bei Debian ist man froh, das Werkzeug zu haben, denn unter anderem erstellt das Projekt damit seine offiziellen Images für die Cloud [1].

Abbildung 2: »fai-diskimage« erstellt auf Basis einer vorhandenen FAI-Konfiguration ein Cloudimage.

Images auf Knopfdruck

Diese Funktionalität ist es, die FAI.me dem Anwender ohne die ansonsten nötige Bastelei zur Verfügung stellt. Im Grunde handelt es sich um nicht viel mehr als eine grafische, Web-basierte Oberfläche für »fai-diskimage«, die auf Zuruf beliebige, bootbare Betriebssystem-Abbilder zusammenstellt. Sowohl Abbilder für Bare-Metal-Installationen als auch jene für Clouds sind darin enthalten. Tatsächlich bietet FAI.me aber eine ganze Vielzahl äußerst praktischer Funktionen, die dieser Artikel im Folgenden aufgreift und erklärt.

Naturgemäß unterscheiden sich die bootbaren FAI-Images für echtes Blech von den Cloudabbildern deutlich. Erstere enthalten den normalen FAI-Installer, der nach dem Starten vom Bootmedium ans Werk geht. Letztere hingegen kommen mit einem bereits fertig installierten Betriebssystem. Um diesem Umstand Rechnung zu tragen, hat Thomas Lange FAI.me über zwei Unterseiten auf der FAI-Website implementiert: [2] dient zum Anlegen von Cloudabbildern und [3] führt in die Bare-Metal-Abteilung.

Wenig Klick-Bedarf

Beide Seiten präsentieren sich einigermaßen übersichtlich. Guckt man sich die Cloud-Seite an, hat der Admin nur wenige Parameter, die er überhaupt setzen muss – die sind dann allerdings tatsächlich wichtig. Ganz oben trägt er beispielsweise sowohl die Zielgröße des Image ein als auch das Format, das es haben soll. Hintergrund: Baut der Admin ein Abbild für AWS, so ist dafür ein anderes Format nötig als etwa für KVM, das üblicherweise das Qcow2-Format für Festplatten erwartet.

Den Hostnamen kann der Admin zwar setzen, in der Regel wird er aber durch das SDN in Clouds und deren Namensauflösung wieder überschrieben. Praktisch: Wer seinen öffentlichen SSH-Schlüssel in ein Cloudabbild packt, muss ihn beim Starten der virtuellen Maschine nicht angeben.

Wer alternativ ein Passwort für Root setzen will, kann das tun – allerdings ist davon dringend abzuraten. Lässt der Admin das Feld frei, hat er einen Angriffsvektor weniger und muss dank Sudo trotzdem nicht auf die Rechte als Root verzichten. Stellt er dann noch die gewünschte Sprache ein sowie die Release, die er nutzen möchte – für FAI.me stehen aktuell Debian 9 oder Debian 10 zur Auswahl –, kann es beinahe losgehen.

FAI.me will dann nur noch wissen, welche Pakete es in das Abbild integrieren soll. Hier gilt allerdings ein Aufruf zur Sparsamkeit: In der Regel stehen Clouds ja hinter durchaus potenten Leitungen, sodass es angezeigt ist, das Basis-Image so klein wie möglich zu halten und den Rest gegebenenfalls aus dem Netz oder einem lokalen Mirror nachzuladen.

Die großen Distributoren machen das anschaulich vor: Die Ubuntu-Images etwa, die Canonical für die Nutzung in Open Stack zur Verfügung stellt, kommen seit Jahren mit rund 260 MByte aus.

Vergleichbarer Aufwand für Blech

Will man stattdessen ein Abbild für die Nutzung auf echtem Blech bauen, so ist der Aufwand auch nicht viel höher. Hier gibt es allerdings einen separaten Schalter, um sich die Advanced Settings anzeigen zu lassen – dahinter verbergen sich jedoch auch nur die Settings für das Passwort von Root und das Hinzufügen eines öffentlichen SSH-Schlüsselteils. Ab Werk geht FAI davon aus, dass es einen Benutzer mit Passwort anlegt, der anschließend per Sudo zu Root wird.

Per Drop-Down-Menü legt der Admin auf Wunsch das Partitionsschema fest. FAI.me liefert hier verschiedene Vorschläge, um etwa LVM zu nutzen oder »/home« auf eine eigene Partition auszulagern. Die restlichen Einstellungsoptionen stimmen weitestgehend mit denen der Cloudvariante überein.

Bei Klick: Image

Egal ob der Admin ein Image für Blech oder für die Cloud will: Am Ende des Vorgangs genügt ein Klick auf den Button unten links, um den Automatismus des Image-Baus in Gang zu setzen (Abbildungen 3 und 4). Nach kurzer Wartezeit startet der Browser danach mit dem Download des Image, das sich dann per USB-Stick, per CD/DVD oder in der Cloud verwenden lässt.

Abbildung 3: FAI.me erstellt wahlweise Images für die Cloud etwa im Qcow2- oder AWS-Format oder …

Abbildung 4: … Installationsabbilder, um einen physischen Host mit einem Betriebssystem auszustatten.

Dabei passiert –wie bereits erwähnt – im Hintergrund kein Hokuspokus. Das Webinterface ruft stattdessen im Hintergrund »fai-cd« und »fai-mirror« oder »fai-diskimage« auf und erstellt so on the Fly ein entsprechendes Abbild. Der Admin kann sich deshalb absolut sicher sein, dass er stets die Pakete etwa für das noch ganz frische Debian GNU/Linux 10 alias Buster bekommt.

Anders als bei den großen Distributoren hat er es auch selbst in der Hand, den Bau des Image anzustoßen – auch wenn er im Gegenzug eben kein offizielles Abbild nutzt, sondern ein per FAI.me selbst gebautes. Fest steht jedoch: Was von Thomas Lange ursprünglich eigentlich als Showcase für FAI gedacht war und den Nutzern den FAI-Funktionsumfang näherbringen sollte, ist für sich allein betrachtet ein sehr praktisches Werkzeug.

Eine eigene Image Factory mit FAI

Um es nochmals zu betonen: FAI.me bringt im Grunde fast keine eigene Funktionalität mit. Das Werkzeug greift im Hintergrund auf eine vorkonfigurierte FAI-Installation zurück und nutzt diese, um Abbilder auf Zuruf nach FAI-Standards zu bauen. Das allerdings ist die Lösung eines Problems, dem sich viele Cloudanbieter gegenüber sehen. Die Malaise ist in etwa diese: Die fertigen Cloudimages sind ja schön und gut. Aber manchmal braucht man eben doch eine lokale Modifikation. Wer etwa besondere Hardware in seiner Cloud offeriert und diese an die Anwender durchreichen will, wird dafür regelmäßig eigene Images bauen.

Das ist allerdings – wie im Kasten “Gretchenfrage – Images oder Automation?” erläutert – nicht trivial, zumal wenn nicht das richtige Tooling zur Hand ist. Dagegen sind FAI und FAI.me erwiesenermaßen geeignete Werkzeuge, die flugs die Grundlage einer lokalen Image Factory bilden können, die ganz automatisch aktuelle Disk-Images mit besonderen lokalen Modifikationen ausgibt.

Wie das geht

Um das zu erreichen, setzt der Admin FAI zunächst so auf, als wollte er es für die Live-Installation von Knoten verwenden. Faktoren wie DHCP bleiben freilich außen vor – Sinn und Zweck ist ja das Erstellen bootbarer Medien. Danach hat er bereits die Möglichkeit, per »fai-cd« und »fai-diskimage « Images selbst anzulegen. Doch das ist nur die halbe Miete: Eigentlich will der Anwender diesen Akt ja in einen CI/CD-Prozess eingebettet haben, der dafür sorgt, dass bei Änderungen der FAI-Konfiguration der Imagebau automatisch startet und die Abbilder anschließend an einem zentralen Ort zum Download bereit sind.

Es bietet sich deshalb unbedingt an, FAI mit einem CI/CD-Werkzeug wie etwa Jenkins zu verbinden. Genau das tut übrigens auch das Debian-Projekt: Es hat seine FAI-Konfiguration im Debian-Gitlab liegen und dies mit Hooks so mit einer FAI-Installation verdrahtet, dass der beschriebene Mechanismus exakt so implementiert ist. Landet ein Commit im »master«-Branch des Repository, sorgt Gitlab anschließend dafür, dass automatisch neue Images entstehen.

Möchte der Admin die alten Images nicht automatisch überschreiben, empfiehlt es sich, im Namen das Datum zu kodieren. Gerade das Beispiel mit Gitlab ist gar nicht schwierig einzurichten, wenn er dafür sorgt, dass Gitlab eine VM hat, in der FAI lauffähig ist und die an das Gitlab-Repository selbst herankommt, um nach seinen Regeln Images zu bauen.

Statt eine Image Factory mühsam selbst zu entwickeln, kann es also eine gute Idee sein, auf FAI zurückzugreifen. Zumindest dann, wenn das Zielsystem Debian ist, mit dem FAI über seinen Autor Thomas Lange besonders verbunden ist.

Fazit

Das Bauen von Betriebssystem-Abbildern gilt vielen Admins als unnötig komplizierte Fingerübung, die viel Vorbereitung braucht. Dass es auch anders geht, zeigt FAI: Durch die Kombination der passenden Parameter für »fai-diskimage« oder »fai-cd« und »fai-mirror« baut es auf der Kommandozeile in kürzester Zeit generische Disk-Images.

Ganz unkompliziert und schnell lässt sich FAI selbst aber nicht aufsetzen. Wer plant, mit der Lösung Dutzende, Hunderte oder gar Tausende Systeme automatisch zu installieren, der nimmt die Mühe für die FAI-Erstinstallation gern in Kauf. Sie rentiert sich garantiert: Jeder neue Server, der auf diese Weise installiert wird, senkt dann den Gesamtaufwand und macht sich bezahlt.

Wer nur mal FAI-Luft schnuppern will, der ist bei FAI.me hingegen sehr gut aufgehoben: In kürzester Zeit lassen sich hier Disk-Images für Debian bauen, die aber Spielraum für lokale Anpassungen bieten. Es ist damit eine sehr sinnvolle und nützliche Erweiterung zu FAI selbst – ein Blick lohnt sich.