© 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.

All diese Arbeitsschritte sind für die Automatisierer kein Problem. Beispiel Paketinstallation: Alle gängigen Lösungen kommen mit einer Abstraktionsschicht, um auf beliebigen Zielsystemen Pakete über das dortige Paketmanagement zu installieren. Das Hinterlegen von Dateien im System ist eine absolute Grundfunktion, eventuelle Vorbereitungsschritte sind mit der Shell problemlos durchführbar. Wer bei null anfängt und ein Ansible-Playbook zum Beispiel für Maria DB schreiben will, wird aber trotzdem viel Zeit brauchen, um etwa die nötigen Parameter zu implementieren. Genau hier kommt Debops ins Spiel.

Debops besteht aus zwei Teilen. Da ist einerseits die Sammlung von fertigen Ansible-Rollen, aktuell über 110 Stück. Andererseits liefern die Autoren für diese Rollen ein paar in Python verfasste Userland-Werkzeuge. Jene sollen dem Admin die Nutzung der fertigen Debops-Ansible-Rollen erleichtern. Zu der Sammlung gehört etwa ein »debops« getauftes Werkzeug, das der Admin mit den passenden Parametern aufruft und das letztlich »ansible-playbook« so startet, dass es wie gewünscht funktioniert.

Über »debops-init« und » debops-update« greift Debops dem Admin bei der Installation und der Pflege seiner Debops-Ansible-Rollen unter die Arme. »debops-defaults« hilft dabei, die passende Konfiguration für das eigene System zu finden. »debops-padlock« gestattet es, sensible Passwörter verschlüsselt zu speichern, »debops-tasks« erlaubt das Abarbeiten mehrerer Aufgaben. Klingt – zugegeben – einigermaßen abstrakt.

Am besten nähert sich der Admin Debops ganz typisch mit Learning by doing. Aber Achtung: Die Lösung macht dem Admin oft das Leben leichter, doch kommt sie auch mit einigen veritablen Fallstricken daher, die er tunlichst umgehen sollte.

Debops – praktisch

Gegeben seien also mindestens zwei Debian-Systeme, die der Admin frisch installiert hat und die noch jungfräulich sind. Theoretisch würde das Beispiel auch mit einem einzelnen Host funktionieren, doch das wäre nicht sehr nahe an der Praxis, denn meist wollen Admins mit Ansible ja gerade mehr als einen Host verarzten. Das Beispiel geht im Folgenden davon aus, dass Ansible auf einem zentralen Automatisierungshost läuft, der sich auf den anderen Systemen per SSH einloggt und dort die Konfiguration wie gewünscht vornimmt.

Debops bezieht sich übrigens ausdrücklich nicht nur auf Debian, sondern will auch mit Ubuntu-Systemen funktionieren. Weil das Gros der Pakete auf beiden System ähnlich ist und viele zentrale Systemwerkzeuge die gleichen Namen haben, sollte das eigentlich problemlos funktionieren. Tests anlässlich dieses Artikels haben an verschiedenen Stellen jedoch Probleme mit Ubuntu aufgezeigt, während dieselbe Aufgabe auf Debian-Systemen problemlos funktionierte. Ganz identisch sind die beiden eben doch nicht – ob das im Einzelfall ein Problem ist, lässt sich leider nur durch Versuch und Irrtum herausfinden.

Damit das im Folgenden beschriebene Setup funktioniert, muss zunächst das Ansible-Programm selbst installiert sein. Es liegt aktuellen Debian- und Ubuntu-Versionen bei, ist dort jedoch naturgemäß etwas angestaubt. Besser ist es, sich vom Ansible-Upstream passende Pakete [3] in aktueller Version für das eigene System zu organisieren. Diese lassen sich ganz normal über die schon vorhandene Paketverwaltung des Systems installieren. Ist dieser Schritt erledigt, folgt die Installation von Debops.

Hier stutzt der Admin vermutlich erstmals: Für Debian gibt es Debops zwar als fertiges Paket, aber nur im Experimental-Branch und dort in einer ältlichen Version. Die offizielle Empfehlung ist, Debops via »pip « zu installieren. In Sachen Compliance treibt das vermutlich vielen Admins Tränen in die Augen; aktuell ist dieser Vorgang aber der einzige Weg, um an die aktuelle Debops-Version zu kommen. Der passende Befehl lautet:

pip install debops

Danach liegt »debops« mit den anderen Tools in »/usr/local/bin/debops« und ist bereit zur Nutzung.

Wie es weitergeht, hängt maßgeblich von der Frage ab, ob der Admin seine Hosts im Team mit anderen Admins betreut oder ob er ein Einzelkämpfer ist. Würde er »debops« nun als normaler Nutzer aufrufen, würden die gesamten Konfigurationsdateien des Werkzeugs in seinem Homeverzeichnis landen. Sollen Kollegen ebenfalls von Debops profitieren, ist das kaum sinnvoll.

Teamwork oder Einzelkämpfer?

Deshalb ist es schlau, in der – eventuell anzulegenden – Datei »/etc/debops.cfg« die folgenden Parameter zu setzen:

[paths]
data-home: /usr/local/debops

Danach landen die Innereien von Debops in eben diesem Verzeichnis. Wer nur als Root arbeitet, kann alternativ auch einen Pfad unter »/root« nutzen.

Apropos Root: Als genau der empfiehlt es sich, nun das Kommando »debops-update« auszuführen. Dann lädt das genannte Programm nämlich alle auf Github verfügbaren Debops-Playbooks für Ansible herunter und legt sie im zuvor konfigurierten Verzeichnis ab. Anschließend folgt »debops-init« mit einem Parameter, der das Zielverzeichnis für die Ansible-Konfiguration enthält.

Richtig gelesen: Die Ansible-Konfiguration liegt bei Debops gerade nicht im »data-home«. Wer ohnehin als Root arbeitet, kann unter »/root« den Befehl »debops-init local-setup« aufrufen. Im Anschluss findet sich darin die typische Ordnerstruktur, die Ansible erwartet – also »ansible« mit »inventory« und »roles« und den dazugehörenden Konfigurationsdateien (Abbildung 3).

Abbildung 3: Mittels »debops-init« legt der Admin den Grundstein für seine Automatisierung.

Als Admin wird man Debops viele Konfigurationsparameter mit auf den Weg geben wollen. Debops ist – wie beschrieben – ein Wrapper um Ansible, der am Ende »ansible« mit den korrekten Parametern aufruft. Ansible erwartet eine »ansible.cfg«, die Debops zuvor aus den hinterlegten Konfigurationswerten erzeugt.

Daraus ergibt sich, dass der Admin selbst in der generierten »ansible.cfg« besser nichts ändert, denn Änderungen dort würden durch Debops später überschrieben. Stattdessen stehen dem Admin die »/etc/debops.cfg« oder – besser – ».debops.cfg« im zuvor per »debops-init« angelegten Verzeichnis für seine Konfiguration zur Verfügung.

Verbindung benötigt

Wenn Ansible auf dem Konfigurationsserver eingerichtet ist, stellt sich im nächsten Schritt die Frage, wie von dort die Verbindung zu den anderen Servern klappt – also jenen, die Debops konfigurieren soll. Klar ist: Ansible setzt nicht auf ein eigenes Client-Server-Protokoll, sondern nutzt das bestens etablierte SSH, um Befehle auszuführen (Abbildung 4). Offen bleibt aber die Frage, wie Ansible und die anderen Server einzurichten sind, damit der Login klappt.

Abbildung 4: Ansible nutzt SSH für die Verbindung zwischen den Hosts.

Variante 1 besteht darin, einen unprivilegierten Nutzerzugang anzulegen, der per »sudo« anschließend Rootrechte erlangt. Das ist aber einigermaßen mühsam, weil der Admin dann bei jedem Ansible-Lauf händisch das Sudo-Passwort eingeben muss, falls er es nicht in der Konfiguration von »debops« fest hinterlegen möchte. Denkbar wäre freilich auch Sudo ohne Nutzerpasswort zu ermöglichen und stattdessen den Zugriff auf Basis von SSH-Schlüsseln zu managen.

Signifikante Vorteile hat diese Lösung gegenüber einem Prinzip, bei dem der Login per passwortlosem SSL-Schlüssel als Root erfolgt, aber lediglich auf dem Papier. Zumal SSH-Schlüssel in den meisten Setups ohnehin Standard sind und der Administrator in diesem Zusammenhang dann den Passwort-Login per SSH gleich ganz abschaltet.

Wer es sich traut, generiert also einen passwortlosen SSH-Schlüssel und legt dessen öffentlichen Teil via »ssh-copy-id« auf allen Zielservern für den Nutzer »root« ab. In ».debops.cfg« im Konfigurationsverzeichnis ist danach der Absatz »[ansible defaults]« um den Eintrag »remote_user = root« zu erweitern. Damit ist sichergestellt, dass Ansible auch tatsächlich den »root«-Account nutzt.

Bleibt die Frage, woher Debops weiß, mit welchen Hosts es sich verbinden soll. Dazu dient die Datei »ansible/inventory/hosts« im zuvor per »debops-init« angelegten Ordner:

server1.example.net
server2.example.net
server3.example.net

Die zu beachtende Syntax folgt dem ».cfg«-Modell.

Für Gruppen

Im Beispiel fehlt noch eine Gruppenbezeichnung. Die oben genannte Datei würde also dazu führen, dass generische Aufgaben, die nicht einer spezifischen Gruppe zugewiesen sind, auf allen drei Hosts ausgeführt werden. Genau jene Datei nutzt der Admin später übrigens auch, um Server zu Gruppen für Debops zusammenzufassen. Das gestaltet die Konfiguration einfacher. Um auf Server 1 PostgreSQL auszurollen, wäre etwa folgender Eintrag notwendig:

[debops_postgresql_server]
server1.example.net

Aus leidvoller Erfahrung haben die Debops-Entwickler gelernt, dass sie den Zustand der Zielsysteme irgendwie überprüfen müssen. Sie empfehlen in ihrer Dokumentation, das Kommando

debops-task all -m setup

nach dem Einrichten der Verbindung und der Inventory-Datei aufzurufen.

Mit Tricks zum Test

Die Sache hat allerdings einen Haken, denn die nötige »ansible.cfg« fehlt zu diesem Zeitpunkt noch, weil Debops sie noch nicht generiert hat – schließlich hat der Admin »debops« zu diesem Zeitpunkt noch gar nicht aufgerufen. Ein kruder Hack hilft: »debops« unmittelbar gefolgt von [Strg]+[C], um den Vorgang so schnell wie möglich wieder abzubrechen. Danach lässt sich »debops-task« wie beschrieben starten.

Wer sich über das Prozedere wundert: Anders als »debops« kann »debops-task« einzelne Ansible-Playbooks aufrufen wie hier »setup«. »debops« würde dagegen loslaufen und alle Playbooks auf jene Hosts anwenden, für die sie konfiguriert sind. Gerade das ist in diesem Schritt aber nicht gewollt.

Böse Überraschung

Im Rahmen dieses Beispiels lautet das Ziel, auf mindestens einem der Server eine funktionierende Instanz von PostgreSQL zu installieren – etwa als Basis für ein klassisches LAPP-Setup. Wenn der Setup-Schritt mit »debops-task« erfolgreich erledigt ist, steht dieser Arbeit nichts mehr im Wege – könnte man glauben. Tatsächlich sollte sich der Admin aber, noch bevor er sich genauer mit PostgreSQL beschäftigt, um einen kapitalen Bock kümmern, den Debops ansonsten schießt.

Bei einem normalen Lauf führt Debops das »common.yaml«-Playbook aus, und zwar auf jedem Host. Das konfiguriert bestimmte Basics und sorgt auch dafür, dass bestimmte grundlegende Pakete installiert sind und dass etwa die »apt«-Konfiguration identisch ist. Das Problem: Es installiert auch die Werkzeuge Ferm (For Easy Rulemaking, [4]) und Tcpwrapper. Und die nageln im Anschluss den Host per »iptables« zu, sodass ein Login aus der Ferne nicht mehr möglich ist. Ansible sperrt sich hier also selbst aus.

Verhindern lässt sich das, indem der Admin Tcpwrapper das rabiate Benehmen schlicht verbietet. Das gelingt mit Hilfe eines Parameters in »ansible/inventory/group_vars/all/debops.tcpwrappers.yml« innerhalb des Debops-Konfigurationsverzeichnisses. Der dafür nötige Eintrag lautet:

tcpwrappers_deny_all: False

Danach lässt Tcpwrapper zwar immer noch nicht komplett die Finger von IPtables, aber die tödliche Catch-all-Regel installiert er wenigstens nicht mehr.

PostgreSQL ausrollen

Wenn das Login-Problem erfolgreich umschifft ist, geht es weiter mit der Installation der ersten echten Applikation: PostgreSQL. Die Pakete für Debian und Ubuntu sind sinnvoll vorkonfiguriert, sodass der Admin hier erst mal nur an einer Stelle Hand anlegen muss: Er bestimmt das Passwort des Benutzers »admin« in der PostgreSQL-Datenbank.

In »ansible/inventory/group_vars/all/debops.postgresql_server.yml« fügt er dazu den Parameter

postgresql_server__admin_password:'sehr-geheim'

ein. Damit setzt er das Passwort global: Alle von Debops ausgerollten PostgreSQL sind anschließend mit diesem Passwort versehen. Alternativ lässt sich das Passwort auch pro Host setzen, und zwar über die Datei »ansible/inventory/host_vars/server1.example.net/debops.postgresql_server.yml« im Debops-Konfigurationsverzeichnis.

Wenn nun die »hosts«-Datei wie beschrieben angepasst ist, sodass »server1.example.net« dort zur Gruppe »debops_postgresql_server« gehört, genügt der Aufruf von »debops« aus dem Debops-Konfigurationsverzeichnis heraus: Dann setzt Debops Ansible auf den Weg, um den gewünschten Dienst auf dem Ziel-Host auszurollen.

Admins haben – sehr zu Recht – in aller Regel ein Problem damit, wenn die Passwörter für kritische Dienste im Klartext auf irgendeinem Host abgelegt sind. Ansible selbst bietet für diesen Zweck Vault an, mit dem Passwörter sich GPG-verschlüsselt ablegen lassen. Nur der Besitzer des GPG-Schlüssels kann beim Ansible-Aufruf die verschlüsselte Datei öffnen und das Passwort sehen.

Debops bietet ähnliche Funktionalität: Mittels Enc-FS und dem Werkzeug »debops-padlock« legt der Admin auch hier sein Passwort verschlüsselt ab, sodass nur er mit seinem GPG-Schlüssel wieder rankommt. Vorsicht ist freilich bei Adminteams geboten: Hier sollte ein separater GPG-Schlüssel erstellt und genutzt werden, dessen Passwort allen beteiligten Admins bekannt ist. Details zu »debops-padlock« verraten die Entwickler in der Dokumentation [5].

Der beschriebene Workflow spielt die Arbeit mit Debops am PostgreSQL-Beispiel durch. Die anderen Ansible-Rollen funktionieren aber genauso: Indem ein Admin in seiner »hosts«-Datei einzelne Hosts zu Gruppen hinzufügt, legt er fest, welche Dienste auf ihnen laufen sollen. Global oder pro Host stellt Debops anschließend die Konfiguration zur Verfügung.

An dieser Stelle ist »debops-defaults« sehr nützlich: Es zeigt alle vorhandenen Konfigurationsparameter für gerade aktive Rollen an. Wer an der Konfiguration eines Dienstes auf einem Host also etwas schrauben möchte, erhält mit diesem Befehl zunächst den Gesamtüberblick und kann danach beliebige Einstellungen wie beschrieben vornehmen.

Tatsächlich finden sich in den Debops-Playbooks so manche Juwelen: Der gesamte LAMP-Stack lässt sich beispielsweise mit Debops etwa ebenso wie PostgreSQL schnell einrichten. Elasticsearch, Logstach und Kibana (Abbildung 5) sind ebenso wenig ein Problem wie Samba, Postfix oder Snmpd.

Abbildung 5: Logstash, Elasticsearch und Kibana lassen sich mittels Debops auf einem jungfräulichen Debian-System schnell und leicht installieren.

Sicheres Repository

Sowohl die Debops-Werkzeuge selbst als auch die zugehörigen Playbooks pflegen die Entwickler in separaten Verzeichnissen auf Github [6]. Anfangs bestand das Debops-Team allerdings nur aus einer Handvoll Menschen. Weil sie alle Debian-Bezug hatten, stand für sie außer Frage, dass ihr Projekt ein offenes sein soll, an dem andere Entwickler zur Mitarbeit herzlich eingeladen sind.

Dass das Thema Sicherheit dabei nicht vernachlässigt wird, zeigen die Entwickler eindrucksvoll: Wer in die Github-Verzeichnisse eigenen Code einchecken möchte, muss diesen zuvor per GPG signieren. Nur entsprechend signierter Code kann überhaupt ins Github-Verzeichnis einziehen. Und über den GPG-Keyring, in dem die erlaubten Schlüssel verzeichnet sind, wachen die Debops-Oberen mit Argusaugen.

Im Grunde haben die Macher hier den Workflow abgekupfert, den Debian auch selbst für die eigenen Pakete nutzt: Auch bei Debian selbst dürfen nur jene Entwickler neue Pakete in das offizielle Debian-Archiv hochladen, deren GPG-Schlüssel im Debian-Keyring enthalten ist. Die Aufnahme als Debian-Entwickler oder als ein Paket-Maintainer besteht im Wesentlichen daraus, dass der eigene GPG-Schlüssel dem entsprechenden Keyring hinzugefügt wird.

Die Verlässlichkeit von Debops ist damit vergleichbar mit der von Debian selbst: Gelingt es einem Angreifer, den Zugriff auf einen GPG-Schlüssel eines genehmigten Entwicklers zu bekommen, kann er theoretisch großen Schaden auf den Zielsystemen anrichten. Wer auf Debian oder Ubuntu setzt, für den steigt das Risiko nicht signifikant.

Fazit

Debops ist ein kluger Ansatz: Nach der Erstinstallation eines Systems lässt sich dieses dank der Debops-Werkzeuge schnell zur Datenbank, zum Webserver oder zum Monitoring-Server konfigurieren. Die vorgefertigten Ansible-Rollen sind für den Admin extrem nützlich, weil er nicht viel Zeit ins Verfassen eigener Rollen investieren muss.

Die Tatsache, dass Debops manchmal nicht ganz intuitiv reagiert, verleidet den Genuss allerdings etwas. Und klar ist auch: Wer sich noch gar nicht mit Ansible auseinandergesetzt hat, wird bei Debops anfangs viel Doku wälzen, so als würde er sich direkt mit dem echten Ansible beschäftigen. Debops bietet also gute Starthilfe, schützt den Admin letztlich jedoch nicht davor, eigenes Ansible-Wissen aufzubauen. Was vermutlich ohnehin anzuraten wäre – schließlich sollte dem Admin grundlegend klar sein, wie das Setup funktioniert.

Wer schnelle Automatisierung für Debian oder Ubuntu will, der sollte den famosen Automaten Debops mal in Betrieb nehmen. Die Qualität der Playbooks ist nämlich gut, sodass ein schnellerer und besserer Einstieg in den umfangreichen Themenkomplex Debian plus Ansible kaum möglich ist.