Platform as a Service als eine unternehmensweite Dienstleistung

Flexible Unternehmens-IT

Marco Metzen
© Shutterstock/Creativa Images

„Zeit ist Geld“: Das wusste bereits Benjamin Franklin im Jahr 1748 und es gilt auch heute noch. Kürzere Produktentwicklungszyklen und immer schnellere Änderungen der Zielmärkte setzen Unternehmen unter ständig wachsenden Druck. Neue Funktionalitäten müssen in kürzester Zeit dem Endkunden zur Verfügung gestellt werden. Die Unternehmens-IT ist gezwungen, darauf zu reagieren und einen Wandel zu vollziehen, der diese wachsende Geschwindigkeit auf allen Ebenen unterstützt und Infrastruktur als Dienstleistung anbietet.

Derzeitige Unternehmensorganisationen verhindern meist die notwendige Geschwindigkeit bei der Entwicklung von Software. Jeder Bereich arbeitet in einer Art Silo, Zusammenarbeit ist geprägt durch gewachsene, vielleicht auch unnötig komplizierte Prozesse. Jedoch hat jedes Unternehmen das Ziel, Funktionalitäten schneller an den Markt zu bringen, Qualität und Wartbarkeit zu steigern und Feedback der Kunden möglichst sofort umzusetzen. Dazu ist ein Wandel in der Organisation notwendig, der die unterschiedlichen Unternehmensbereiche zum Zusammenrücken und zum Aufbrechen der Silos zwingt. Ein Trend unserer Zeit ist DevOps, der Entwicklung und Betrieb zusammenbringt und so Reibungsverluste minimiert oder sogar aufhebt.

Den ersten Schritt haben bereits einige IT-Bereiche in Unternehmen vollzogen und bieten Infrastructure as a Service (IaaS) an. Hardware muss nicht extra über einen langwierigen Prozess bestellt werden, sondern das Entwicklungsteam klickt sich seine Wunschkonfiguration zusammen oder wählt aus bereits vorab definierten Konfigurationen aus. Kurze Zeit später steht das System bereits zur Verfügung und das Entwicklungsteam kann mit der Konfiguration der Laufzeitumgebung loslegen. Im besten Fall erfolgt dieser Schritt auch über automatische Provisionierung mithilfe der gängigen Tools wie z. B. Puppet. Was vorher Tage oder gar Wochen in Anspruch genommen hat, kann nun innerhalb von Minuten erledigt werden. Platform as a Service ist die konsequente Weiterentwicklung dieses Konzepts unter Nutzung bereits etablierter IaaS-Dienste. Statt virtueller Hardware, Betriebssystem und Laufzeitumgebung wählt das Entwicklerteam nur noch die Laufzeitumgebung aus und kann loslegen. In der Regel erlaubt dies keinen direkten Zugriff auf das Betriebssystem, sondern die PaaS wird entweder über eine Oberfläche oder per API angesprochen. Das freut jeden Administrator, ist er doch weiter Herr über die Systeme.

Abbildung 1 zeigt die Verantwortlichkeiten in den verschiedenen Ebenen. Die IaaS wird durch den IT-Bereich zur Verfügung gestellt. Dieser kümmert sich um den Speicherplatz, die notwendige Hardware zum Betrieb der PaaS und ggfs. um eine Virtualisierungslösung. Der Entwickler bzw. das Entwicklerteam hat die volle Kontrolle über die Applikation und deren Laufzeitumgebung. Dazwischen arbeitet unsere PaaS-Lösung, die auf Ebene des Betriebssystems und der zur Verfügung stehenden Laufzeitumgebungen als Orchestrierungsschicht zwischen Betrieb und Entwickler dient.

Abb. 1: Übersicht Infrastrukturkomponenten und deren Verantwortliche

RedHat OpenShift ist die Grundlage zum Betrieb einer PaaS

Im Mai 2011 als Developer-Preview und Cloud-Lösung gestartet, hat OpenShift nun schon mehrere Jahre Entwicklungszeit hinter sich. Etwas über ein Jahr später startete auch schon die On-Premise-Lösung OpenShift Enterprise zum Betrieb einer PaaS auf eigener Infrastruktur. Erst kürzlich wurde von RedHat die Version 2.1, die weitere nützliche Funktionen für den Betrieb in einer Unternehmenslandschaft enthält, veröffentlicht.
Abbildung 2 zeigt eine Übersicht der beteiligten Komponenten beim Einsatz von OpenShift. Der Broker ist dabei das Gehirn unserer Plattform. Er hält im Datenspeicher die Metadaten zu allen Applikationen bereit, authentifiziert die Entwickler und sorgt für das Auffinden unserer bereitgestellten Applikation. Neben der Orchestrierung der Applikationen bietet er eine Weboberfläche, sowie ein REST-API für die Verwaltung an.

Abb. 2: OpenShift-Komponenten und Kommunikation

Auf den Nodes laufen die Applikationen in Gears. Ein Gear ist der Container, in dem die Laufzeitumgebung zur Verfügung gestellt wird und das Source Repository beheimatet ist. Bei skalierten Applikationen werden mehrere Kopien eines Gears auf mehrere Nodes übertragen (Kasten: „Skalierung“). Die Kommunikation mit den Nodes erfolgt über eine Messaging-Middleware, konkret kommt hier ActiveMQ zum Einsatz. Für die Verteilung bzw. Reaktion auf Nachrichten ist MCollective verantwortlich. Auf dem Node (genau wie auf dem Broker) leitet dieses Framework die entsprechenden Aktionen an die OpenShift-Node-Dienste weiter.

Eine Applikation erstellen wir entweder über die Weboberfläche des Brokers oder über die RHC-Client-Tools auf unserem Entwicklungsrechner. Für die Erstellung benötigen wir die Angabe eines Namens, eines Profils und einer Cartridge. Der Name wird sowohl für die Domain genutzt, als auch lokal ein Verzeichnis für uns erstellt, in das der Quellcode für uns ausgecheckt wird. Profile dienen zur Bestimmung von unterschiedlichem Ressourcenbedarf, aus denen der Entwickler bei der Erstellung seiner Applikation auswählen kann (Kasten: „Ressourcenmanagement und Sicherheit“). Cartridges sind in OpenShift verfügbare Vorlagen für die Laufzeitumgebung. Benötige ich Java, Ruby, PHP, einen Tomcat oder doch einen ausgewachsenen JBoss Application Server, eine MariaDB, Postgresql oder MongoDB, dann wird dies über die Verwendung von Cartridges konfiguriert. Sie stellen alle notwendigen Bibliotheken, Binaries und Konfigurationen bereit, sodass eine lauffähige Umgebung sofort bereitsteht. Wir sind nicht nur auf die bereits existierenden Cartridges angewiesen, sondern können diese auch selbst erstellen und so den Unternehmensbedürfnissen anpassen. Die Anwender unserer Applikationen benötigen lediglich den Domänennamen, unter dem wir die Applikation zur Verfügung stellen und gelangen zum Node, der hauptsächlich für unsere Anwendung verantwortlich ist. Über einen Reverse Proxy werden die Anfragen an unseren Applikations-Container, das Gear, weitergeleitet.

Skalierung
OpenShift ist nicht nur als offene und erweiterbare Plattform entwickelt worden, sondern auch unter dem Gesichtspunkt der Unterstützung von skalierbaren Anwendungen. Beim Erstellen einer Anwendung muss angegeben werden, ob es sich um eine skalierbare Anwendung handelt. Die meisten Cartridges unterstützen die Option, wodurch sie in der Weboberfläche sowie über die Kommandozeile verfügbar ist. Anschließend kann konfiguriert werden, wie viele Gears minimal bereitgestellt werden sollen und bis zu welcher Anzahl Gears unsere Applikation anwachsen darf. Als Load Balancer kommt HAProxy [6] zum Einsatz. OpenShift überwacht die von HAProxy bereitgestellten Metriken (z. B. Anzahl aktiver Sessions) und stellt bei Bedarf weitere Gears bis zur maximalen konfigurierten Anzahl zur Verfügung. Die Konfiguration des Load Balancer lässt sich an die eigenen Bedürfnisse anpassen. In Unternehmensumgebungen ist meist ein Load Balancer (z. B. F5) vorhanden. Dieser und andere existierende Infrastruktur kann mit OpenShift weiter verwendet werden.
Resourcenmanagement und Sicherheit
Jede Anwendung verfügt über ein Profil. Es legt fest, welche Ressourcen die Anwendung zur Laufzeit verwenden darf. In der Standardinstallation gibt es ein „Small“-Profil, das den Anwendungen 512 MB Hauptspeicher und 1 GB Festplattenplatz erlaubt. Die Einhaltung der Ressourcen-Grenzen wird über CGroups verwaltet. Fällt eine Anwendung aus dem Rahmen, werden die gestarteten Prozesse des Gear beendet und neu gestartet. Für die Sicherheit bezüglich des Systemzugriffs kommt SELinux zum Einsatz. SELinux setzt ein von der NSA entworfenes Sicherheitskonzept um. Per se verbietet es jeglichen Zugriff und nur über Regeln werden feingranulare Berechtigungen für Prozesse vergeben, die somit nur auf bestimmte Dateien oder Verzeichnisse Zugriff erhalten. Dadurch befinden sich die Gears und deren Prozesse in einem Sicherheitskontext, in dem Zugriffe geregelt und die Gears vom System und anderen Gears isoliert sind. Aber nicht nur auf Prozess- und Systemebene sind Gears abgeschottet, sondern auch was ihre Kommunikationsmöglichkeiten betrifft. Jedem Gear wird eine lokale IP-Adresse im Bereich 127.x.x.x zugeordnet. Die Kommunikation mit anderen Gears wird über iptables-Regeln ermöglicht, die OpenShift selbstständig erstellt und modifiziert. iptables ist ein Programm, das die Firewall-Regeln des Linux-Kernel verwaltet. Dies ist z. B. notwendig, wenn separate Gears für die Anwendung und die zugehörige Datenbank verwendet werden. OpenShift übernimmt dabei die Orchestrierung und stellt den Gears die notwendigen Informationen (z. B. Host, Port) zur Verfügung.

Aufmacherbild: Businessman bridge position over blue sky background von Shutterstock / Urheberrecht: Creativa Images

[ header = Seite 2: Installation von OpenShift ]

Installation von OpenShift

Die Installation von OpenShift gestaltet sich dank des neuen OO-Installers einfach. Er ist in der Lage, uns sowohl durch die Installation von OpenShift Origin als auch OpenShift Enterprise zu führen. Dabei ist es sowohl möglich, Broker und Node für Testzwecke auf eine einzige Maschine zu installieren, als auch Broker auf einer und den Node auf einer anderen Maschine installieren zu lassen. Letzteres wird unser Setup für die kommenden Schritte sein. Für einfache Testzwecke lohnt es sich, das bereits fertig bereitgestellte VM-Image zu laden und zu verwenden.

Integration von OpenShift in OpenStack
Bereits jetzt ist es möglich, mit OpenStack Heat (ähnlich zu Amazon CloudFormation) OpenShift automatisiert in einem OpenStack-Cluster auszurollen. Die zukünftige Integration, aktuell in einem Project Enhancement Proposal (PEP) 007 beschrieben, geht hier mehrere Schritte weiter. OpenStack-Dienste, wie z. B. der Identity Service „Keystone“, sollen zur Authentifizierung und Authorisierung integriert werden. Damit lässt sich die Benutzerverwaltung für OpenShift und OpenStack zentralisieren. Des Weiteren werden die Nodes und Broker-Systeme auf ihre Auslastung hin überwacht und bei Bedarf automatisch über die Nutzung des Heat-API weitere Systeme provisioniert.

Vorbereitung der Installation

Wir werden unsere OpenShift-Installation mit einem Broker (broker.cloud.codecentric.de) und einem Node (node1.cloud.codecentric.de) vornehmen. Auf dem Broker werden alle notwendigen Dienste installiert, wie ActiveMQ für Kommunikation, BIND als DNS-Server und MongoDB für die Datenhaltung. Im produktiven Einsatz ist es ratsam, diese Dienste auf verschiedene Systeme aufzuteilen bzw. existierende Infrastrukturen zu nutzen, was den Rahmen dieses Artikels jedoch überschreitet.
Als Betriebssystem verwenden wir Fedora 19, OpenShift Origin wird unsere Wahl für die Installation sein. Der Installationsprozess von OpenShift Enterprise folgt den gleichen Prinzipien und kann als 30-Tage Testversion verwendet werden. Für den langfristigen Betrieb von OpenShift Enterprise sind aktive Subskriptionen notwendig, unsere OpenShift Origin Version benötigt diese jedoch nicht und ist uneingeschränkt nutzbar.

Die Installation muss entweder von dem Nutzer root oder einem Nutzer mit Root-Berechtigungen ausgeführt werden. Zusätzlich muss auf allen OpenShift-Systemen SELinux entweder im Permissive– oder im Enforcing-Modus laufen. Weiterhin ist es notwendig, ein SSH Keypair ohne Passwortschutz auf dem Broker zu generieren und zum Node zu übertragen, sodass während der Installation eine Verbindung zum Node aufgebaut werden kann. Anschließend müssen auf dem Broker, sowie auf dem Node noch zusätzliche Pakete installiert werden. Dazu verwenden wir den Paketmanager yum (Listing 1).

broker$ ssh-keygen
broker$ ssh-copy-id node1.cloud.codecentric.de

broker$ yum -y install ruby unzip puppet augeas dnssec-tools httpd-tools

node1$ yum -y install puppet augeas

Ausführen des Installer

Nun kann der Installer ausgeführt werden. Dieser lässt sich durch folgenden Befehl starten:

broker$ sh <(curl -s https://install.openshift.com/)

Die aktuelle Version wird geladen und anschließend ausgeführt. Für die Durchführung der Installation werden uns Fragen zur Konfiguration von Broker und Node gestellt. Dazu führt der Installer uns Schritt für Schritt durch die einzelnen Konfigurationsmöglichkeiten, wie z. B. den Hostnamen unserer Maschinen, den Domänennamen unter dem unsere Anwendungen verfügbar sein sollen und ob eigene Passwörter vergeben werden oder automatisch generierte verwendet werden sollen. Zuerst wird die Konfiguration des Brokers und anschließend die Konfiguration unseres Node vorgenommen. Der Installer kann auch jederzeit gestartet werden, wenn ein neuer Node dem System hinzugefügt werden soll.

Bevor das Installationsprogramm beginnt, zeigt es uns noch eine Übersicht der von uns gewünschten Konfiguration, sowie die Benutzer und deren Passwörter an. Mit diesen Informationen generiert das Installationsprogramm für uns Puppet-Skripte, mithilfe derer sowohl Broker als auch Node provisioniert werden.

Prüfen der Installation

Den Erfolg unserer Installation überprüfen wir anschließend am einfachsten durch die Sichtung der Log-Dateien. Diese befinden sich unter /tmp auf unserem Broker als auch auf unserem Node. Ist alles in Ordnung, also keine Fehler im Log protokolliert, können wir die Systeme in der Reihenfolge Broker und anschließend Node neu starten.
Nach dem Neustart steht die Benutzeroberfläche auf dem Broker unter dem URL unseres Brokers (hier im Beispiel: http://broker.cloud.codecentric.de) zur Verfügung. Anmelden können wir uns mit dem Benutzer demo und dem vom Installationsprogramm generierten oder einem gewählten Passwort. Dann sollte uns die Administrationsoberfläche wie in Abbildung 3 begrüßen. Die Kommunikation zum Node kann über einen Befehl überprüft werden:

oo-mco ping

Dieser zeigt im Output den Namen unseres Node und die Antwortzeit in Millisekunden. Weiterhin steht ein hilfreiches Programm nach der Installation zur Verfügung, das die Systemkonfiguration überprüft und entsprechende Informationen zurückliefert:

oo-diagnostics

Abb. 3: Begrüßungsbildschirm OpenShift Origin

Konfiguration der OpenShift-Umgebung

Eigentlich können wir jetzt anfangen, die ersten Applikationen zu erstellen und mit der Verwendung unserer OpenShift-Plattform starten. Jedoch haben wir noch keinen District angelegt. In ihm werden mehrere Nodes logisch gruppiert und der OpenShift Broker nutzt die Informationen aus dem District um ein Load Balancing bei der Verteilung der Applikationen vorzunehmen. Eine Einschränkung gibt es dabei: Es können nur Nodes in einen District hinzugefügt werden, die das gleiche Gear-Profil unterstützen. Die Konfiguration eines District erfolgt auf dem Broker. Listing 2 zeigt die auszuführenden Befehle und zur besseren Übersicht sollte der Name des District auch den Namen des Profils beinhalten.
In der Standardkonfiguration nach der Installation ist auf dem Node ein „small“-Profil konfiguriert. Je Node kann jedoch nur ein einziges Profil verwendet werden. Die Konfiguration des Profils befindet sich auf jedem Node in der Datei /etc/openshift/resource_limits.conf. Zusätzlich müssen neue Profile auch dem Broker bekannt gemacht werden, was durch die Anpassung der Broker-Konfiguration in /etc/openshift/broker.conf erfolgt.

Weiterhin möchten wir gerne einen JBoss Application Server verwenden, jedoch wird bei OpenShift Origin das entsprechende Cartridge nicht installiert. Das ist jedoch kein Problem, denn es gibt ein fertiges Paket dafür. In Listing 2 finden sich dafür auch die entsprechenden Befehle zum Ausführen. Anschließend finden wir in der Cartridge-Auswahl in der Weboberfläche dann unseren JBoss Application Server wieder.
Zuletzt muss unser Broker noch als verantwortlicher Name-Server für unsere Domäne, unter der wir die Applikationen bereitstellen, registriert werden. Für einen schnellen Test kann auch die lokale Datei hosts angepasst und die IP-Adresse des Node mit dem vollständigen Domänennamen unserer Applikation eingetragen werden.

broker$ oo-admin-ctl-district -c create -n district1_small -p small
broker$ oo-admin-ctl-district -c add-node -n district1_small -i 
  node1.cloud.codecentric.de

node1$ yum -y install openshift-origin-cartridge-jbossas
node1$ service mcollective restart
broker$ /usr/sbin/oo-admin-broker-cache --console

Verwendung unserer OpenShift-Installation

Nun steht der Bereitstellung unserer ersten eigenen Anwendung nichts mehr im Weg. Zuerst installieren wir die OpenShift Client Tools (kurz rhc genannt für Red Hat Cloud), die als ruby-gem bereitgestellt werden, und zusätzlich auch Git. Wie in Abbildung 2 bereits gesehen, legt OpenShift bei Erstellung unserer Applikation ein Git-Repository innerhalb des Gears an. Dort liegt unser Quellcode bereit und eine Kopie wird von den rhc-Tools lokal zur Verfügung gestellt.
Dazu müssen wir zuerst die Konfiguration von rhc vornehmen und dürfen dabei nicht die Angabe des Parameter —server <unsere Broker-URL> vergessen, da per Default immer mit OpenShift Online kommuniziert wird.
Anschließend können wir die erste Applikation namens sandbox unter Verwendung der JBoss Cartridge anlegen, die uns einen Java-EE-kompatiblen Application Server bereitstellt. Zusätzlich entscheiden wir uns noch für eine Datenbank, nämlich eine PostgreSQL. Listing 3 zeigt die dazu notwendigen Schritte.

client$ rhc setup —server broker.cloud.codecentric.de -l demo

client$ rhc app create sandbox jbossas-7

client$ rhc cartridge-add postgresql-9.2 -a sandbox

Die Ausgabe der Aufrufe gibt uns alle notwendigen Informationen über die neu angelegte Applikation, wie z. B. den URL unter dem diese verfügbar ist, den URL zum SSH-Zugriff und für das Git Repository. Zusätzlich wurde das Git Repository bereits für uns ausgecheckt, sodass wir sofort mit dem Arbeiten loslegen können. Rufen wir unsere Anwendung auf, so sollte wie in Abbildung 4, das erfolgreiche Anlegen bestätigt werden. Jetzt können wir in unserem lokalen Repository unseren Quellcode bearbeiten und anschließend mit Git pushen. Dadurch wird ein Maven Build ausgelöst und unser Artefakt auf den JBoss deployt.

Abb. 4: Meldung beim Aufruf unserer angelegten Applikation

Zusammenfassung und Ausblick

Wir haben gesehen, wie einfach eine Grundinstallation von OpenShift ist, sodass man in kurzer Zeit die ersten Gehversuche mit einer PaaS im Unternehmen durchführen kann. Für die Entwickler bedeutet der Einsatz dieser Plattform, dass sie sich wieder mehr auf die Entwicklung ihrer Anwendungen konzentrieren können. Lediglich gewisse Vorentscheidungen müssen getroffen werden, wie z. B. welche Laufzeitumgebung, welche Ressourcennutzung oder wie viel Instanzen benötigt unsere Applikation.
OpenShift liefert mit den Cartridges vorgefertigte Templates, die je nach Unternehmenseinsatz angepasst werden können. Die Freigabe der verfügbaren Cartridges erfolgt zusammen mit dem Betrieb, sodass man sich hier auf gemeinsame Standards und Anforderungen einigen kann. In der Standardinstallation wird auch immer ein Jenkins-Build-Server mitgeliefert und mit dem Jenkins-Client Cartridge lassen sich unsere Applikationen über diesen bauen und deployen. Wie man mit Jenkins eine Continuous-Delivery-Pipeline aufsetzt, zeigen meine Kollegen in der nächsten Ausgabe.

Geschrieben von
Marco Metzen
Marco Metzen
Marco Metzen ist Senior Consultant bei der codecentric AG. Er hat langjährige Erfahrung in der Entwicklung von unternehmenskritischen und verteilten Softwaresystemen mit Java und Java EE. Der Schwerpunkt seiner Tätigkeiten in Projekten ist der Entwurf und die Umsetzung technischer Architekturen, das technische Design von Anwendungskomponenten und das Coaching von Entwicklerteams.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: