Amazons Elastic Beanstalk, ein erster Praxistest

Inhaltsverzeichnis

Durch den neuen Cloud-Service Elastic Beanstalk ist Amazon in den Kreis der "Platform as a Service"-Anbieter (Paas) wie Google und Salesforce.com gerückt. heise Developer hat das neue Angebot einem ersten Entwicklertest unterzogen.

Mitte Januar stellte Amazon mit Elastic Beanstalk seine "Java-Cloud" vor. Das "Platform as a Service"-Angebot (PaaS) basiert auf Amazons etablierter Web-Services-Infrastruktur (EC2, Elastic Load Balancing und anderen AWS-Diensten) und hat besonders Entwickler von Java-Webanwendungen zur Zielgruppe. Als Servlet-Container setzt Amazon den beliebten Tomcat der Apache Software Foundation ein. Die Nutzung des Dienstes ist einfach: Der Entwickler installiert ein normales Web Application Archive (WAR-Java-Datei) in der Cloud, und Amazon regelt den Rest, etwa das Bereitstellen der AWS-Infrastruktur.

Loslegen und gut?

Zum Starten benötigt man eine (einfache) Webanwendung. Als Beispiel dient eine zeitgemäße Enterprise-Java-Anwendung (Java EE 6), die neben JavaServer Faces 2.0 (Apache MyFaces) auch Java Persistence API (Apache OpenJPA), Contexts and Dependency Injection (CDI; Apache OpenWebBeans) und CDI-Erweiterungen (MyFaces CoDI) enthält.

Die Anwendung wurde bereits vorher innerhalb des Tomcat (Version 6 und 7) installiert. Einem Deployment auf der Beanstalk-Plattform sollte damit nichts mehr im Weg stehen. Der Quelltext des Beispiels lässt sich einfach mit Git aus dem Github-Repository beziehen. Anschließend wird die WAR-Datei mit Apache Maven (mvn clean install) gebaut.

Nach dem erfolgreicher Registrieren (und Validieren) von Beanstalk kann man per Login auf die "AWS Management Console" zugreifen. Sie stellt einen zentralen Einstiegspunkt auf Amazon-Dienste wie Elastic MapReduce, EC2 oder auch Elastic Beanstalk (siehe Abb. 1) dar. Für das erste Deployment des Beispiels ist die Option "Upload your own application" zu wählen.

Im zweiten Schritt wird der Name der Anwendung vergeben. Da er Einfluss auf die URL hat, sollte der Anwender vorher die Verfügbarkeit der gewünschten Domain beziehungsweise des Namens überprüfen. Neben einer optionalen Beschreibung der Anwendung kann er bestimmen, ob man ein 32- oder 64-bit-Linux als Host für den Tomcat möchte. Abschließend wählt man die gewünschte WAR-Datei aus.

Nach dem erfolgreichen Upload der Datei greift der Automatismus der Amazon-Cloud: Ressourcen wie EC2 oder Auto Scaling werden für die neue Anwendung konfiguriert (siehe Abb. 3a). Sobald sämtliche Dienste verfügbar sind, hat der Betreiber Zugriff auf Monitoring-Funktionen, oder er kann Events der Anwendung in der AWS Management Console einsehen. Die Event-Übersicht bietet eine Filterfunktion, falls das Anzeigen sämtlicher Ereignisse nicht gewünscht ist (siehe Abb. 3b).

So gelungen die Beanstalk-Oberfläche erscheint, der spannende Augenblick jedoch ist der, wenn der Cluster endlich zur Verfügung steht und die Anwendung benutzt werden kann. Die zuvor installierte Anwendung lässt sich über das Muster http://anwendungs-name.elasticbeanstalk.com/ aufrufen (siehe Abb. 4).

Wenn im Laufe der Zeit die Anforderungen an die Software wachsen und neue Funktionen realisiert werden, geht die Aktualisierung der Anwendung innerhalb der "Tomcat-Cloud" einfach vonstatten. Ein Klick auf den "Upload New Version"-Button genügt, und prompt öffnet sich ein Wizard zum Hochladen der neuen Version (siehe Abb. 5).

Nicht nur die gehostete Applikation lässt sich bearbeiten, sondern auch die Konfiguration der Beanstalk-Umgebung. Die Abbildung 6 zeigt einen Dialog, in dem man beispielsweise die Heap Size der Java Virtual Machine (JVM) verändern könnte.

Wird niemand mehr die Anwendung mehr, kann der Betreiber sie löschen (Abb. 7). Dabei werden die aktuelle Umgebung terminiert und die Anwendung gelöscht. Die zuvor hochgeladenen Versionen jedoch nicht, sie bleiben innerhalb von Amazons Simple Storage Service (S3) gespeichert.