Eclipse Gyrex

Aufsetzen der eigenen Cloud

Nachdem das Beispiel fertig entwickelt wurde, geht es nun daran, eine eigene Cloud aufzusetzen, in der das Beispiel dann läuft. Wie bereits in der Einführung erwähnt, setzt Gyrex auf Apache ZooKeeper als zentrale Koordinierungsstelle für alle Nodes. Im Entwicklungsmodus wird von Gyrex ein lokaler ZooKeeper-Server mitgestartet. Dadurch ist das System sofort einsatzbereit. Im Produktivbetrieb sollte aber unbedingt ein eigenständiger Apache-ZooKeeper-Cluster aufgesetzt werden. Da das Aufsetzen allerdings den Rahmen des Artikels sprengen würde, wurde hier für den Zweck der Demonstration die Ein-Server-Variante gewählt, die als Standalone-Operation im Getting Started Guide der ZooKeeper-Dokumentation [17] beschrieben wird.

Zum Einrichten der Gyrex Nodes kommt das fertige Serverpaket zum Einsatz, das auf der Webseite von Gyrex als Download zu finden ist. Es gibt es als Paket für Windows, Linux und Mac OS und enthält alle notwendigen Komponenten für den Betrieb in einer Produktivumgebung inklusive der Administrationsoberfläche und der Softwareverteilung auf Basis von p2. Um unser Beispiel im Server zu deployen, müssen wir es lediglich als p2 Repository verfügbar machen. Das geht komfortabel mit dem Export Wizard in Eclipse (FILE | EXPORT | DEPLOYABLE FEATURES) oder mit einer der Build-Technologien (PDE Build, Tycho oder Buckminster). Um einen Gyrex Node einzurichten, muss dieser zunächst mit dem ZooKeeper-Server registriert werden. Anschließend wird der Node durch ein einfaches Tagging mit Aufgaben versehen. Das geht per OSGi-Konsole oder per Administrationsoberfläche (Abb. 5). Auch eine Automatisierung (beispielsweise bei Amazon-EC2-Abbildern oder mittels Konfigurationswerkzeugen wie BCFG2 oder Puppet) ist möglich, sodass bei Bedarf weitere Nodes in die Cloud gebracht werden können, die sich dann automatisch die notwendigen Plug-ins und Features aus dem p2 Repository installieren.

Abb. 5: Einrichten von Gyrex Nodes

Wenn die Nodes soweit eingerichtet sind und laufen, kann das Beispiel installiert werden. Dazu wird zunächst das p2 Repository aufgesetzt. Da p2 mit URLs arbeitet, empfiehlt es sich, das Repository auf einen Webserver zu legen, der von allen Nodes erreichbar ist. Alternativ könnte auch ein Shared-Filesystem genutzt werden, das auf allen Nodes zur Verfügung steht. Nachdem das p2 Repository konfiguriert ist, kann das Softwarepaket eingerichtet werden. Ein Softwarepaket ist ein Konzept in Gyrex, das eine Gruppe von Features und/oder Plug-ins zusammenfasst. Dabei kann eine feste Version oder ein Versionsbereich angegeben werden, sodass verfügbare Updates bei Bedarf ausgerollt werden. Nachdem das Softwarepaket eingerichtet ist, muss es explizit zum „Roll-out“ freigegeben werden. Erst danach erfolgt die Installation auf den einzelnen Nodes (Abb. 6). Der Installationsprozess erfolgt geordnet und kontrolliert, das heißt es wird immer nur ein Node bearbeitet. Erst wenn die Installation/Aktualisierung erfolgreich abgeschlossen wurde, geht es mit dem nächsten Node weiter. So soll vermieden werden, dass ein fehlerhaftes Paket alle Nodes lahmlegt. Nachdem das Paket auf allen Nodes installiert wurde, ist unser Beispiel-Servlet auf den Webserver-Nodes abrufbar. Der Hintergrundprozess läuft auf den Worker-Servern. Er kann auf jedem beliebigen Node geplant und gestartet werden, wird aber nur durch die Worker-Server abgearbeitet. Bei Engpässen können so weitere Worker Nodes in die Cloud eingebunden werden.

Abb. 6: Softwareverteilung mittels p2
Fazit

Gyrex ist eine Plattform, die es ermöglicht, Eclipse-Runtime-Technologien für die Cloud betriebsfähig zu machen. Wem Eclipse-Konzepte und -Technologien vertraut sind und wer diese gerne nutzt, dem bietet Gyrex eine ideale Ausgangsbasis für eine eigene Eclipse AppEngine. Von der kleinen Versionsnummer sollte man sich nicht täuschen lassen. Gyrex wird bereits heute produktiv auch in großen Projekten eingesetzt. Die größte Herausforderung für das Projekt liegt daher auch im Aufbau einer vielfältigen Nutzer- und Entwicklergemeinschaft. Zwar ist das Projekt über alle Eclipse-Kommunikationskanäle erreichbar, aber die Zielgruppe weicht doch deutlich von der typischen Eclipse-Plug-in-Entwicklerbasis ab, da primär Entwickler angesprochen werden sollen, die serverbasierte Anwendungen erstellen.

Gunnar Wagenknecht ist Softwareentwickler und bei AGETO verantwortlich für alle Themen rund um Technology und Architektur. Er ist Leiter des Eclipse Technology PMC und seit über zehn Jahren in der Eclipse-Community aktiv.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.