Hinweis:
Dieser Blogartikel ist älter als 5 Jahre – die genannten Inhalte sind eventuell überholt.
Bei der heutigen Zahl an Systemen und darauf laufender Anwendungen in einer IT-Abteilung ist deren manuelle Verwaltung keine ernsthafte Option mehr für Systemverwalter. Parallelausführung von Skripten, Konfigurationsmanagement und Deploymentwerkzeuge sind die Antworten des Zeitalters der Automation. Rex ist die Synthese dieser drei Ansätze. Jetzt ist nach gut vier Jahren die Version 1.0 erschienen.
Wer die Herausforderungen der Verwaltung komplexer IT-Landschaften verstehen will, muss ein wenig in die Geschichte dieser Disziplin schauen: Operateure setzten sich direkt vor die betroffenen Computer und warteten mittels Handbuch und Erfahrung die Systeme und die dort laufenden Anwendungen. Gerade in gut klimatisierten Rechenzentren war das oft ein unbeliebter Job.
Ausflug in die Geschichte: Vom Operateur zum System Engineer
Im Zuge der voranschreitenden Vernetzung war die gleiche Tätigkeit plötzlich aus einem Büro von einem Terminal oder PC mittels Netzwerkverbindung möglich. Operateure nannte man nun Systemadministratoren. Ihre Werkzeuge nannten sie nun Telnet oder später SSH, aber die Tätigkeiten ähnelten immer noch denen der Vergangenheit: Sie loggten sich über das Netz auf dem Zielsystem ein, erlangten dort Administratorrechte und warteten die Software. Das konnte das Anpassen von Konfigurationen umfassen, das Überwachen von Logfiles oder den Neustart von abgestürzten Anwendungen.
In Zeiten, in denen Verfügbarkeit eine wesentliche Rolle spielt, ist diese Art der Systemadministration jedoch kaum noch realisierbar: Die Zahl der einzelnen Anwendungen steigt mit den immer komplexeren Aufgaben, die die IT erbringt. Systemarchitekten nennen den Effekt vertikale Skalierbarkeit. Hier setzt Rex an, ein als Open-Source-Projekt entwickeltes Framework, das ein gutes Dutzend Entwickler rund um Projektleiter Jan Gehring entworfen haben. Der moderne System Engineer hat mit Rex eine Umgebung, mit der er anwendungsbezogen an zentraler Stelle die Schritte ablegt, die zur Konfiguration und Verwaltung notwendig sind.
Neben der vertikalen Skalierbarkeit beschäftigt Systemverwalter aber auch die Zahl der zu verwaltenden Instanzen. Seitdem Virtualisierung populär und produktionsreif ist, schnellt diese nämlich zusätzlich in die Höhe. Wo früher ein Webserver das Unternehmen im Netz repräsentierte, kümmert sich in Zeiten des Cloud Computing oft ein ganzer Schwarm von gleichartigen Frontends, Applikationsservern und Datenbanken um die Entgegennahme von Kundenanfragen und Bestellungen. Diese zweite Dimension des Wachstums nennen die Systemplaner horizontale Skalierbarkeit.
Vertikale und horizontale Skalierbarkeit
Rex adressiert diese Herausforderung dadurch, dass es seine Anleitungen, Rexfiles genannt, nicht zwingend auf einen konkreten Host anwendet, sondern stattdessen auf abstrakte Hostgruppen. Die lassen sich dann zentral mit den dazu notwendigen Benutzernamen, Passwörtern und Zertifikaten verwalten. Zur Kommunikation zwischen der Kommandozentrale und den gemanagten Hosts greift Rex auf den kleinsten gemeinsamen Nenner der vernetzten Systemadministration zurück und verbindet sich per SSH auf die einzelnen Hosts. Dabei kapselt das Werkzeug aber die konkrete Übertragung. Wie seine Rexfiles ausgeführt werden und wo, das braucht der System Engineer gar nicht zu berücksichtigen, wenn er die Anleitungen schreibt.
Konfigurationsmanagementsysteme sind umso flexibler, je geringere Ansprüche sie an die betreuten Nodes stellen. Sind dort irgendwelche Agents, Daemons oder Plugins notwendig, dann müssen diese zumindest initial den Weg auf die Nodes finden und dort dauerhaft laufen. Rex umschifft dieses Problem mit einem Kniff: Da auf jedem Node meist ohnehin ein SSH-Zugang für den Admin oder die Anwender existiert, nutzt es diesen Weg gleich mit. Als einzige weitere Anforderung muss auf den verwalteten Nodes ein Perl-5-Interpreter vorhanden sein – den bringt praktisch jede Linux-Distribution heute mit. Dauerhaft laufende Software oder ein wartender Daemon sind bei Rex nicht notwendig.
Transparenz und Wiederholbarkeit
Buchhaltung, Controlling und rechtliche Verordnungen erfordern über die Skalierbarkeit hinaus auch ein definiertes Maß an Nachvollziehbarkeit: Wer einst dem verschrobenen Operateur im Serverraum all seine Daten in die Hände gelegt hat und darauf vertraute, dass dieser sein Handwerk verstünde, so sind heute transparentere Maßnahmen nötig: IT-Sicherheitsrichtlinien fordern, dass Änderungen an der Software protokolliert und nachvollziehbar geschehen, um so im schlimmsten Fall Manipulationen zu verfolgen.
Wer also heute moderne Anwendungsumgebungen entwerfen und betreiben möchte, muss diese Anfroderungen berücksichtigen. Zunächst behalfen sich Administratoren damit, wiederkehrende Arbeiten in Skripten zusammenzufassen. Ein Beispiel: Die Schritte, eine Datenbank herunterzufahren, ihre Inhalte in einer Datei zu sichern, die Datenbank wieder hochzufahren und die Sicherung in komprimierter Form im Backup zu archivieren, lassen sich gut in zwanzig Zeilen Code formulieren.
Doch solche Skripte haben ihre eigenen Probleme: Jeder Sysadmin schreibt nach seinem eigenen Stil und geht oft von Voraussetzungen aus, die nach einiger Zeit nicht mehr gelten, etwa hinsichtlich der Namen von Verzeichnissen oder Computern. Weiterhin gilt es, diese Skripte von einer Kommandozentrale auf vielen Rechnern gleichzeitig auszuführen. Auch das lässt sich skripten, aber schnell wird die Administration so zu einem unentwirrbaren Knäuel aus Aufrufen, die nur bedingt miteinander harmonieren.
Dazu kommt, dass manche Aufgaben zwar vordergründig einfach zu realisieren sind, in der Realität aber, wenn sie umsichtig implementiert werden, immer wieder die gleichen Schritte erfordern. Beispiele sind das Liefern von Returncodes, das Aufräumen von Temporärdateien oder die Besonderheiten beim Arbeiten über eine verschlüsselte Verbindung.
Außerdem benennen die einzelnen Linux-Distributionen manche Datei oder manches Verzeichnis etwas unterschiedlich: Wer einen Apache-Webserver installiert, findet dessen Konfigurationsdateien unter Red Hat Enterprise Linux, CentOS oder Fedora unter dem Pfad /etc/httpd. Auf einem Debian- oder Ubuntu-System liegen diese im Verzeichnis /etc/apache2. Manche Systeme konfigurieren ihre Netzwerkinterfaces mit dem Kommando ifconfig, andere mit dem neueren ip. Um ein Paket zu installieren verwendet OpenSuse das Tool zypper, Distributionen aus dem Haus Red Hat yum und die Debian-Welt aptitude.
Abstraktion in der Konfiguration sichert gegen Silo-Wissen ab
Diese Vielfalt bändigt Rex dadurch, dass es mit einem Modulsystem die wichtigsten Aufgaben abstrahiert. Auf der Website rexify.org finden sich mehrere Dutzend Plugins, die zum Beispiel die Arbeit mit Logfiles, Datenbanken, Hypervisoren oder Firewalls vereinfachen.
Obwohl schon vor dem Bau des ersten Computers die Informatikpioniere Church und Turing nahelegten, dass alle Programmiersprachen im Ergebnis gleichartig wären, hielt das die Architekten von Programmiersprachen nicht auf, ein neues Babylon zu schaffen: Heute gibt es Dutzende von Programmiersprachen. Im Feld des Konfigurationsmanagements ist eine ähnliches Phänomen zu beobachten.
Ein Standard muss her
Bei manchen Werkzeugen beschreibt der System Engineer nur, wie er sich seine Zielarchitektur vorstellt. Der Hersteller solcher Software liefert Regeln mit, wie sich solche Ziele umsetzen lassen. Die Herausforderung solcher deklarativer Beschreibungen ist nur, dass sie sehr präzise sein müssen. Weiterhin müssen die Anbieter für viele Fälle schon Regeln mitliefern oder vorsehen, dass diese leicht nachzurüsten sind.
Puppet ist ein Vertreter dieser Fraktion. Das weit verbreitete Framework stellt eine eigene Domain Specific Language (DSL) bereit, die deklarativ beschreibt, wie ein mit Puppet verwaltetes System aussehen soll. Wie die einzelnen Computer dies erreichen sollen, klammert Puppet dabei aus. Durch diesen Ansatz ist die Sprache anfangs nicht ganz einfach zu erlernen und führt daher manchmal zu Überraschungen.
Rex nutzt hier einen deutlich pragmatischeren Ansatz: In seinen Rexfiles gibt der Systemverwalter pro Aufgabe Schritt für Schritt an, was zu tun ist. Dabei kann er prinzipiell Perl als Programmiersprache verwenden, auch wenn das in den meisten Fällen keine gute Idee und auch nur selten nötig ist. Denn Rex liefert durch seine Module eine ganze Reihe von praktischen Kommandos gleich mit. Wie diese Aufgaben in konkrete Befehle auf den Zielsystemen umgesetzt werden, findet das Framework selbstständig zur Laufzeit heraus.
Dieser imperative Ansatz beschert Rex auch eine Sonderstellung im Konfigurationsmanagement, denn es lassen sich damit auch Deploymentaufgaben erledigen. Bei ersterem tut nur dann etwas, wenn sich an der grundsätzlichen Systemumgebung etwas ändert. Das ist beispielsweise der Fall, wenn eine Anwendung nun mehr Speicherplatz erhalten soll oder eine IP-Adresse sich ändert.
Manche Umgebungen meinen das gelöst zu haben, indem es ausreicht, eine Datei im richtigen Verzeichnis abzulegen. In der Realität sind trotzdem oft viele zusätzliches Tätigkeiten nötig: So lädt ein Deployment vielleicht einen initialen Datensatz, konvertiert ihn zum Gebrauch der Anwendung, holt dann erst die überarbeitete Software aus einem Repository, führt einige Tests durch und aktiviert bei deren Erfolg die neue Revision.
Aus diesem Grund ist Rex auch ein guter Kompagnon von Build- und CI-Tools wie beispielsweise Jenkins. Sobald dort eine neue Fassung einer Anwendung fertig und getestet ist, kann Jenkins Rex aufrufen und die Software installieren.
Perl-Kenntnisse nützen beim Einsatz, sind aber keine Voraussetzung
Die Mischung aus Pragmatismus und Vereinheitlichung trägt zur Beliebtheit von Rex hinzu: Auch etwas kniffligere Datentransformationen lassen sich mit Regular Expressions, dem riesigen Angebot der CPAN-Module in objektorientierter Notation formulieren, und dennoch sind einfache Aufgaben präzise und knapp formulierbar. Das weiß die wachsende Community von Anwendern und Entwicklern zu schätzen. Gut ein Dutzend Aktive steuern regelmäßig Code bei.
Die Rex-Entwickler sind regelmäßig auf Konferenzen unterwegs und stellen das Werkzeug dort vor. Die nächsten Stationen nach den Kieler Linux Tagen, dem LinuxTag 2014 in Berlin, dem Nordic Perl Workshop in Helsinki und einigen weiteren Konferenzen und Meetups sind bereits in Planung.
Rex gibt es seit Ende 2010. Ursprünglich konnte es nur Dateien mit upload auf Nodes hochladen und Shellbefehle mit run ausführen, um Webanwendungen im Java- sowie Ruby-On-Rails Umfeld nachvollziehbar auf mehreren Systemen zu deployen. In 55 Releases hat sich seither eine Menge getan. Das betrifft vor allem die Abstraktion von typischen Objekten wie Dateien, Templates, Verzeichnissen, Berechtigungen oder Firewall-Regeln, mit denen Admins regelmäßig umgehen. Aber auch das Anbinden an Cloud-Dienste oder der Einsatz einer unabhängigen und versionierbaren Konfigurationsdatenbank (CMDB) markieren wichtige Meilensteine der Entwicklung.
Support und Features rechtfertigen den Versionssprung auf Rex 1.0
Anfang März ist nun Rex 1.0 erschienen. Weil die Entwickler nach dem Prinzip der semantischen Versionierung arbeiten, versprechen sie, die öffentliche Schnittstelle, das Rex-API, in dieser Version nicht mehr zu verändern. Die Entwickler gehen sogar noch einen Schritt weiter und erheben die Version 1.0 zu einem LTS-Release (Long Term Support), das sie bis März 2017 mit Bugfixes versorgen wollen. Das bedeutet, dass neue Features nur noch durch externe Module dazu kommen, sich der Kern selbst aber nicht verändert. Mittlerweile bieten auch schon einige Freiberufler und Unternehmen kommerziellen Support für Rex an.
Seit dem Projektstart vor gut vier Jahren hat sich um das Werkzeug zur Konfigurationsverwaltung und zum Softwaredeployment eine eigene Fangemeinde versammelt, die auf pragmatisches Verwalten von Nodes auf Perl-Basis schwört. Da mittlerweile Module für die meisten Situationen bei der Softwareverteilung und ihrer Konfiguration bereitstehen, sich das Tool mit wenig Aufwand erweitern lässt und eine hilfsbereite Community bereitsteht, trägt Rex seine neue Versionsnummer zu Recht.
Interview: Fünf Ziele für Rex 2
Jan Gehring, Initiator und Projektleiter von Rex, spricht im Interview über neue Features seines Tools, Entwickler und eine besondere Regular Expression.
Was war die ursprüngliche Motivation, Rex zu veröffentlichen?
Ich habe schon viele Projekte veröffentlicht, aber keines hatte so viele Benutzer wie Rex. Der Grund dahinter ist der, dass ich der IT-Gemeinschaft auch etwas zurückgeben möchte. Das ganze Wissen, das ich über die Jahre angesammelt habe, kommt von irgendwelchen Menschen, die ich noch nie gesehen habe, die aber gute Blog-Posts (kostenlos) veröffentlicht haben oder auf Fragen in Foren geantwortet haben. Wenn ich im Gegenzug mit der Veröffentlichung von Rex Anderen helfen kann, freut mich das sehr. Auf unserer Website nehmen wir aber auch Spenden entgegen!
Wie kamst Du auf den Namen für Rex? Kannst Du die Überlegung hinter der Regular Expression erklären, die dahinter steht?
Der Name des Projektes ist ja (R)?ex. Dabei steht das ex für Execution. Das (R)? steht für vielleicht Remote. Anwender können also Aufgaben remote wie lokal erledigen.
Die Benutzerbasis von Rex ist seit Projektstart ziemlich gewachsen. Was weißt Du über Eure Anwender?
Eigentlich wissen wir nur wenig über unsere Anwender, da wir dazu bislang kaum Daten erheben und auswerten. Wir wollen aber noch in diesem Jahr auf unsere Benutzer zugehen und sie um sie um User-Stories bitten.
Wie ist das Projekt intern heute strukturiert? Wie viele Committer hattest Du in den letzten sechs Monaten? Haben sich Co-Maintainer herausgebildet?
Das Projekt selbst besteht mittlerweile aus drei Core-Committern. Pull Requests bekommen wir immer wieder aus der Community. Laut Github gab es in den letzten sechs Monaten rund ein Dutzend Committer, zu denen noch Beiträge per E-Mail dazukommen. Damit liegen wir auch im Vergleich zu den klassischen Configuration Management Systemen ganz gut. Leider gibt es ja Freshmeat oder Freecode nicht mehr, denn das war eine Plattform, über die wir gut neue Benutzer erreicht haben.
In welche Richtung möchtest Du Rex im nächsten Jahr steuern?
Für Version 2.x haben wir uns fünf Ziele gesteckt: Als erstes wollen wir unsere Erfahrung aus der Vergangenheit im Code-Design nutzen, um eine stabile Basis für Rex zu schaffen. Daran arbeiten wir bereits seit einiger Zeit.
Zweitens wollen wir Rex‘ Weboberfläche Rex-JobControl stark erweitern und stärker integrieren. Dazu migrieren wir das Bare-Metal-Deployment von Rex.IO und bauen es in Rex-JobControl ein. Obendrauf kommt noch VM- und Cloud-Management dazu. Um den Anwendern einen besseren Überblick über ihre Systeme zu liefern, wollen wir drittens die Reporting-Schnittstelle erweitern. Damit wird es einfacher, auch eigene Reporting-Backends wie etwa Kibana und Elasticsearch zu integrieren.
Viertens planen wir, Repositorio und Rex-JobControl zu verbinden. Das ist ein eigenes Projekt, das Linux-Repositorys verwaltet. Die Erweiterung zeigt dann automatisch in Rex-JobControl an, welche Pakete es wo aktualisieren muss oder wo Sicherheitsprobleme drohen. Das letzte Ziel ist eine Integration von Windows. Anwender fragen häufig danach, doch aktuell müssen wir sie noch vertrösten.
Wo siehst Du Rex in fünf Jahren?
Im personellen Bereich wünsche ich mir, dass die Zahl der Core-Commiter weiter wächst, damit das Projekt im Zweifel auch ohne mich weiterleben kann. Schön wäre es, wenn wir dann einen Verein hätten, dem die ganzen Rechte gehören.
Aus technischer Sicht haben wir noch viele Ideen und auch Herausforderungen. Heute weiß noch niemand genau, wie sich Configuration-Management an sich weiterentwickeln wird. Ich sage aber voraus, dass es in fünf Jahren die Version 3 gibt – mit welchen Features, das kommt auf die Wünsche der Community an!
