Heutzutage entwickelte Anwendungen können als WAR oder EAR- Archiv gepackt werden und laufen in Containern die von Web- oder Anwendungsservern bereitgestellt werden. Bekannte Vertreter solcher Server sind z.B. Tomcat, JBoss oder WebSphere und einige mehr. Neben einer Laufzeitumgebung , die es der Applikation ermöglicht über http mit einem Client (i.e. einem Browser) zu kommunizieren, bieten solche Server meist deutlich mehr. Features wie Sicherheitsmanagement, Transaktionsmanagement, Skalierung und Lastausgleich stehen zur Verfügung und können konfiguriert werden. In einem solchen Szenario werden die Aufgaben zwischen einem Entwicklungsteam – das die eigentliche Anwendung erstellt – und einem Administrationsteam aufgeteilt. Das Administrationsteam kümmert sich um die Lauffähigkeit auf dem Server, die Konfiguration der Anwendungsumgebung und spielt neue Patches ein. Die Entwicklung in diesem Bereich steht aber nicht still. Ein moderner Ansatz lagert den administrativen Teil mehr und mehr aus. Das wird immer beliebter … und hier kommt das Hosting in der Cloud ins Spiel!
Ein Vertreter dieser Cloud-Anwendungsplattformen ist Heroku. In diesem Artikel werfen wir einen Blick darauf, ob und wie es Heroku gelingt, die Anforderungen an eine solche Plattform zu erfüllen.
Was bringt Anwendungsentwicklung in der Cloud
Cloud-Anwendungsentwicklung verspricht unter anderem Folgendes:
- Der Entwickler kann sich voll auf die Logik und den Inhalt der eigentlichen Anwendung konzentrieren. Serverkonfiguration oder andere Voraussetzungen für die optimale Lauffähigkeit werden über die Cloud geregelt.
- Cloud Applikationsentwicklung verringert die Kosten für Bereitstellung und Betrieb der Anwendung. Man stellt zusammen was man braucht und bezahlt nur für das was man auch verwendet.
Dies sind nur einige wenige, aber wichtige Faktoren, die die Cloud Anwendungsentwicklung verspricht um so die alltäglichen Schmerzen während eines Anwendungs-/Entwicklungszyklus zu lindern. Wie Heroku dies löst und was Sie beachten sollten, wenn Sie eine Anwendung auf Heroku entwickeln oder nach Heroku migrieren, möchten wir in diesem und weiteren Artikeln erläutern.
Erste Frage: Wie funktioniert Heroku eigentlich?
Heroku ist eine polyglotte Plattform die zu den Vertretern der PaaS (Platform as a Service) zählt. Für die einzusetzende Anwendung bietet die Heroku-Plattform eine Kombination aus den Ressourcen des zugrunde liegenden Betriebssystems, einer Laufzeitumgebung (je nach Anwendungssprache) und weitere unterstützende Software in Form von Add-Ons.
Heroku bietet die Möglichkeit Anwendungen in verschiedenen Sprachen wie z.B. Ruby, Node.js, Java, Python, Scala, Go und PHP in die Cloud zu deployen, sie dort laufen zu lassen und zu administrieren.
Sprachübergreifend definiert sich eine Heroku Anwendung als eine Sammlung von Quellcode, Ressourcedateien und Build-Skripten für entsprechende Build-Systeme (z.B. Maven für Java).
Die Möglichkeiten, die in Heroku verwendet werden, um Abhängigkeiten aufzulösen und benötigte Libraries etc. der Anwendung zuzufügen sind im Normalfall Standardansätze und nicht Heroku-spezifisch. Ruby benutzt Gemfile, Python eine requirements.txt, in Node.js eine package.json, in Java eine pom.xml.
Was benötigt Heroku um eine Anwendung zum Laufen zu bringen:
- Den Quellcode der Anwendung
- Je nach verwendeter Sprache ein Dependency File, um die Abhängigkeiten aufzulösen (siehe vorheriger Abschnitt)
- Eine Datei in der definiert wird, welche Teile der Anwendungen ausführbar sind (Procfile)
Das sollte im Normalfall schon reichen um die Anwendung zu entwickeln, deployen und zu betreiben.
Was ist ein Procfile?
Für ein besseres Verständnis macht es Sinn, sich die Procfiles genauer anzuschauen. Über das Procfile bestimmt Heroku die ausführbaren Teile der Anwendung, wo diese liegen und von welcher Art sie sind. Beispiel eines Procfile:
web: java $JAVA_OPTS -Dspring.profiles.active=prod -jar target/dependency/webapp-runner.jar --port $PORT target/*.war
Dieses Procfile ist Teil unseres „Splash“ Heroku buttons, verfügbar im zugehörigen Github repo.
Das wichtigste, was durch dieses Procfile ausgedrückt wird: Das ausführbare jar „webapp-runner“ wird benutzt, um einen Tomcat Server zu starten. Die Webapplikation aus dem Verzeichnis target mit Endung .war soll auf diesem Tomcat Server deployed werden.
Damit das in Heroku funktioniert, muss die Datei auch exakt als „Procfile“ benannt werden und im Root Verzeichnis der Applikation abgelegt werden:
Applikationen auf Heroku deployen
Damit eine Anwendung in Heroku läuft muss diese zunächst einmal nach Heroku übertragen werden. Möglichkeiten sind hier Git, GitHub, Dropbox oder eine spezielle API. Die Heroku Plattform benutzt Git als primäres Tool, um Applikationen zu deployen.
Erstellen von Anwendungen
Nachdem Heroku den Quellcode der Applikation erhalten hat, wird dessen Build initiiert. Umgesetzt wird dies über einen Github Webhook, der nach einem neuen push auf den Heroku Remote Master Branch der Applikation greift. Zum eigentlichen Build verwendet Heroku so genannte Buildpacks. Für die unterstützten Sprachen gibt es in Heroku eine ganze Reihe von Standard Buildpacks welche automatisch je nach Applikationstyp ausgeführt werden. Mit Hilfe dieser Buildpacks wird die Applikation zu einen sogenannten „Slug“ kompiliert und gepackt.
Heroku Innenleben
Was ist eigentlich ein Slug? Bevor wir diese Frage beantworten, erst ein paar weitere Basics über das Innenleben von Heroku:
Die Heroku Cloud-Entwicklungsplattform bietet eine Grundlage für die Entwicklung, Bereitstellung und Fehlerbehebung Cloud-basierter Anwendungen und besteht aus folgenden Komponenten:
- Der Platform Stack: Bietet Core Komponenten wie das Betriebssystem (aktuell Linux Ubuntu 14.x), die Laufzeitumgebung (z.B. Node.js, Ruby, Java, PHP), und unterstützende Bibliotheken.
- Einen Routingmechanismus für Requests: Eingehende Requests werden angenommen und zuverlässig an den entsprechenden Prozess der Anwendung weitergeleitet.
- Die Laufzeitumgebung: Notwendige Laufzeitunterstützung um die Applikation auszuführen.
- Das Logplex Logging Framework: Ein eventbasiertes Logginsystem um Applikationsevents aus den verschiedenen Prozessen zusammen zu führen.
- The Add-on Ecosystem: Dieses bietet die Möglichkeit, Dienste von Drittanbietern an die Applikation anzubinden. Beispiele hierzu sind Performance Monitoring, Caching oder Datenspeicherung.
- Die Heroku Plattform APIs: Hierbei handelt es sich um ein Webservice Interface, das es ermöglicht Heroku Funktionen aus der Applikation heraus aufzurufen.
… über Dynos und Slugs
Wer seine Anwendung auf Heroku deployen will sollte sich zudem mit dem Konzept der so genannten Dynos vertraut machen. Ein Dyno ist ein leichtgewichtiger Unix Container, der jede Art von Prozess laufen lassen kann, den die Ausführungsumgebung bereitstellt. Diese Ausführungsumgebung für Prozesse – in Heroku Dyno-Manifold gennant – ermöglicht die Ausführung verschiedener Dyno-Typen. Die wohl am meisten verwendeten sind dabei die so genannten Web Dynos. Was im Procfile als web Prozess definiert ist, wird über einen Web Dyno zur Ausführung gebracht. Webdynos nehmen (über die Heroku Router weitergeleiteten) eingehenden Requests an und schicken entsprechende Responses zurück.
Nachdem etwas genaueren Blick auf die Dynos zurück zur Frage „Was ist ein Slug?“ Der Slug Compiler erstellt aus dem zugrunde liegenden Quellcode etwas Ausführbares, indem er die eigentliche Anwendung baut, notwendige Binaries verlinkt und alles für ein schnelles Deployment komprimiert. Das finale Produkt aus dem Slug Compiler ist das, was von Heroku dann Slug genannt wird.
Nochmal zusammengefasst: Slugs sind komprimierte Kopien der eigentlichen Anwendung, optimiert für eine schnelle Verteilung auf den/die entsprechenden Dyno(s).
Zu einer erfolgreichen Anwendung gehört aber noch mehr als den Code zu schreiben und die Anwendung zum Laufen zu bekommen. Skalierung und Wartung sind weitere wichtige Aspekte.
Auch hier ist Heroku auf der Höhe der Zeit. Für eine horizontale Skalierung wird einfach die Anzahl der Dynos angepasst(z.B. wenn mehr Requests behandelt werden müssen). Zur vertikalen Skalierung kann die Performanz der Dynos angepasst werden (z.B. wenn mehr CPU Power benötigt wird).
P.S.: Wir haben Beispielcode von unserem SPLASH Heroku Button verwendet. Mehr dazu auf unserer GitHub Page https://github.com/logiclinegmbh/splash. Das ist ein Architekturmuster für Web Apps mit Java, Spring, Hibernate und AngularJS auf einem einzelnen Dyno auf Heroku.
Mehr Informationen zu Heroku gibt’s direkt auf der Heroku-Homepage: https://www.heroku.com
