Open Source PaaS

In dieser Blogserie geht es um Platform as a Service (PaaS). Was das ist, und warum eine solche Plattform Entwicklung und Betrieb effizienter macht, wurde im ersten Blogpost diskutiert. Im zweiten Blogpost wurden dann Kriterien vorgestellt, nach denen verschiedene in Frage kommende PaaS verglichen werden können. Dabei hat sich herausgestellt, dass Open Source Lösungen wichtige Vorteile gegenüber proprietären Angeboten haben. Allerdings gibt es nur zwei weitverbreitete Open Source PaaS. Diese möchte ich in diesem Artikel vorstellen, bevor ich im nächsten Artikel auf proprietäre Technologien eingehen werde.

Cloud Foundry

Ich persönlich habe die meisten Erfahrungen mit Cloud Foundry gemacht. Cloud Foundry ist eine Open Source Plattform, welche von der Cloud Foundry Foundation getrieben wird. Diese hat Mitglieder, bestehend aus fast allen relevanten Technologiefirmen, unter anderem  Dell, IBM, SAP, VMWare, Microsoft oder Google. Mit der Swisscom ist auch ein Schweizer Unternehmen als “Gold” Partner involviert. Genau diese Vernetzung von Firmen macht diese Technologie zu der verbreitetsten, da viele dieser Firmen ein eigenes Cloudangebot haben. Ob man seine Applikationen auf IBM Bluemix, Pivotal Webservices, dem Swisscom Developer Portal oder auf der Plattform von anynines laufen lässt – dahinter läuft immer Cloud Foundry.

Die Architektur von Cloud Foundry ist komplex. Hier ein paar abstrakte Merkmale:

  • Cloud Foundry besteht aus unzähligen Komponenten, welche jeweils auf einer oder mehreren virtuellen Maschinen (VMs) laufen. Um diese Komponenten auf VMs auszurollen, automatisch skalieren und bei Ausfällen wiederherstellen zu können, verwendet Cloud Foundry BOSH. BOSH bietet eine Abstraktion zu allen gängigen Virtualisierungs-Layern wie AWS, VMWare oder OpenStack an.
  • Cloud Foundry kann über mehrere Availability Zones hinweg installiert werden. Alle wichtigen Komponenten laufen in mehreren Zonen, so dass beim Ausfall einer Zone die Plattform noch funktioniert.
  • Das “klassische” Cloud Foundry läuft mit der Application Runtime, was einer klassischen PaaS gemäss der oben beschriebenen Definition entspricht. Mittlerweile lassen sich zwar auch Docker Container in der Runtime deployen, und es gibt sogar eine Container Runtime, welche auf Kubernetes basiert, wir fokussieren uns in diesem Artikel aber auf das klassische PaaS.
  • Der Service Marktplatz erlaubt es, per Mausklick eine Instanz eines Datenservices anzulegen, welche an Applikationen “gebunden” werden kann. Diese Applikationen bekommen automatisch Umgebungsvariablen zur Verfügung gestellt, mit welchen sie sich zum Beispiel mit dem Service verbinden können.

Datenbankanbindung mit Cloud Foundry
Applikationen, die an eine Instanz eines Datenservices gebunden werden, bekommen Umgebungsvariablen mit Verbindungsdetails zum Service zur Verfügung gestellt.

Cloud Foundry bietet eine Unterteilung in Organisationen und Spaces an, so dass Entwicklerteams dediziert in isolierten Bereichen der Plattform arbeiten können. Um meine Testapp in einen Space deployen zu können, sind folgende Kommandos nötig:

  1. Login mit Angabe des APIs, Benutzername und Passwort.
  2. “Pushen” der App, wobei das vorgenerierte JAR referenziert wird.
  3. Es wird je einmal eine MongoDB, RabbitMQ und MariaDB Instanz erstellt.
  4. Die drei erstellten Instanzen werden je an die erstellte App gebunden.
  5. Die App wird neu gestartet, so dass Spring beim Starten die Variablen von den Serviceinstanzen findet und zu diesen verbinden kann.

Damit habe ich in fünf Minuten eine neue Applikation live gestellt und diese mit diversen Services verbunden!

Swisscom Developer Portal
So sieht mein Dashboard auf der Swisscom Cloud Foundry Plattform aus, nachdem ich die oben genannten Schritte in der “Silberrücken” Organisation und im “Blogpost” Space ausgeführt habe.

OpenShift

OpenShift ist die Open Source Plattform von Red Hat und basiert auf Kubernetes. Neben der public Cloud von Red Hat selber gibt es auch andere Dienste, ich kenne allerdings nur die Schweizer Plattform APPUiO.

OpenShift bietet zwei Deployment Möglichkeiten an:

  • Source-to-image: Der Source Code wird von einem Git Repository bezogen und in einem Build wird daraus ein Container Image generiert. Wie das Image mit welcher Laufzeitumgebung generiert wird, kann in der Plattform vordefiniert werden.
  • Dockerfile: Ein Dockerfile ist eine Definition, wie ein Docker Image erstellt werden muss. Bei dieser Variante verwalten die Entwickler die benötigten Dockerfiles und können so komplett beliebig steuern, wie die finalen Images aussehen werden. Dies entspricht also weniger unserer Definition von PaaS und wird deshalb nicht weiter diskutiert.

Die einzelnen Instanzen einer Applikation sind über einen Service ansprechbar, was einer fixen URI entspricht, über welche Requests auf veränderbare Instanzen verteilt werden. Applikationen und Builds werden in Projekten organisiert. Datenservices werden oft ausserhalb der Plattform betrieben, die Variablen zur Anbindung an eine Serviceinstanz werden dann zentral im Projekt abgelegt, so dass Applikationen diese verwenden können, ohne die Service Konfiguration selber verwalten zu müssen.

Datenbankanbindung in Openshift
Die Konfiguration zum Verbinden eines externen Services wie eine Datenbank kann in einer ConfigMap gespeichert werden, welche von Applikationen eingelesen werden kann, die zu dem Service eine Verbindung herstellen müssen.

Um die Testapplikation in einem Projekt zu installieren, sind folgende Kommandos nötig:

  1. Login mit Angabe der API, Benutzername und Passwort.
  2. Ein neuer Build wird erstellt, welcher das OpenJDK Build Image und unser Git Repository verwendet. Damit die Plattform auf das Git Repository zugreifen kann, wird ein vorgängig erstellter SSH Key mitgegeben.
  3. Eine neue App wird erstellt, welche auf dem durch den Build generierte Image basiert.
  4. Die App wird geöffnet (“expose”), so dass sie von aussen her erreichbar ist.
  5. Es wird eine neue App basierend auf dem openshift-rabbitmq Docker Image erstellt.
  6. Je eine App wird aus dem MongoDB und dem mySQL Template erstellt.
  7. Die Deployment Konfiguration wird manuell so angepasst, dass die Verbindungsvariablen den erstellten Services entsprechen.

OpenShift Web KonsoleDie vier resultierenden Deployments im “blogpost” Projekt.

Bei Schritt 5-6 ist zu beachten, dass das Erstellen von Datenservices innerhalb OpenShift nur für Testumgebungen empfohlen ist. Für die Entwicklung ist es praktischer, Services von ausserhalb zu beziehen, wo sie optimal betrieben werden können.

Ausblick

Im nächsten Beitrag werde ich die Google App Engine und Heroku vorstellen, beides proprietäre Technologien, welche aber ebenso auf Open Source aufbauen. Im letzten Beitrag werde ich dann sämtliche vorgestellten Technologien vergleichen und zeigen, welche Technologie in welchen Anwendungsfällen am meisten Sinn macht.

Haben Sie Fragen zu diesem Thema oder brauchen Sie Unterstützung bei der Einführung von PaaS, können Sie sich gerne bei mir melden.

Kommentar verfassen