© Peter Hermes Furian, 123RF

Automatisierung ist nicht nur in großen Setups hilfreich. Sie nützt überall dort, wo Admins identische Aufgaben immer und immer wieder erledigen müssen. Das Werkzeug Debops bringt viele oft gebrauchte Serverdienste schnell und leicht auf ladenneue Debian-Systeme.

Eine These, die in den vergangenen Jahren aufkam, besagt, dass sich Automatisierung nur für große Setups eigne, etwa für Clouds oder für verteilte Objektspeicher. Wer sich hingegen regelmäßig nur mit kleinen Setups beschäftige, für den zahle sich das Automatisieren nicht aus: Der Aufwand dafür sei dann viel höher als der für die einmalige, manuelle Ausführung.

Diese Behauptung ist gelinde gesagt problematisch. Denn zunächst ist es in der IT erfahrungsgemäß so, dass Admins Aufgaben selten nur ein einziges Mal ausführen. Wer kein großes Setup pflegt, der pflegt vielleicht viele kleine, bei denen die Installation immer denselben Regeln folgt. Oft zwingen auch unerwartete Ereignisse zur Wiederholung: Geht etwa ein Server irreparabel kaputt, muss der Admin ihn so schnell wie möglich ersetzen. Dann erweist sich auch bei kleinen Setups Automatisierung als wertvoll: Einerseits lässt sich die Arbeit schneller erledigen, andererseits ist die Fehleranfälligkeit deutlich geringer.

Abbildung 1: Puppet ist ein alter Hase im Geschäft der Automatisierer, aber es bedarf eines erheblichen Lernaufwands, um es zu meistern.

Zugegeben: Die Abneigung vieler Admins gegen Automatisierung hat gute Gründe. Die in Europa dominierenden Automatisierungslösungen Puppet und Chef sind zwar sehr mächtig. Aber sie bedingen auch viel Lernerei. Gerade bei Puppet (Abbildung 1) ist die Zahl der Funktionen kontinuierlich gestiegen. Zusätze wie Hiera vergrößern die Komplexität obendrein. Wer also mit der Automatisierung für ein Setup anfängt, sieht sich viel Arbeit gegenüber und hat es oft schwer, den passenden Anfang zu finden.

Ein bequemerer Einstieg

Ansible hat sich als Alternative zu Puppet & Co. inzwischen eine kleine Fangemeinde erkämpft. Es umschifft viel Komplexität der großen Lösungen [1]. Ansible-Rollen müssen aufgrund der Ansible-Syntax implizit so verfasst sein, dass sie sich selbst dokumentieren (Abbildung 2). Das gestaltet den Einstieg merklich leichter. Zudem sorgt die strenge, aber einfache Ansible-Syntax dafür, dass Admins ihr ohnehin vorhandenes Wissen schneller einbringen können – sie müssen keine neue, komplexe Syntax wie bei Puppet oder Chef lernen.

Abbildung 2: Ansible nutzt keine komplizierte Syntax, sondern setzt auf Yaml und zwingt Playbooks dazu, sich gewissermaßen selbst zu dokumentieren.

Mit den anderen Lösungen gemein hat Ansible aber die Arbeit, die anfangs ansteht. Wer ein zuvor nicht automatisiertes Setup mit Ansible umrüsten will, wird dafür noch immer einige Zeit benötigen. Wäre es nicht toll, gäbe es für die Standard-Dienste fertige Ansible-Rezepte, die sich per Knopfdruck in Sekundenschnelle installieren lassen?

Das zumindest dürften sich die Köpfe hinter Debops [2] gedacht haben. Debops ist eine riesige Sammlung fertiger Ansible-Rollen, die sich durch einzelne Befehle auf frische Debian-Systeme anwenden lassen. Von der Installation des Betriebssystems bis zur fertigen Datenbank vergeht so merklich weniger Zeit. Wie funktioniert die Lösung und hält sie, was sie den Admins verspricht? Das Linux-Magazin schaut genauer hin.

Was Automatisierung leisten muss

Bevor der Artikel auf Debops im Detail eingeht, steht eine andere und vermeintlich leichte Frage an: Was genau muss Automatisierung eigentlich leisten, um Admins das Leben tatsächlich zu erleichtern? Nur wenn das klar ist, lässt sich die Performance von Debops bewerten. Für eine Antwort ist ein Blick unter die Haube gängiger Software nötig.

Die meisten Programme durchlaufen bei ihrer Installation drei Schritte. In Schritt 1 steht die Installation der Pakete an, die der Distributor für das jeweilige Programm bereitstellt. Schritt 2 ist anschließend die Konfiguration: Dazu genügt es in der Regel, eine passend vorbereitete Konfigurationsdatei an den Ort im Dateisystem zu legen, wo der Dienst sie erwartet. Der dritte und letzte Schritt ist der Start des Dienstes und die Überprüfung, ob er wie gewünscht arbeitet.

Manchmal ist noch ein Zwischenschritt nötig, nämlich dann, wenn die fragliche Komponente vor dem ersten Start einen Bootstrapping-Prozess braucht und ihn nicht automatisch selbst initiiert. Datenbanken verlangen manchmal, dass der Admin ihr Datenverzeichnis händisch initiiert. Bei vielen Diensten ist auch das händische Anpassen von Zugriffsrechten für Dateien erforderlich, damit der Programmstart klappt.