© andreblais, 123RF

Das ursprüngliche Ziel von Open Stack ist es, die Infrastruktur fürs Rechenzentrum bereitzustellen. Was aber ist mit den Anwendungen, die darauf laufen sollen? Eine Antwort versucht das Murano-Projekt.

Unter der Schirmherrschaft von Open Stack beziehungsweise der Foundation gibt es eine Menge von Projekten. Was 2010 recht klein mit Nova und Swift anfing, ist nun eine umfangreiche Ansammlung von verschiedenen As-a-Service-Einheiten geworden. Wie Open Stack selbst haben sich auch die Anforderungen und Erwartungen seiner Benutzer vergrößert. Aus der Perspektive des Rechenzentrums mag es ausreichend sein, dass Server, Netzwerk und Datenspeicher elegant und schnell bereitstellbar sind.

Ein Cloudanbieter kann damit schon Geld verdienen. Für die meisten anderen ist die Infrastruktur aber erst der Anfang. Für ihr eigentliches Geschäft müssen Anwendungen mit entsprechender Konfiguration auf der Open-Stack-Maschinerie laufen. Die bloße Infrastruktur ist für sie nicht genug. Der Normalfall sind dagegen 2-Tier- oder 3-Tier-Applikationen mit Abhängigkeiten zwischen den einzelnen Komponenten und oft genug auch zusätzliche Anforderungen an das zugehörige Netzwerk.

Fertige Kollektion

Angenommen jemand möchte sich neu einkleiden. Er braucht Hemd, Weste, Jackett und Hose. Open Stack entspräche in dieser Analogie einem Einkaufszentrum. Der Käufer müsste die einzelnen Geschäfte besuchen und sich aussuchen, was er haben will. Er muss dabei aber auch selbst darauf achten, dass die Sachen zusammenpassen. Wäre es nicht viel einfacher, er könnte aus einem Katalog eine bereits komplett zusammengestellte Garderobe wählen? Im realen Leben versuchen gerade Startups wie Outfittery.de oder Modomoto.de mit dieser Geschäftsidee zu punkten.

Dieser Katalog – allerdings für Applikationen – ist das Open-Stack-Projekt Murano [1]. Grob gesagt stellt das Projekt Schnittstellen bereit, um eine komplette Applikationsumgebung in einer Open-Stack-Wolke zu installieren und zu verwalten. Dabei erfindet Murano das Rad nicht komplett neu, sondern greift auf vorhandene Projekte zurück.

Für die Orchestrierung und die Arbeitsabläufe kommen beispielsweise Heat beziehungsweise Mistral zum Einsatz. Murano versteht sich als Integrator, der die vorhandenen Puzzleteile zu einem Bild zusammenfügt. Abbildung 1 zeigt eine abstrakte Sicht auf das Zusammenspiel der Open Stack-Komponenten.

Abbildung 1: Murano im Zusammenspiel mit anderen Open-Stack-Komponenten.

Seit den Anfängen im Jahr 2013 hat sich Murano weiterentwickelt und ist heute weit mehr als nur ein Katalog. Es übernimmt beispielsweise die Verwaltung des gesamten Lebenszyklus einer Anwendung. Dazu gehören auch Themen wie automatische Skalierung, Hochverfügbarkeit oder auch nur das profane Backup. Ein Blick auf die Zukunftspläne [2] lässt ahnen, dass hier noch viel mehr zu erwarten ist.

Geschichtliches: Wie alles begann

Die Anfänge von Murano – außerhalb der IT bekannt als Inselgruppe vor Venedig, die für ihre Glaskunst berühmt ist – reichen mindestens bis in den Februar 2013 zurück. Interessanterweise machte das Projekt seine ersten Schritt mit Windows und seinem Verzeichnisdienst Active Directory. Die treibende Kraft hinter dem Applikationskatalog ist die Firma Mirantis [3], unter anderem Gründungsmitglied der Open Stack Foundation. Eine einfache Analyse der Softwarebeiträge zu Murano zeigt, dass mindestens die Hälfte der zirka 80 Entwickler aus dieser Firma kommen.

Allerdings hat das Projekt auch erst seit der Open-Stack-Version Juno eine gewisse Sichtbarkeit. Der breiteren Öffentlichkeit ist Murano wohl erst seit dem Summit in Vancouver bekannt, wo eine Art Marktplatz-Version des Projekts vorgestellt wurde. Wem es in den Fingern juckt, gleich selbst einen Blick in den Katalog zu werfen, der findet in dem Kasten “Erste Schritte” die notwendigen Hinweise und Tipps.

Abbildung 2: Anwendungen im Murano-Katalog einer privaten Open-Stack-Installation.

01 $
02 $ git clone https://git.openstack.org/openstack-dev/devstack
03 [...]
04 $ git clone https://git.openstack.org/openstack/murano
05 [...]
06 $ export DEVSTACK_DIR=`pwd`/devstack/
07 $ cd murano/contrib/devstack/
08 $ cp lib/murano ${DEVSTACK_DIR}/lib
09 $ cp lib/murano-dashboard ${DEVSTACK_DIR}/lib
10 $ cp extras.d/70-murano.sh ${DEVSTACK_DIR}/extras.d
11 $ cd $DEVSTACK_DIR
12 $ vi local.conf
13 [...]
14 $ cat local.conf
15 [[local|localrc]]
16 ADMIN_PASSWORD=Password
17 DATABASE_PASSWORD=$ADMIN_PASSWORD
18 RABBIT_PASSWORD=$ADMIN_PASSWORD
19 SERVICE_PASSWORD=$ADMIN_PASSWORD
20 SERVICE_TOKEN=b670a556-36a3-37c3-a5d2-f712f8080d50
21 enable_service heat h-api h-api-cfn h-api-cw h-eng
22 enable_service murano murano-api murano-engine
23 $
24 $ sudo ./tools/create-stack-user.sh
25 [...]
26 $
27 $ sudo cp -a /root/devstack /opt/stack/
28 $ sudo chown -R stack:stack /opt/stack/
29 $ sudo su - stack
30 $ cd devstack
31 $ ./stack.sh
32 [...]

Wer redet hier mit wem und warum?

In Abbildung 1 ist das Zusammenspiel von Murano mit verschiedenen Open-Stack-Komponenten dargestellt. Im Hintergrund sind zwei Prozesse aktiv: »murano-api« und »murano-engine« . Der Name impliziert schon, dass der erste die Schnittstelle nach außen ist. Ein nativer Murano-Client oder andere Open-Stack-Komponenten nehmen den Kontakt über diesen Daemon auf. Er gibt die Information an den anderen Prozess – die Engine – weiter, die für die eigentliche Arbeit verantwortlich ist.

Der erste Schritt ist dann die Generierung einer Umgebung (Environment). Im Wesentlichen fasst Murano hier die zu installierenden Anwendungen mit ein paar Infrastrukturangaben für die darunterliegenden virtuellen Server zusammen. Das können Angaben über die verwendete Variante für den Gast, das Netzwerk, Servername oder Verfügbarkeitszone sein. Anders gesagt: Die Umgebung gibt die Topologie des zu installierenden Dienstes an. Jedes dieser Konstrukte bekommt einen Namen für die Referenzierung.

Die Murano-Maschine analysiert die Angaben der Umgebung und prüft, ob alle benötigten Komponenten vorhanden beziehungsweise zugänglich sind. Wenn sich der Anwender über die Umgebung informieren will, empfiehlt sich die Verwendung der grafischen Schnittstelle, denn die Kommandozeile ist hier nicht besonders gesprächig (siehe Listing 2) – ganz anders beim Zugriff über Horizon (Abbildung 3).

01 $ murano environment-list
02 +----------------------------------+------------+---------------------+---------------------+
03 | ID                               | Name       | Created             | Updated             |
04 +----------------------------------+------------+---------------------+---------------------+
05 | 1160f3d830cd4aaf8ea53bf42d4bd8f9 | DockerTest | 2015-09-01T05:20:20 | 2015-09-01T05:20:20 |
06 +----------------------------------+------------+---------------------+---------------------+
07 $ murano environment-show 1160f3d830cd4aaf8ea53bf42d4bd8f9
08 +------------+----------------------------------+
09 | Property   | Value                            |
10 +------------+----------------------------------+
11 | created    | 2015-09-01T05:20:20              |
12 | id         | 1160f3d830cd4aaf8ea53bf42d4bd8f9 |
13 | name       | DockerTest                       |
14 | networking | {}                               |
15 | services   | []                               |
16 | status     | pending                          |
17 | tenant_id  | 55273dedb2be476c812f0bc3f953f2cf |
18 | updated    | 2015-09-01T05:20:20              |
19 | version    | 0                                |
20 +------------+----------------------------------+
21 $

Abbildung 3: Mit ein paar Mausklicks stellt der Admin in Murano eine komplette Umgebung zusammen – hier ein Webserver mit drunterliegender Container-Infrastruktur.

Ist alles im grünen Bereich, dann kontaktiert Murano die erforderlichen Open- Stack-Module, um die entsprechenden Komponenten bereitzustellen. Für Netzwerkkomponenten wäre das zum Beispiel Neutron. Im nächsten Schritt erzeugt Murano eine Vorlage für die Orchestrierung – im Open-Stack-Sprech heißt das: ein Heat-Template. Das Template dient dann als Gerüst für die darauffolgenden Schritte.

Hier gibt es zwei Möglichkeiten. Der Murano-Weg wäre die Installation einer Agenten-Software ([9], [10]) im virtuellen Server. Dieser kümmert sich dann um die weiteren unerledigten Aufgaben. Unter [11] befinden sich Glance-Abbilder, die diesen Agenten bereits enthalten. Alternativ kann man auch den reinen Heat-Weg gehen. Dann erfolgen die weiteren Schritte komplett über die Definitionen innerhalb der Orchestrierungssoftware von Open Stack.

So oder so steht am Ende eine vollständig installierte und konfigurierte Anwendung dem Nutzer zur Verfügung. Der letzte Schritt ist die Rückmeldung an den API-Daemon, der die Meldung über Erfolg oder Misserfolg nach außen weitergibt.

Selbst ist der Paketierer

Der aufmerksame Leser fragt sich nun, auf welche wundersame Weise die Abhängigkeiten der Komponenten beziehungsweise die zu konfigurierenden Parameter ins Spiel kommen, damit eine funktionierende Umgebung entsteht. Auch die Installationsreihenfolge der beteiligten Anwendungen spielt in vielen Fällen eine wichtige Rolle. Die Magie ist im Murano-Paket der beteiligten Applikationen verborgen. Es enthält das Rezept mit allen Zutaten inklusive Querverweisen auf andere Anleitungen.

Für die ersten Schritte kann sich der Admin bereits vorgefertigte Pakete vom Community-Katalog [12] herunterladen und in die eigene Open-Stack-Installation integrieren. Die Anfertigung eines eigenen Pakets gewährt natürlich einen ausführlichen Blick hinter die Kulissen. Prinzipiell ist die dafür notwendige Vorgehensweise dokumentiert ([13], [14], [15]), aber nicht einfach zu lesen. Die Anleitung enthält eine Reihe von Querverweisen, sodass der Leser oft hin und her wechseln muss. Außerdem gilt es, die so genannte Murano-Programmiersprache (Murano PL, Murano Programming Language, [16]) zu lernen. Sie setzt sich im Wesentlichen aus den Auszeichnungssprachen Yaml (Yaml Ain’t Markup Language, [17]) und Yaql (Yet Another Query Language, [18]) zusammen.

Für den Paketbau gibt es zwei Herangehensweisen. Die für den Anfang einfachere Variante verwendet eine Heat-Vorlage als Basis [19]. Das Kommando »murano package-create –template /Pfad/zum/Heat-Template« generiert ein Zip-Archiv, das sich mittels »murano package-import /Pfad/zur/Zip-Datei« integrieren lässt. Die Steuerungsmöglichkeiten des Benutzers sind hier recht beschränkt. Es gibt lediglich ein paar Zusatzoptionen für das Sub-Kommando »package-create« und die Konfigurationen in der Heat-Vorlage selbst.

Aufwändiger, aber auch viel stärker auf die eigenen Bedürfnisse anpassbar ist das manuelle Zusammenstöpseln eines Murano-Pakets. Die wesentlichen Bestandteile sind eine generelle Beschreibung der Anwendung und die Installationsanweisung. Letztere enthält Verweise auf zu verwendende Skripte, Murano-PL-Klassen und eventuell auch Benutzerdialoge zum Abfragen von Konfigurationseinstellungen. Die Beschreibung erfolgt dabei in dem zuvor genannten Yaml/Yaql-Format. Dazu kommt noch eine bestimmte Verzeichnisstruktur zum Ablegen der verschiedenen Dateien. Der Autor hat ein einfaches Beispiel auf seiner Github-Seite [20] bereitgestellt.

Vor und hinter dem Horizont

Zum gegenwärtigen Zeitpunkt weist Murano einige sehr nützliche Funktionen auf. Das Installieren kompletter Anwendungen inklusive Abhängigkeiten und Zusatzdefinitionen auf Knopfdruck ist dabei die hervorstechenste Eigenschaft. Mit einem Schlag liefert Open Stack mehr als nur Infrastruktur, wo der Benutzer noch viel Hand anlegen muss, bevor sie für das Business nützlich ist.

Murano geht noch weiter: Seit Kurzem kann der Murano-Admin so genannte Anwendungsaktionen definieren. Darüber implementiert er Dinge wie automatische Skalierung, Hochverfügbarkeit oder Datensicherungen [21].

Ein Blick auf die geplanten Änderungen für die nächste Version [2] zeigt, dass das Projekt sein Potenzial noch lange nicht voll entfaltet hat. Der einzige Wermutstropfen ist, dass bisher nur Mirantis als stark sichtbarer Befürworter auftritt. Hier wäre mehr Mitarbeit von den anderen Mitgliedern der Open-Stack-Familie wünschenswert. Murano bedeutet also einen großen Schritt in die richtige Richtung. Es stellt die Verbindung zwischen Anwendung und Infrastruktur auf bequeme Weise her.