Micro-Cloud mit Cloud Foundry

Einer der Plattformdienste

Phillip Ghadir, Oliver Wolf

Bereits in [1] haben wir mit Red Hat OpenShift Express einen Plattformdienst für Java-Anwendungen vorgestellt. Nun, ein Jahr später, haben wir mit Cloud Foundry ein anderes Angebot herausgepickt und stellen vor, warum es sich lohnt, auch dieses anzuschauen.

Cloud Foundry unterstützt die auf der JVM aufsetzenden Frameworks Spring, Scala, Play und Grails sowie auch Node.js und Ruby, Rails- und Sinatra- Applikationen. Die Applikationen können innerhalb der Cloud Foundry auf Services wie MongoDB, MySQL, RabbitMQ, Redis und vFabric Postgres zugreifen, die von der Plattform bei entsprechender Konfiguration automatisch bereitgestellt werden.

Die Cloud auf dem eigenen Rechner

Cloud Foundry bietet neben der Cloud im Internet eine sogenannte Micro-Cloud an, die in einer VMware VM auf dem eigenen Rechner betrieben wird. Für Windows und Linux-Anwender genügt ein kostenfrei verfügbarer VMware Player. Mac-Anwender hingegen müssen für den dauerhaften Einsatz eine kostenpflichtige Lizenz für VMware Fusion erwerben.

Wer also einen leistungsfähigen Entwicklungsrechner besitzt, kann auch ohne ständigen Netzzugang auf der Cloud-Foundry-Plattform entwickeln. Nachdem die circa 1,5 GB umfassende Micro-Cloud-VM heruntergeladen ist, kann’s losgehen.

Entwicklungsumgebung

Freunde grafischer IDEs können die Cloud Foundry Integration Extension mit der Spring Tool Suite oder direkt mit Eclipse verwenden. Darüber hinaus unterstützt die aktuelle Version von Intellij IDEA 12 in der Ultimate- Edition ebenfalls Cloud Foundry. Die Plattform lässt sich aber auch über die Kommandozeile mit dem Werkzeug vmc steuern. Dies ist der in diesem Artikel verwendete Weg.

Sind in der lokalen Entwicklungsumgebung die Werkzeuge für den Einsatz von Cloud Foundry installiert, kann die lokale Umgebung mittels

vmc target <cloud-instance-url>

mit einer Cloud-Instanz verbunden werden, in die dann im Folgenden die Software deployt werden soll.

Die Entwicklung erfolgt in der gewohnten lokalen Umgebung. Der Entwicklungszyklus muss sich dabei in keiner Weise von der sonstigen Entwicklung unterscheiden. Nach dem Bauen der Software schiebt man sie mit dem Werkzeug vmc einfach in die Cloud. Je nach lokaler Konfiguration kann das lokal oder remote erfolgen.

Der Kasten „Aufsetzen der Micro-Cloud in der VM“ skizziert grob, wie Cloud Foundry in der Entwicklungsumgebung aufgesetzt wird. Beim Deployment in einer frisch aufgesetzten Umgebung wird deutlich, dass die Cloud mehr bietet, als eine einfache Virtuelle Maschine mit Server-Betriebssystem. Abbildung 1 stellt die ersten Entwicklungsschritte dar. Wird mit

vmc push <deployment-unit>

ein Softwarestand in die Cloud geschoben, erkennt Cloud Foundry mittels Introspektion, von welchem Technologie-Stack die Software abhängt. Für die erkannten Abhängigkeiten erfragt vmc push relevante Konfigurationsparameter und stellt die passende Umgebung bereit, um unsere Software darin zu deployen.

Weitere Informationen zum Thema: Aufsetzen der Micro-Cloud in der VM

Erste Schritte

Wir verwenden für den Einstieg ein mit Play 2 realisiertes Beispiel [2], um die Arbeit mit Cloud Foundry zu demonstrieren. Die kleine Todo- Listen-Anwendung speichert die Todos in MongoDB. Das Technologie-Beispiel ist neben verschiedenen anderen explizit dazu gedacht, die ersten Schritte mit der Cloud zu erleichtern.

Voraussetzung für die folgenden Schritte ist eine installierte Version des Play 2-Frameworks. Zunächst erzeugen wir uns mit

git clone https://github.com/cloudfoundry-samples/todolist-play-java-mongodb.git

eine lokale Kopie des Git-Repositories, in dem der Quellcode der Beispiel- Anwendung liegt. Nun müssen wir die Konfigurationsdatei (app/application.conf) für das Deployment in die Cloud anpassen: Da die Verbindungsparameter der MongoDB in der Cloud erst von der Cloud Foundry vergeben werden, müssen wir Platzhalter eintragen, die beim Deployment automatisch durch die korrekten Werte ersetzt werden. Folgende Platzhalter stehen hier zur Verfügung:

mongo.dbname=${?cloud.services.mongodb.connection.db}
mongo.remote.hostname=${?cloud.services.mongodb.connection.hostname}
mongo.remote.port=${?cloud.services.mongodb.connection.port}
mongo.remote.username=${?cloud.services.mongodb.connection.username}
mongo.remote.password=${?cloud.services.mongodb.connection.password}

Nun können wir unsere Anwendung mit „play dist“ bauen und paketieren. Mit einem anschließenden

vmc push --path=dist/todolist-java-mongodb-1.0-SNAPSHOT.zip

starten wir den Deployment-Vorgang, bei dem noch eine Reihe von Parametern abgefragt werden. Als Erstes müssen wir einen Namen für die Anwendung wählen, z.B. „todolist“. Dieser Name dient dazu, bei Aktionen mit dem „vmc“-Werkzeug die Anwendung zu identifizieren (z.B. zum Starten, Stoppen, Löschen usw.). Bei der Wahl des Namens verzichtet man am Besten auf die Verwendung von Punkten („.“).

Im nächsten Schritt erkennt vmc korrekt, dass es sich um eine Play-Anwendung handelt, sodass wir die Frage mit „Y“ beantworten können.

Nun können wir die URL bestimmen, unter der die Anwendung erreichbar sein soll. Als Default wird die URL aus dem Namen der Anwendung und dem Domainnamen unserer MCF (Micro Cloud Foundry) gebildet. So lange wir auf die MCF deployen, sind wir in der Namenswahl frei. Später in der „großen“ Cloud kann es durchaus zu Namenskollisionen mit anderen Anwendern kommen, sodass wir hier den Default unter Umständen ändern müssen.

Anschließend wird die Speicherkonfiguration abgefragt. Der vorgegebene Wert wird automatisch anhand der Art der Anwendung (Programmiersprache, Framework usw.) ermittelt und passt in unserem Fall. Auch die folgende Frage nach der Anzahl der Instanzen beantworten wir mit der vorgegebenen Antwort „1“.

Das Bildschirmfoto in Abbildung 3 zeigt die interaktiven Fragen des vmc- Aufrufs. Insgesamt dauert das Deployment nach dem Beantworten aller Fragen für die kleine Play-Anwendung nur wenige Sekunden auf einem aktuellen Notebook.

Abbildung 4 zeigt das zufrieden stellende Ergebnis des kleinen Exkurses. Nach der Konfiguration der Umgebung, dem Auschecken der Quellen, dem Bauen der Anwendung und dem Hochladen in die Cloud steht die Anwendung unter der beim Deployment angezeigten URL zur Verfügung.

Sollte anstatt der Todo-Listen-Anwendung eine Fehlermeldung oder Exception zu sehen sein, hilft vielleicht ein Blick in die Log-Datei. Mit dem Kommando

vmc logs todolist

lässt sich diese einsehen. Beendet wird die Anwendung mit

vmc stop todolist

und mit

vmc delete todolist

kann sie wieder komplett von der MCF entfernt werden.

Soll das Deployment anstatt in die lokale MCF in die „große“ Cloud Foundry im Internet erfolgen, sind die Schritte identisch. Lediglich die Zielumgebung muss mit

vmc target api.cloudfoundry.com

umgeschaltet werden.

Abbildung 3: Der Screenshot zeigt die Fragen beim Deployment in die Cloud
Abbildung 4: Screenshot der Anwendung TodoList - live aus der MCF

Stand der Dokumentation

Derzeit beantwortet die Dokumentation viele naheliegende Fragen noch nicht. In vielen Fällen ist man auf die Suche auf StackOverflow zu Cloud Foundry angewiesen [3].

Zwar wird man teilweise recht schnell fündig, aber manche Wege hätten wir uns lieber erspart. Mit einer etwas ausgereifteren Benutzer-/Entwickler- Dokumentation hätten wir uns gleich von Anfang an an die Konventionen der Plattform gehalten und zum Beispiel Namen ohne „.“ verwendet bzw. die korrekten Schalter verwendet, um die Unterschiede zwischen der Java-Version in der Entwicklungsumgebung (Java 7) und der Cloud-Instanz (Java 6) auszugleichen.

Fazit

Cloud Foundry ist ein Angebot, das für verschiedene Frameworks eine Laufzeitumgebung bereitstellt, die lokal ähnlich wie in der Cloud laufen kann. Aufgrund der Ausrichtung erfordert Cloud Foundry eine Menge an Verständnis über die Abläufe und Zusammenhänge zwischen Build-Infrastruktur, Paketen, Konfigurationen und den Eigenheiten der in einer Cloud-Instanz bereitgestellten Infrastruktur.

Die Bereitstellung der Services erfolgt einfach und gelungen. Der Zugriff auf die Umgebung aus der eigenen Applikation heraus ist definiert, sodass hier eine dynamische Konfiguration unproblematisch bleiben sollte.

An verschiedenen Stellen sollten Konventionen eingehalten werden, die so noch nicht allgemein dokumentiert sind, sondern aus Forenbeiträgen ermittelt werden müssen. Unser subjektiver Eindruck ist, dass Cloud Foundry etwas mehr Anforderungen an die Deployment-Pakete stellt, als wir dies bislang gewohnt waren.

Naturgemäß erfordert die MCF etwas mehr Grundverständnis und bietet dafür aber sowohl einen Online- als auch einen Offline-Betrieb.

Weitere Informationen zum Thema: Services in der Cloud Foundry

Quellen, Links und Interessantes

Referenzen

  1. Ph. Ghadir, OpenShift Express, in: JavaSPEKTRUM, 1/2012  ↩

  2. auf Play 2 basierende Todo-List-Beispiel-Anwendung für Cloud Foundry, https://github.com/cloudfoundry-samples/todolist-play-java-mongodb  ↩

  3. Stack Overflow zu Cloud Foundry, http://stackoverflow.com/questions/tagged/cloudfoundry  ↩

Thumb dsc08236

Phillip Ghadir, member of innoQ’s CxO team, is a consultant and trainer with a focus on software architecture.

More content

Thumb dsc03428

Oliver Wolf is a Principal Consultant and member of the Executive Board at innoQ, a Germany-based consulting company focussing on software architecture and highly scalable internet solutions. Prior to joining innoQ, Oliver worked as a Product Manager and Lead Architect for SOPERA, an open source SOA product company that was acquired by Talend in late 2010. He holds a degree in computer science and worked in IT security consulting for a while before switching to software architecture.

More content

Java spektrum
Dieser Artikel ist ursprünglich in Ausgabe 01/2013 der Zeitschrift JavaSPEKTRUM erschienen. Die Veröffentlichung auf innoq.com erfolgt mit freundlicher Genehmigung des SIGS-Datacom-Verlags.

Comments

Please accept our cookie agreement to see full comments functionality. Read more