© Karol Sobolewski, 123RF

Red Hat bedient sich bei seinem Clouddienst Open Shift, der Webentwickler zu PaaS-Anhängern machen will, einiger Analogien aus der Welt der Getriebe. Weil es in der Red-Hat-Cloud bis zu drei virtuelle Maschinen samt HA für lau gibt, hat das Linux-Magazin geschaut, ob die Zahnräder spielfrei ineinandergreifen.

Der Linux-Marktführer bietet schon länger Cloud- und darunter PaaS-Dienste (Platform as a Service, [1]) an, seit 2011 auch unter dem Namen Open Shift [2]. Red Hat lässt es bei der Wortwahl für Open Shift ziemlich rattern. Im offenen Getriebe finden sich allerorts Anspielungen auf Motoren und Zahnrädern (Gears) oder Gänge (ebenfalls Gears).

Als gesetzt darf gelten, dass Red Hat dank Open-Shift-PaaS seine Cloudinfrastruktur-Pferdestärken besser auf die Straße bringen will. Entwickler sollen mit dem Produkt auf einfache Weise eine virtuelle Instanz oder einen vorbereiteten simu- oder emulierten Rechner bereitgestellt bekommen, auf dem beispielsweise eine komplette Entwicklungsumgebung installiert ist.

Bei dem Cloudangebot brauchen sich Admin, Entwickler oder Devops nicht um die Installation zu kümmern – so zumindest die Theorie. Sie starten einfach neue Instanzen und vergessen Paketpflege, Abhängigkeiten, Compiler oder Ähnliches.

Vor allem bei Webentwicklern fand dieses Konzept schnell Anklang, doch auch wenn es darum geht, schnell einen CMS-Server hochzufahren, bietet es sich an. Red Hat will es also Entwicklern und Testern leichter machen, in eine – natürlich von Red Hat betriebene – Cloud zu wechseln. Dementsprechend gibt es Open Shift sowohl als Webdienst in einer Public Cloud wie auch zur Selbstinstallation (Abbildung 1).

Abbildung 1: Online, Enterprise und Origin: Open Shift gibt es in drei Geschmacksrichtungen.

Sprachen und Begriffe

Die Red-Hat-Entwickler haben Open Shift in Ruby geschrieben. Als Framework unterstützt es Java und Dotnet (nach Gartner die zwei wichtigsten PaaS-Sprachen) sowie Haskell, Javascript, Perl, PHP, Python und – wenig überraschend – auch Ruby. Entwicklern stehen mehrere Datenbanken zur Verfügung, von MySQL über PostgreSQL bis zu Mongo DB.

Eine lange Liste auf der Webseite zeigt die Frameworks und APIs, die Programmierern zu Diensten stehen. Mit all dem will Red Hat Open Shift natürlich zu nichts weniger aufbauen als zu der Laufzeitumgebung für jedermann.

Das Getriebe besteht aus Gears, Cartridges, Applikationen, Client-Tools und automatischen Skalierungsmechanismen. Alles was der User laut Red Hat braucht, seien ein grundsätzliches Verständnis zu SSH, Git und der gewählten Applikation. Vermutlich wird Basis-Know-how hinsichtlich der Architektur, die Red daruntergeschoben hat, auch nicht schaden. Open Shift zeigt sich dem Anwender zunächst als Webdienst, als Public Cloud, die von überall erreichbar ist und die Open Stack antreibt.

Was die Kontaktmöglichkeiten der Anwendungen (Applications) angeht, zeigt sich Open Shift zugeknöpft: Nur die Ports 22, 80, 443, 8000 und 8443 sind von außen auf jeder virtuellen Maschine erreichbar, also SSH, HTTP, HTTPS und zwei Ports für beispielsweise Websockets. Andere Wege in die virtuelle Instanz gibt es nicht – Anwendungen, die etwas anderes brauchen, werden nicht oder nicht richtig funktionieren. Der Anwender ist hier festgelegt.

Red Hats Cloud hinter Open Shift kann sowohl public als auch private arbeiten, sie stellt die Servercontainer für die Applikationen bereit. Als der Hersteller 2011 auf seinem jährlichen Summit in Boston Open Shift startete, isolierte eine Mischung aus SE Linux und Cgroups die einzelnen Anwendungen. Diese virtuellen Maschinen oder Container sortiert Open Shift in die besagten Gears. Die für den Herbst angekündigte Version 3 wird daran einiges ändern (siehe Kasten “Open Shift 3”).

Reiche Cartridge-Auswahl

In der zurzeit für den Produktivbetrieb vorgesehenen Version 2, die sich auf der Herstellerwebsite einfach testen lässt, rotiert alles ums Getriebe. Ein Gear ist im einfachsten Falle ein Container (oder aber auch ein -Verbund), der eine Applikation betreibt. Es gibt drei Typen von Gears, die sich aber nur in RAM und Plattenplatz unterscheiden.

Als Cartridges (Kartuschen) bezeichnet Red Hat die zur Verfügung stehenden Frameworks und APIs, von Jboss bis zu Node.js, von der Datenbank bis zu Cron gibt es für Open Shift (Version 2) eine reiche Auswahl. Cartridges können alleine arbeiten (wie Frameworks) oder mit anderen verknüpft sein, etwa wenn eine Datenbank oder der Cron-Daemon nötig sind. Meist laufen mehrere Cartridges auf oder in einem Gear zugleich, was die Sache verzwickt macht: Sie bleiben nicht auf einen Gang beschränkt.

Im Nebenjob besorgt Open Shift die automatische Skalierung: Reichen die Ressourcen nicht, dann fährt es einfach einen oder mehrere identische Container hoch – bei einem Webserver passierte das, wenn er 16 oder mehr Verbindungen zeitgleich zu bewältigen hat.

Während das Hoch- und Runterfahren von Containern für das Backend ein Leichtes ist, müssen Entwickler und Admins selbst dafür sorgen, dass ihre Applikationen diese Art Skalierung auch verkraften. Wer darüber etwas lernen will, dem sei das Buch [9] empfohlen, das trotz seiner wenigen Seiten einen guten Einstieg gibt, der bis zum Skalieren von Python-Applikationen reicht.

Die Geschmacksrichtungen

Die drei Flavours von Open Shift, die sich schon beim ersten Besuch der Webseite zeigen, sind schnell erklärt: Fast immer läuft der erste Kontakt über die Public-Cloud-PaaS-Lösung. Um den Online-Tier zu testen, braucht der Tester nur einen Red-Hat-Account. Nach der Registrierung geht es dann los.

Open Shift Enterprise dagegen ist die installierbare On-Premise-Lösung, die laut den Rothüten PaaS in die Unternehmen bringen wird. Bei dieser Produktversion gibt es eine Webkonsole, CLIs, IDEs und das Ganze als Public-, Private- oder Hybrid-Wolke – bei Bedarf auch mit automatischer Skalierung.

Origin [7] ist das Upstream-Projekt von Open Shift, was die Anwesenheit der oben erläuterten Betaversion von Open Shift 3 erklärt. Neben deren Sourcen finden sich darin auch zahlreiche Open-Shift-Images für KVM, Virtualbox oder VMware, ein Puppet- sowie ein Deployment- und der Easy-Installation-Guide [10]. Wer das ausprobieren will, sollte gleich mit Centos oder einem Original-RHEL loslegen, denn darauf ist die Dokumentation ausgerichtet.

Alles öko

Typisch für Red Hat ist die Ausrichtung auf Ökosysteme. Dieses Buzzword ist allgegenwärtig, auch für Open Shift stricken die Mannen aus Raleigh Website um Website: Commons ([11], Abbildung 2) und Marketplace ([12], Abbildung 3) machen den Anfang. Während Commons sich eher an Unternehmen richtet, die Open Shift fördern wollen (“Companies using Open Shift to accelerate its Success and Adoption”), ist der Marktplatz für Anwender, Entwickler und Partner gedacht, die ihre Produkte in der Open-Shift-Welt vermarkten und für Anwender so simpel wie möglich zu Download und Test bereitstellen wollen.

Abbildung 2: Open Shift Commons sucht Partner aus der Industrie.

Abbildung 3: Der Marktplatz glänzt durch ein schnell wachsendes Angebot an Containern.

Der Praxistest

Für einen schnellen Test reicht die kostenfreie Online-Version von Open Shift absolut aus. Hier werkelt die stabile Version 2, weshalb die Beispiele und Anleitungen aus [9] und [10] voll und ganz zutreffen. Nur ein wenig Wissen um SSH und Git (weil Open Shift dort die Konfiguration speichert) sind notwendig.

Wer noch keinen Red-Hat-Account hat, meldet einen an und wartet die Bestätigung ab. Nun kann’s losgehen: Auf [2] einloggen und den persönlichen »Open Shift Settings« -Dialog aus Abbildung 4 aufrufen. Hier gilt es, einen Namespace anzulegen und den eigenen Public Key hochzuladen, »Save« zu klicken und auf die Bestätigung zu warten.

In der Zwischenzeit kann der Admin auf seinem lokalen Rechner die RHC-Tools installieren, entweder via Rubygems mit

yum install rubygems
gem install rhc

oder direkt mit »yum install rubygem-rhc« . Egal wie, wenn das Fedora-, Centos- oder RHEL-System fertig ist, startet »rhc setup« . Listing 1 verfolgt das Frage-und-Antwort-Spiel zur initialen Konfiguration.

Zu guter Letzt zeigt das Setuptool verfügbare Applikationen und die Anzahl freier Gears. In der kostenlosen Online-Version sind nur die kleinen Gänge (»small« ) erlaubt, »rhc cartridge list« zeigt die ganze Liste möglicher Cartridges (Listing 2).

Abbildung 4: Namespace, Public Key, Authorizations. Im Settings-Dialog von Open Shift Online definiert der Anwender seine Umgebung.

01 OpenShift Client Tools (RHC) Setup Wizard
02
03 This wizard will help you upload your SSH keys, set your application namespace, and check that other programs like Git are properly installed.
04
05 If you have your own OpenShift server, you can specify it now. Just hit enter to use the server for OpenShift Online: openshift.redhat.com.
06 Enter the server hostname: |openshift.redhat.com|
07
08 You can add more servers later using 'rhc server'.
09
10 Login to openshift.redhat.com: mfeilner@linux-magazin.de
11 Password: **********
12
13 OpenShift can create and store a token on disk which allows to you to access the server without using your password. The key is stored in your home directory and should be kept secret.  You can delete the key at
14 any time by running 'rhc logout'.
15 Generate a token now? (yes|no) yes
16 Generating an authorization token for this client ... lasts about 1 month
17
18 Saving configuration to /home/mfeilner/.openshift/express.conf ... done
19 Checking for git ... found git version 2.1.0
20 Checking common problems .. done
21 Checking for a domain ... feilner
22 Checking for applications ... none
23
24 Run 'rhc create-app' to create your first application.
25   Do-It-Yourself 0.1                rhc create-app <app name> diy-0.1
26   JBoss Application Server 7        rhc create-app <app name> jbossas-7
27 [...]
28   WildFly Application Server 8.2.0.Final  rhc create-app <app name> jboss-wildfly-8
29   You are using 0 of 3 total gears
30   The following gear sizes are available to you: small
31
32 Your client tools are now configured.

01 jbossas-7                JBoss Application Server 7              web
02 jboss-dv-6.0.0 (!)       JBoss Data Virtualization 6             web
03 jboss-dv-6.1.0 (!)       JBoss Data Virtualization 6             web
04 jbosseap-6 (*)           JBoss Enterprise Application Platform 6 web
05 jboss-unified-push-1 (!) JBoss Unified Push Server 1.0.0.Beta1   web
06 jenkins-1                Jenkins Server                          web
07 nodejs-0.10              Node.js 0.10                            web
08 perl-5.10                Perl 5.10                               web
09 php-5.3                  PHP 5.3                                 web
10 php-5.4                  PHP 5.4                                 web
11 zend-6.1                 PHP 5.4 with Zend Server 6.1            web
12 python-2.6               Python 2.6                              web
13 python-2.7               Python 2.7                              web
14 python-3.3               Python 3.3                              web
15 ruby-1.8                 Ruby 1.8                                web
16 ruby-1.9                 Ruby 1.9                                web
17 ruby-2.0                 Ruby 2.0                                web
18 jbossews-1.0             Tomcat 6 (JBoss EWS 1.0)                web
19 jbossews-2.0             Tomcat 7 (JBoss EWS 2.0)                web
20 jboss-vertx-2.1 (!)      Vert.x 2.1                              web
21 jboss-wildfly-8 (!)      WildFly Application Server 8.2.0.Final  web
22 diy-0.1                  Do-It-Yourself 0.1                      web
23 10gen-mms-agent-0.1      10gen Mongo Monitoring Service Agent    addon
24 cron-1.4                 Cron 1.4                                addon
25 jenkins-client-1         Jenkins Client                          addon
26 mongodb-2.4              MongoDB 2.4                             addon
27 mysql-5.1                MySQL 5.1                               addon
28 mysql-5.5                MySQL 5.5                               addon
29 phpmyadmin-4             phpMyAdmin 4.0                          addon
30 postgresql-8.4           PostgreSQL 8.4                          addon
31 postgresql-9.2           PostgreSQL 9.2                          addon
32 rockmongo-1.1            RockMongo 1.1                           addon
33 switchyard-0             SwitchYard 0.8.0                        addon
34 haproxy-1.4              Web Load Balancer                       addon
35
36 Note: Web cartridges can only be added to new applications.
37 (*) denotes a cartridge with additional usage costs
38 (!) denotes a cartridge that will not receive automatic security updates

Applikation in Gang setzen

Nun gilt es, eine erste Applikation zu erzeugen. Wer faul ist, klickt im Webinterface auf »Create your first application now« . Einigermaßen schnell geht es alternativ mit »rhc app create« , gefolgt von dem Namen der App und dem Typ der Cartridge (Listing 3). Am Ende der Prozedur bekommt der Anwender die Zugangsdaten zum Container geliefert. Wie die freundliche Ausgabe dieses Kommandos bereits andeutet, liefert »rhc show-app Name_der_App« diese Basisinformationen jederzeit nach.

Wer die Ausgaben von »rhc app create« genau studiert, trifft auf das eigentliche Problem: das Setup per Git. Zu Beginn existiert noch keine Git-Konfiguration für die Anwendungskonfiguration. Die muss der Kunde aus dem Nichts entwickeln und in Git einchecken. Den selten kurzen Weg dahin hilft der User Guide [13] beschreiten. Im Kern entwickelt man die Konfiguration in einem lokalen Git, pusht sie bei Änderungen und stellt das so der Open-Shift-Cloud zur Verfügung, damit die identische Instanzen starten kann. Auch die Autoren von [9] haben ein nettes Kapitel über eine Beleidigungs-App, anhand derer sie unter anderem die Git-Konfiguration erläutern.

Wer »rhc setup« erneut aufruft, dem teilt das Tool mit: »You are using 1 of 3 total gears« – also läuft der erste Container. Applikationen löschen gelingt am CLI mit »rhc del app« (Listing 4), die Konfiguration von Open Shift und alle Tokens liegen auf dem Client in »~/.openshift/« . Wer das nicht glaubt, besucht per Browser die angebotene URL (Abbildung 5).

01 Application Options
02 -------------------
03 Domain:     feilner
04 Cartridges: python-2.7
05 Gear Size:  default
06 Scaling:    no
07
08 Creating application 'MyFirstApp' ... done
09 Waiting for your DNS name to be available ... done
10 Klone nach 'myfirstapp'...
11 The authenticity of host 'myfirstapp-feilner.rhcloud.com (54.89.183.121)' can't be established.
12 RSA key fingerprint is cf:ee:77:cb:0e:fc:02:d7:72:7e:ae:80:c0:90:88:a7.
13 Are you sure you want to continue connecting (yes/no)? yes
14 Warning: Permanently added 'myfirstapp-feilner.rhcloud.com,54.89.183.121' (RSA) to the list of known hosts.
15 Connection closed by 54.89.183.121
16 fatal: Could not read from remote repository.
17
18 Please make sure you have the correct access rights and the repository exists.
19 Unable to clone your repository.
20 [...]
21
22 Your application 'myfirstapp' is now available.
23
24   URL:        http://myfirstapp-feilner.rhcloud.com/
25   SSH to:     55060dfae0b8cd7df90000b6@myfirstapp-feilner.rhcloud.com
26   Git remote: ssh://55060dfae0b8cd7df90000b6@myfirstapp-feilner.rhcloud.com/~/git/myfirstapp.git/

01 This is a non-reversible action! Your application code and data will be permanently deleted if you continue!
02 Are you sure you want to delete the application 'myfirstapp'? (yes|no): yes
03
04 Deleting application 'myfirstapp' ... deleted

Abbildung 5: Pythons Willkommensgruß bei der ersten selbst gebauten Open-Shift-Applikation.

Leichter geht’s via Web

Das Ganze geht per Webinterface etwas einfacher: In Open Shift Online klickt der administrierende Anwender einfach auf »Applications« , wählt eine App, die ihm gefällt, und füllt in Schritt 2 die offenen Felder mit seinen Daten. Im Test gelang das mit WordPress problemlos, nur die angesprochene Auto-Skalierungs-Problematik muss der Admin selbst lösen. Abschließend auf »Create Application« geklickt – und schon startet WordPress (Abbildungen 6 und 7).

Wer seine Applikation aus dem CLI-Beispiel oben noch laufen hat, sieht jetzt unten auf der Webseite ein kleines »+2« -Symbol: Er benutzt derzeit zwei Gänge und hat noch einen weiteren frei. Nach ein wenig Warten bietet Open Shift mehr Informationen (WordPress ist gestartet) samt Login-Daten für die Instanz. Die enthalten das Rootpasswort der Datenbank, den Datenbanknamen und die URL, unter der WordPress erreichbar ist. Auch hier gibt es eine gute Anleitung für die Git-Konfiguration.

Abbildung 6: Open Shift für WordPress konfigurieren – oder umgekehrt?

Abbildung 7: Ein neues WordPress-Blog ist verfügbar, zwei Gears laufen – so berichtet Open Shift.

Ausreichend Drehmoment

Entwickler und Devops, die Open Shift für sich aus Red Hats Garage rollen, dürfen sogar bei Enterprise-Voraussetzungen auf entspanntes Rundendrehen hoffen. Vorher müssen sie sich jedoch durch eine Konfiguration per Git mühen. Was bei vielen gleichartigen Diensten vermutlich Aufwand spart, stimmt bei gegenteiligen Voraussetzungen verdrießlich.

Nach fast fünf Jahren steht mit Version 3 ein großer Umbruch an, der die Antriebstechnik des Produkts ins Jahr 2015 holt. Die Anwender, so ist zu hoffen, betrifft das kaum. Darum: Im Herbst einfach mal einen Gang hochschalten.

Der Autor

Markus Feilner ist ein Linux-Spezialist aus Regensburg, der seit 1994 mit dem freien Betriebssystem als Autor, Trainer, Consultant und Journalist arbeitet. Der Conch-Diplomat, Minister der Universal Life Church und Jedi-Ritter leitet heute das Dokumentationsteam bei Suse in Nürnberg.