© Adrian Hughes, 123RF

Ein Kommandozeilenbefehl startet eine vollständige Entwicklungsumgebung, ein weiterer schiebt die eigene Webanwendung auf den Produktivserver – und all das ohne eine einzige Konfigurationsdatei. Den Traum des Webentwicklers möchte das brandneue Tool Otto wahr machen.

Die nigelnagelneue Webanwendung –beim Entwickler arbeitet sie zuverlässig und sieht verdammt schick aus. Bis er sie auf einen öffentlichen Webserver schiebt. Plötzlich liefert der aufgrund strikter Zugriffsrechte Grafiken nicht aus, während die App munter fehlende PHP-Bibliotheken anmahnt. Meist kommt der Motor ins Stottern, wenn gerade der wichtige Releasetermin ins Haus steht.

Lieferheld

Einen eleganten Ausweg aus dieser Situation verspricht das Tool Otto [1]. Es richtet zunächst auf dem System des Programmierers eine maßgeschneiderte Entwicklungsumgebung ein. Auf Zuruf verpackt es die fertige Anwendung in eine virtuelle Maschine und startet diese automatisch auf dem Produktivsystem beziehungsweise in einer Cloud. Otto stellt dabei nicht nur sicher, dass alle notwendigen Bibliotheken, Frameworks und Dienste vorhanden sind, sondern sichert auch das produktive System gegen Angriffe ab.

Das Projekt benötigt eine Datenbank? Auch das ist kein Problem: Otto installiert sie und richtet sie automatisch passend ein. Bei seiner Arbeit orientiert sich das Werkzeug durchgehend an erprobten Best Practices. Otto ist sogar so intelligent, anhand des Quellcodes zumindest teilweise auf die benötigten Abhängigkeiten zu schließen.

Hat der Entwickler seine Anwendung schließlich überarbeitet, genügt ein weiterer singulärer Kommandozeilenbefehl, um sie auf das produktive System zu überspielen. Damit unterstützt Otto aktiv das Prinzip der Continuous Integration beziehungsweise der Continuous Delivery. Das erlaubt es Entwicklern, ihre Projekte in schneller Folge um neue Funktionen zu erweitern und diese auszuliefern. Da sie so auch klassische Admin-Aufgaben übernehmen, werden sie ganz nebenbei zum Devop ([2], [3]).

Alte Bekannte

Für die Entwicklung von Otto zeichnet die Firma Hashicorp verantwortlich. Das kalifornische Unternehmen ist vor allem durch sein Tool Vagrant bekannt, das halbautomatisch virtuelle Maschinen aufsetzt [4]. Das klingt nicht nur verdächtig nach einer Aufgabe von Otto, tatsächlich spannt das Tool im Hintergrund Vagrant und zahlreiche weitere Hashicorp-Tools für seine Zwecke ein. Dies geschieht für den Anwender komplett transparent, mit den Tools selbst kommt er nicht in Kontakt. Otto unterliegt der Mozilla Public License in der Version 2.0, die Entwicklung erfolgt offen auf Github [5].

Allerdings gibt es einen Haken: Otto befindet sich noch am Anfang seiner Entwicklung. Zum Redaktionsschluss lag erst die Version 0.1.2 vor, die nur einen kleinen Teil der geplanten Funktionen enthält. Diese führte Otto in Tests für den Artikel aber immerhin bis auf eine kleine Ausnahme zuverlässig aus.

Maggi Fix

Hashicorp stellt Otto als fertiges Paket für 32-Bit-, 64-Bit- und ARM-Systeme bereit. Wer das Tool einsetzen möchte, muss sich nur unter [1] das passende Zip-Archiv herunterladen und es danach auf der Festplatte entpacken. Das dabei herausfallende und gerade mal 15 MByte große Programm »otto« ruft der Entwickler direkt auf, eine Installation ist nicht notwendig. Hashicorp empfiehlt aber, »otto« in den »PATH« einzubinden.

Neben Otto benötigen Anwender noch Virtualbox ab Version 4.2.0 sowie eine aktuelle Ausgabe von Vagrant. Bei einigen großen Distributionen gelingt die Installation der beiden Tools über den Paketmanager, andernfalls warten fertige Pakete für Virtualbox unter [6] und solche für Vagrant unter [7]. Künftige Versionen von Otto sollen alle benötigten Tools automatisch nachinstallieren.

Aufbauarbeit

Für die ersten Gehversuche mit Otto stellt Hashicorp den Quellcode der simplen Webanwendung aus Abbildung 1 bereit. Ihn kann sich der Entwickler entweder bei Github direkt herunterladen [8] oder via »git« auschecken:

Abbildung 1: Die von den Otto-Entwicklern bereitgestellte Webanwendung nimmt einen Namen entgegen und gibt ihn einfach wieder aus.

git clone https://github.com/hashicorp/ otto-getting-started.git

Da die Webanwendung in Ruby geschrieben ist, würden Entwickler jetzt gewöhnlich den Paketmanager zücken und das komplette Ruby-System nebst einem Webserver sowie allen benötigten Abhängigkeiten installieren. Mit Otto reicht es hingegen aus, in das Projektverzeichnis der Webanwendung zu wechseln (»cd otto-getting-started« ) und dort folgende zwei Befehle aufzurufen:

otto compile
otto dev

Das erste Kommando weist Otto an, sich den Quellcode anzusehen und alle zum Aufsetzen der Entwicklungsumgebung nötigen Informationen einzuholen (Abbildung 2). Das Tool erkennt selbstständig, dass es sich um ein Ruby-Programm handelt, und zieht aus dem bei solchen Anwendungen üblichen Gemfile alle benötigten Bibliotheken beziehungsweise Abhängigkeiten. Die auf diese Weise ergatterten Informationen merkt sich Otto innerhalb des Projektverzeichnisses im versteckten Verzeichnis ».otto« . Es enthält primär Konfigurationsdateien für die von Otto eingespannten Werkzeuge, weshalb Otto-Normalverbraucher dort besser keine Änderungen vornehmen.

Abbildung 2: Otto ist äußerst gesprächig. In dem hier ausgeführten ersten Schritt hat das Tool erkannt, dass im aktuellen Projektverzeichnis ein Ruby-Programm liegt.

Alles im Kasten

Hat Otto seine Informationen gesammelt, erstellt »otto dev« die eigentliche Entwicklungsumgebung. Im Hintergrund weist Otto dazu Vagrant an, eine passende VM mit Virtualbox aufzusetzen (Abbildung 3). Ist Vagrant nicht greifbar, bietet Otto an, das Tool selbst herunterzuladen. Das funktioniert in der Version 0.1.2 noch nicht, auch wenn die Otto-Dokumentation anderes suggeriert. Folglich kommt der Ottomane nicht umhin, Vagrant, wie eingangs erwähnt, per Hand zu installieren.

Abbildung 3: Mit Hilfe von Vagrant stellt Otto eine virtuelle Maschine mit einem Mini-Ubuntu zusammen, richtet in ihr einen SSH-Zugang ein und installiert dann die benötigte Software.

Sofern Otto Vagrant starten konnte, lädt dieses ein zirka 350 MByte großes Basisimage herunter und bastelt daraus die komplette virtuelle Maschine. Der erste Aufruf von »otto dev« kann folglich einige Minuten dauern. Das Basisimage enthielt im praktischen Versuch eine Minimalversion des über drei Jahre alten Ubuntu 12.04 LTS Precise Pangolin, dessen Support allerdings erst im April 2017 ausläuft.

Um einfacher Daten in die virtuelle Maschine zu schieben, installiert Otto darin zudem die Virtualbox Guest Additions in Version 4.2.0. Die sind zwar auf die Zusammenarbeit mit Virtualbox 4.2.0 ausgelegt, funktionieren aber auch mit neueren Versionen. Auftretende Probleme mischt Otto unter seine vielen Statusmeldungen, die der Nutzer folglich genau studieren sollte.

Im nächsten Schritt hängt Otto das Projektverzeichnis der Webanwendung transparent in die virtuelle Maschine ein. Änderungen an ihr stehen damit unverzüglich in der virtuellen Maschine bereit und vice versa. Danach installiert Otto in der virtuellen Maschine das Tool Consul [9], das Datenbanken und andere Dienste einfacher findet und adressiert (dazu später mehr).

Jetzt richtet Otto noch die benötigten Programmiertools ein, im Beispiel installiert es unter anderem Ruby. Bei einer PHP-Anwendung spielt Otto neben dem Paketmanager Composer automatisch die häufig verwendeten PHP-Module »mcrypt« , »fpm« , »gd« , »readline« , »pgsq« und »mysql« ein – wohlgemerkt nur das Modul »mysql« , nicht die Datenbank.

Eintrittskarte

Am Ende der Installation läuft im Hintergrund eine virtuelle Maschine mit einer Entwicklungsumgebung. Als Schlusswort fasst Otto alle wichtigen Informationen und möglichen Einschränkungen zusammen (Abbildung 4). Im Fall der Ruby-Anwendung muss der Entwickler etwa noch manuell die Ruby-Gems einspielen. Immerhin hat Otto alles dazu Notwendige vorbereitet. Es genügt daher zunächst mit

Abbildung 4: Die in der virtuellen Maschine verfügbaren Tools verrät Otto zum Schluss noch einmal in einer kurzen Zusammenfassung.

otto dev ssh

in die virtuelle Entwicklungsumgebung zu wechseln. Wie der Befehl andeutet, erfolgt der Zugriff verschlüsselt via SSH, die Anmeldung regelt Otto. Im Anschluss findet sich der Entwickler direkt im Projektverzeichnis (Abbildung 5).

Abbildung 5: Per »otto dev ssh« gelangt der Entwickler in die virtuelle Maschine, in die Otto das Projektverzeichnis einblendet. Dort arbeitet er folglich direkt mit dem Originalquellcode und nicht auf Kopien.

Die von der Anwendung verlangten Ruby-Gems holt jetzt »bundle« nach. Anschließend lässt sich in der virtuellen Maschine mit »rackup –host 0.0.0.0« der Ruby-eigene Webserver zünden, der standardmäßig an Port 9292 lauscht. Bei einem PHP-Programm lautet das Äquivalent »php -S 0.0.0.0:5000« , wobei der Port 5000 zum Einsatz kommt.

Jede virtuelle Maschine – also auch jede von Otto aufgesetzte Entwicklungsumgebung – erhält eine eigene IP-Adresse. Über die erreicht der Nutzer insbesondere die jetzt laufende Webanwendung. Die IP-Adresse verrät Otto in den letzten Zeilen beim Aufsetzen der Entwicklungsumgebung (Abbildung 4). Vergessliche User können auch ein zweites Terminal öffnen, ins Projektverzeichnis wechseln und dort »otto dev address« aufrufen. Im Fall der kleinen Beispielanwendung reicht es, in einem Browser die angezeigte IP-Adresse mit Port 9292 aufzurufen – Abbildungen 4 und 1 folgend also »http://100.95.102.77:9292« .

Der Entwickler kann jetzt auf seinem Rechner ganz normal an seiner Webanwendung weiterarbeiten. Dank des durchgereichten Projektverzeichnisses kommen Änderungen direkt in der Entwicklungsumgebung an, ein Neuladen der Seite im Browser sollte genügen. Wer seine Arbeit zum Feierabend unterbrechen muss, fährt die Entwicklungsumgebung kontrolliert mit »otto dev halt« herunter und am nächsten Tag mit »otto dev« wieder hoch.

Wolkenbildung

Um die fertige Anwendung in den Produktivbetrieb zu übernehmen, müsste ein Admin in einer Cloud einen virtuellen Server starten, auf diesem eine entsprechende Ruby-Umgebung einrichten und dort die Webanwendung installieren (Deployment). Auch diese Schritte übernimmt Otto. Die Version 0.1.2 kennt allerdings nur Amazons AWS-Cloud. Weitere Clouds beziehungsweise Zielsysteme sollen in späteren Versionen folgen. Geplant ist unter anderem eine Veröffentlichung als Docker-Container.

Um die eigene Webanwendung in der Amazon-Cloud zu starten, muss Otto diese zunächst einrichten. Diese Aufgabe übernimmt der knappe Befehl:

otto infra

Das Tool fragt zunächst nach dem Access und dem Secret Key (Abbildung 6). Beide erhält der Amazon-Nutzer, wenn er sich bei dem Dienst anmeldet [10], auf den eigenen Namen rechts oben in der Ecke klickt, »Security Credentials« wählt und dann unter »Access Keys« auf »Create New Access Key« klickt.

Abbildung 6: Nur bei der ersten Inbetriebnahme der Webanwendung in der Amazon-Cloud fragt Otto alle diese Informationen ab.

Auf die virtuellen Maschinen in der Amazon-Cloud greift Otto später via SSH zu. Dabei verwendet das Tool einen Schlüssel, den der Anwender gegebenenfalls mit »ssh-keygen« vorab auf seinem PC erzeugt. Der Admin muss Otto dann den Pfad zu der Datei mit dem öffentlichen Schlüssel übergeben, gewöhnlich ist dies »~/.ssh/id_rsa.pub« .

Damit der Anwender alle bis hierin abgefragten Daten nicht immer erneut eintippen muss, merkt Otto sie sich in einer verschlüsselten Datei. Das dazu notwendige Passwort denkt sich der Anwender im nächsten Schritt aus und tippt es ein. Nur wer dieses Passwort kennt, darf künftig die Webanwendung in die Cloud schieben.

Zum Schluss weist Otto seinen Gehilfen Terraform [11] an, die AWS für die Ausführung der Webanwendung vorzubereiten. Sofern Terraform nicht auf dem System verfügbar ist, bietet Otto die Installation an. Wer sich bei einer der Angaben vertippt hat, löscht im Unterverzeichnis »~/.otto.d/cache/creds/« die zum Projekt gehörende Datei (im Beispiel »otto-getting-started« ) und ruft »otto infra« erneut auf. Im Verzeichnis »~/.otto.d« landen alle Informationen über und Einstellungen für die Cloud, weshalb man auch dort möglichst keine Änderungen vornehmen sollte.

Wolkenkuckucksheim

Mit »otto status« erhält der Anwender einen Blick auf den aktuellen Deployment-Zustand. Wenn wie in Abbildung 7 der Punkt »Infra« auf »READY« steht, ist die Cloud für die Ausführung der Webanwendung eingerichtet.

Abbildung 7: In diesem Fall ist die Amazon-Cloud eingerichtet (»Infra: READY«). Zudem ist die passende virtuelle Maschine gebaut (»Build: BUILD READY«). Der User muss sie nur noch von Otto hochladen lassen.

Als Nächstes bereitet der Befehl »otto build« die Webanwendung auf das Deployment vor. Im Fall der AWS-Cloud verpackt Otto dabei die Webanwendung in ein Amazon Machine Image (AMI) und somit in eine virtuelle Maschine, die sich in der Amazon-Cloud starten lässt. Das Image erstellt im Hintergrund das Tool Packer [12], das Hashicorp für genau diese Aufgabe entwickelt hat. Sollte die aktuelle Packer-Version auf dem System fehlen, holt Otto sie nach.

Das Tool installiert im AMI automatisch die Webanwendung nebst den zur Ausführung benötigten Programmen. Für die Beispielanwendung sind das unter anderem die Ruby-Umgebung und ein Nginx-Webserver. Der Befehl »otto status« sollte anschließend neben »Build« ein »BUILD READY« melden wie in Abbildung 7. Damit ist die Webanwendung endlich bereit, in die Cloud zu wandern. Genau das initiiert »otto deploy« . Am Ende des Prozesses gibt Otto in giftgrüner Schrift die URL preis, unter der die Webanwendung zu erreichen ist. Vergisst der Entwickler die Adresse, hilft »otto deploy info« ihm auf die Sprünge.

Das Einrichten und Deployen dauern selbst bei kleinen Webanwendungen eine Weile, wobei manchmal mehrere Minuten lang nichts zu passieren scheint. In künftigen Otto-Versionen soll das Tool Nomad [13] sowohl das Zusammenstellen des AMI als auch das eigentliche Deployment übernehmen und beide Vorgänge drastisch beschleunigen.

Mit dem Befehl »otto deploy destroy« stoppt und zerstört der Anwender bei Bedarf die virtuelle Maschine in der Cloud, anschließend löscht »otto infra destroy« die Infrastruktur beziehungsweise gibt die bei Amazon reservierten Ressourcen wieder frei. Und »otto dev destroy« entfernt schließlich noch die lokale Entwicklungsumgebung.

Handgreiflich

Künftig muss der Entwickler mit »otto dev« lediglich die Entwicklungsumgebung hochfahren, dann nach seiner Arbeit mit »otto build« eine virtuelle Maschine für den produktiven Betrieb erstellen lassen und diese per »otto deploy« in die Cloud schieben. Um alles andere kümmert sich jetzt Otto – zumindest im optimalen Fall.

Nicht immer sind jedoch Automatismen erwünscht. Beispielsweise könnte die Webanwendung die Ruby-Version 2.1 verlangen. In solchen Fällen lässt sich Otto über eine Konfigurationsdatei steuern. Sie trägt den Dateinamen »Appfile« und liegt im Projektverzeichnis der Webanwendung. Ihr Aufbau folgt der Hashicorp Configuration Language (HCL, [14]), die wiederum Json entspricht. Listing 1 zeigt ein einfaches Beispiel für ein »Appfile« . Die Otto-Entwickler weisen allerdings darauf hin, dass sich der Aufbau noch stark ändern kann.

01 application {
02         name = "otto-getting-started"
03         type = "ruby"
04         dependency {
05                 source = "github.com/hashicorp/otto/examples/mongodb"
06         }
07 }
08
09 project {
10         name = "mein-projekt"
11         infrastructure = "meine-infrastructure"
12 }
13
14 infrastructure "meine-infrastructure" {
15         type = "aws"
16         flavor = "simple"
17 }
18
19 customization "ruby" {
20         ruby_version = "2.1"
21 }

Der erste Abschnitt »application« gibt der Anwendung zunächst einen Namen, in Listing 1 heißt sie »otto-getting-started« . Hinter »type« folgt die Art der Anwendung beziehungsweise die Programmiersprache. Neben Ruby unterstützt Otto derzeit Go, PHP und Node.js-Anwendungen, weitere Sprachen sollen folgen. Zudem gibt es noch den speziellen Typ »docker-external« , der einfach einen bereits fertigen Docker-Container startet. Das ist beispielsweise nützlich, um einen fertigen Dienst anzuwerfen, etwa den Apache Webserver.

Die meisten Webanwendungen benötigen eine Datenbank. Solche Abhängigkeiten notiert der Block »dependency« . Hinter »source« steht hier eine URL, die zu einem Verzeichnis mit einem Appfile führt. Das unter »github.com/hashicorp/otto/examples/mongodb« erreichbare Appfile verweist einfach auf ein Docker-Image mit der Datenbank Mongo DB. Otto würde folglich die Datenbank Mongo DB hinzuholen und starten. Es genügt dabei, die URL zur direkt benötigten Anwendung anzugeben, die für Mongo DB erforderlichen Abhängigkeiten löst Otto selbst auf.

Die URL darf auch auf eine Anwendung auf der Festplatte zeigen (mit der Notation »file:///home/tim/eineapp/« ). Auf diese Weise kann etwa ein Team sehr leicht die Anwendung eines anderen Teams einbinden. Die Macher von Otto planen zudem ein öffentliches Verzeichnis mit häufig benötigten Appfiles.

Das Auflösen und Integrieren der Abhängigkeiten bereiten Otto 0.1.2 allerdings noch massive Probleme. Mit Listing 1 gefüttert, wollte das Tool zwar einen Docker-Container mit Mongo DB einrichten, brach aber genau an dieser Stelle den Vorgang reproduzierbar ab. Grund war angeblich ein fehlgeschlagener SSH-Zugriff. Die unfertige virtuelle Maschine ließ sich jedoch manuell problemlos per »otto dev ssh« betreten.

Wenn die Installation der Abhängigkeiten klappt, sollen die entsprechenden Dienste laut Otto-Dokumentation eigene DNS-Namen erhalten. So wäre beispielsweise unter »mongodb.service.consul« die Datenbank Mongo DB zu erreichen. Im Hintergrund regelt die Namensvergabe das eigens zu diesem Zweck in jeder virtuellen Maschine eingerichtete Tool Consul.

Infrastrukturmaßnahme

In Listing 1 ordnet der mittlere Abschnitt »project« die Anwendung zunächst über die Einstellung »name« einem Projekt zu. Damit sollen sich künftig Webanwendungen in Projekten gruppieren lassen. Otto wertet diese Einstellung jedoch derzeit nicht aus.

Die gewünschte Cloud und die in ihr benötigten Ressourcen fasst Otto unter dem Begriff Infrastructure zusammen. Jede Infrastructure gibt es noch einmal in mehreren Geschmacksrichtungen (Flavors). Für die AWS-Cloud gibt es in Otto 0.1.2 die beiden Flavors »simple« und »vpc-public-private« . Standardmäßig verwendet das Tool die »simple« -Variante, bei der die virtuelle Maschine in der Cloud möglichst wenig Ressourcen beansprucht. Die »vpc-public-private« -Version richtet hingegen unter anderem automatisch ein privates Subnetz ein. Mit diesem Flavor skaliert die Webanwendung zwar einfacher, der Betrieb verursacht aber auch höhere Kosten.

Welche Infrastructure in welchem Flavor Otto nutzen soll, bestimmt der Abschnitt »infrastructure« . In ihm legt »type« das Zielsystem fest, »flavor« wählt eine Variante aus. In Listing 1 soll die Webanwendung in der Amazon-Cloud (»type = “aws”« ) auf nur einem einzelnen virtuellen Server starten (»flavor = “simple”« ). Diese Auswahl erhält noch einen beliebigen Namen, in Listing 1 »meine-infrastructure« . Dass Otto genau diese Infrastructure nutzen soll, teilt der Betreiber dem Tool im Abschnitt »project« hinter »infrastructure« mit.

Über einen »customization« -Block lässt sich schließlich noch die Entwicklungsumgebung beeinflussen. Dem Schlüsselwort »customization« folgt zunächst der Name des Anwendungstyps, im Beispiel handelt es sich um eine Ruby-Anwendung. Die dann innerhalb des »customization« -Blocks möglichen Einstellungen hängen von der entsprechenden Programmiersprache ab. Listing 1 legt dort beispielhaft fest, dass unbedingt Ruby in der Version 2.1 zum Einsatz kommen muss.

Ein geändertes oder neu erzeugtes »Appfile« wertet Otto erst dann aus, wenn der Anwender »otto compile« aufruft. Anschließend muss er gegebenenfalls die aktuelle Entwicklungsumgebung zerstören (»otto dev destroy« ) und eine neue erstellen (»otto dev« ). Die Entwickler verkaufen dieses »Recompiling« als Feature, denn Teammitglieder können am »Appfile« Änderungen vornehmen, ohne dass dies die laufende Entwicklungsumgebung beeinflusst.

Turbolader

Otto macht Lust auf mehr: Eine Handvoll Befehle setzt eine Entwicklungsumgebung auf und schiebt die fertige Anwendung in die Cloud. Unter der Haube rotieren bekannte und in der Praxis erprobte Tools wie Vagrant. Man merkt Otto den extrem frühen Entwicklungsstand allerdings noch deutlich an. Größte Mankos sind die fehlerhafte Auflösung von Abhängigkeiten und die Beschränkung auf Amazons Cloud. Die gute Dokumentation besteht zudem aus zahlreichen Versprechungen für geplante künftige Versionen [1].

Doch auch wenn Otto in der aktuellen Ausführung noch nicht ganz alltagstauglich ist, sollten besonders Devops-Anhänger einen intensiveren Blick auf das System werfen und dessen Weiterentwicklung beobachten – schließlich soll Otto nach dem Willen von Hashicorp langfristig Vagrant ersetzen.