© Jaromir-Urbanek, 123RF

Bereits seit 2010 arbeitet der Kalifornier Mitchell Hashimoto mit seiner Firma Hashicorp emsig an vier Open-Source-Tools. Vagrant & Co. erleichtern nicht nur die Arbeit von Devops, sondern helfen auch herkömmlichen Administratoren. Jedes Werkzeug löst dabei elegant eine ganz spezielle Aufgabe

Programmierer richten sich gerne selbst eine passende Umgebung für ihr Projekt ein. Das führt bei der Inbetriebnahme der fertigen Software allerdings häufig zu Problemen. So fehlen in der Produktivumgebung etwa benötigte Bibliotheken oder eine leicht veränderte Konfiguration führt zu unerwarteten Nebenwirkungen. Solchen Situationen beugt Vagrant vor [1]. Das Tool erstellt auf Knopfdruck eine virtuelle Maschine mit einer passenden Entwicklungsumgebung. Die erzeugten Maschinen sind nicht nur portabel, Vagrant kann sie auch immer wieder exakt reproduzieren. Fertige Maschinen lassen sich zudem an andere Teammitglieder weitergeben und bei Bedarf in die Produktionsumgebung umsiedeln.

Vagrant

Mitchell Hashimoto begann mit der Entwicklung an Vagrant zunächst in seiner Freizeit. Aufgrund der schnell wachsenden Nutzerzahlen gründete er im Herbst 2012 die Einmannfirma Hashicorp. Sie erlaubte es ihm, in Vollzeit an Vagrant weiterzuarbeiten. Geld verdient das Unternehmen heute vor allem durch Supportverträge, Schulungen und mit der Entwicklung kommerzieller Addons. Nutzer von Vagrant sind laut Hashicorp derzeit neben Mozilla und Disqus auch die BBC, O’Reilly und Expedia.

Um mit Vagrant eine Entwicklungsumgebung aufzusetzen, legt der Programmierer zunächst in seinem Projektverzeichnis eine kleine Konfigurationsdatei an. In diesem so genannten Vagrantfile beschreibt er die benötigte Software, konfiguriert die virtuelle Maschine und legt fest, wie er auf das Gastsystem zugreifen möchte. Ein PHP-Programmierer könnte sich zum Beispiel ein Debian-System mit einem Webserver wünschen.

Vagrant selbst arbeitet als Wrapper für eine Virtualisierungssoftware, den so genannten Provider. Vagrant unterstützt von Haus aus Virtualbox, Docker und Microsofts Hyper-V. Weitere Provider rüstet der Anwender über Plugins nach. Wer Vagrant mit VMware bekannt machen möchte, findet ein passendes Plugin bei Hashicorp [2]. Als kommerzielles Produkt schlägt es allerdings mit rund 80 Dollar pro Lizenz zu Buche.

Bewölkte Schachteln

Um möglichst schnell die virtuelle Maschine starten zu können, klont Vagrant einfach ein fertiges Festplattenimage und passt es anschließend an. Solche Basis-Images bezeichnet Vagrant als Boxes. Fertige Boxes lassen sich über die Community-Sammlung Vagrantbox.es ([3], Abbildung 1) oder die von Hashicorp betriebene Vagrant Cloud [4] kostenlos herunterladen. Auf Letzterer steht unter anderem auch eine virtuelle Maschine mit Debian 7.4 und vorinstalliertem Chef bereit.

Abbildung 1: Vagrantbox.es stellt Links zu öffentlich zugänglichen Vagrant-Boxen bereit. Ihr Einsatz setzt großes Vertrauen in deren Autoren voraus.

Wer sich in der Vagrant Cloud kostenlos registriert, kann zudem den Dienst Vagrant Share nutzen. Er bietet eine Art dynamischen DNS-Dienst für Boxes: Mit einem Kommandozeilenbefehl verbindet der Vagrant-Anwender eine gerade laufende virtuelle Maschine mit einer neuen Subdomain von Vagrantshare.com. Seine Entwicklungsumgebung ist dann beispielsweise über »http://hulking-chameleon-3934.vagrantshare.com« im Internet erreichbar.

Auf diese Weise kann man nicht nur die Anmeldung an der neuen Webanwendung mit Oauth unter realen Bedingungen testen, auch Teammitglieder in Außenstellen erhalten so Einblick in die laufende Entwicklung.

Wer selbst erstellte Boxes über die Vagrant Cloud nur bestimmten Personen zugänglich machen möchte, muss ein kostenpflichtiges Abonnement abschließen. Die Preise beginnen bei 6 Dollar pro Monat [5], jeder Download einer Box schlägt zusätzlich mit 12 US-Cent zu Buche (Abbildung 2). Wer der Vagrant Cloud nicht traut, kann selbstverständlich auch eigene Boxes erstellen.

Abbildung 2: Die Vagrant Cloud bietet kostenlos praktische Dienste für Boxes, aber auch zu bezahlende Extras.

Ruby-gesteuert

Innerhalb des Vagrantfile erfolgt die Konfiguration über Ruby-Code, Anwender müssen jedoch nicht die komplette Skriptsprache beherrschen. Listing 1 zeigt als Beispiel eine minimale Konfigurationsdatei: Die zweite Zeile legt mit »config.vm.box = “ubuntu/trusty64″« fest, dass eine Box aus der Vagrant Cloud mit Ubuntu 14.04 Server in der 64-Bit-Variante zum Einsatz kommen soll. Die dritte Zeile richtet zudem Port-Forwarding ein, wodurch der Webserver im Gast auch auf dem Wirtsrechner über den Port 9999 zu erreichen ist.

01 Vagrant.configure("2") do |config|
02   config.vm.box = "ubuntu/trusty64"
03   config.vm.network :forwarded_port, host: 9999, guest: 80
04 end

Sobald der Entwickler das Vagrantfile an seine Bedürfnisse angepasst hat, reicht ein Aufruf des Kommandos »vagrant up« – und schon sitzt er vor der fertigen virtuellen Maschine. Ein hinterhergeschobenes »vagrant ssh« öffnet eine SSH-Verbindung in das Gastsystem. Wer schon einmal eine virtuelle Maschine per Hand nebst SSH-Zugang eingerichtet hat, dürfte jetzt freudig in die Hände klatschen. Die Konfigurationsdatei lässt sich obendrein einfach an andere Teammitglieder weitergeben.

Beim ersten Start der virtuellen Maschine kann Vagrant automatisch beliebige Befehle und Programme ausführen. Auf diese Weise lässt sich per Shellskript etwa ein Webserver nachinstallieren und passend einrichten. Das ermöglicht schnelle und einfache Provisionierung.

Vagrant startet aber nicht nur Shellskripte, sondern arbeitet auch direkt mit den Konfigurationssystemen Chef, Puppet, Ansible, Salt und der CF Engine zusammen. Auf Wunsch erstellt das Tool sogar Docker-Container. Mit Plugins lassen sich weitere dieser so genannten Provisioners nachrüsten.

Das Projektverzeichnis des Entwicklers reicht Vagrant standardmäßig an die Gastmaschine durch, wo es im Verzeichnis »/vagrant« auftaucht. Analog synchronisiert das Tool beliebige weitere Verzeichnisse auf der Festplatte mit einem anderen in der virtuellen Maschine (Synced Folders). Auf diese Weise sieht der Entwickler die Auswirkungen einer Änderung direkt im Dateisystem.

Das Devops-Werkzeug Vagrant gibt es neben Linux auch für Windows und Mac OS X. Auf der Homepage stehen fertige Pakete im Debian- und RPM-Format bereit. Darüber hinaus liegt das Tool auch in den Repositories einiger Distributionen. Ubuntu bietet allerdings nur die etwas ältere Version 1.4.3 an. Vagrant selbst ist in Ruby geschrieben, eine Installation als Rubygem ist bei aktuellen Vagrant-Versionen jedoch nicht mehr vorgesehen. Das Tool steht unter der liberalen MIT License, der Quellcode liegt offen auf Github [6].

Packer

Meist bietet es sich an, die fertige Anwendung direkt als virtuelle Maschine bereitzustellen (Appliance). Das artet schnell in Arbeit aus, wenn die Kunden unterschiedliche Virtualisierungslösungen nutzen. Genau hier springt Packer ein [7]. Das Werkzeug richtet nicht nur automatisch eine virtuelle Maschine passend ein, sondern baut auch noch parallel Images für die Clouddienste Amazon EC2, Digital Ocean, Googles Compute Engine und Open Stack sowie die Virtualisierungslösungen Virtualbox, VMware, Qemu (für KVM und Xen), Parallels und Docker. Auf Wunsch erzeugt Packer auch eine Box für Vagrant. Über Plugins lässt sich die Unterstützung für weitere Plattformen nachrüsten. Zur Einrichtung des Gastsystems kann Packer zudem Chef und Puppet einspannen.

Zip-Archiv

Anders als Vagrant stellt Hashicorp das Programm Packer als distributionsunabhängiges Zip-Archiv bereit. Dabei gibt es jeweils eine Variante für 32-Bit-, 64-Bit- und ARM-Systeme. Neben Linux läuft Packer auch unter Windows, Max OS X, Free BSD und Open BSD. Installieren muss der Entwickler das Tool per Hand, indem er den Inhalt des Zip-Archivs in ein passendes Verzeichnis verschiebt, unter Linux etwa nach »/usr/local/bin« . Der Quellcode ist in der Programmiersprache Go verfasst, lagert auf Github [8] und unterliegt der Mozilla Public License in der Version 2.0.

Die gewünschten Ausgabeformate und den Inhalt der virtuellen Maschine beschreibt der Entwickler in einer Konfigurationsdatei im Json-Format. Ein Beispiel für ein solches Template zeigt Listing 2. Die obere der beiden Sektionen legt dabei fest, wie Packer das oder die Images erstellen soll. Den Bau eines Image übernimmt dabei ein so genannter Builder, der auf ein ganz bestimmtes Ausgabeformat spezialisiert ist.

01 {
02 "builders": [{
03         "type": "virtualbox-ovf",
04         "source_path": "debian7.ovf",
05         "ssh_username": "root",
06         "ssh_password": "123456",
07         "ssh_wait_timeout": "30s",
08         "shutdown_command": "echo 'Fertig' | sudo -S shutdown -h now"
09         }],
10 "provisioners": [{
11         "type": "shell",
12         "inline": [
13                 "sleep 30",
14                 "sudo apt-get update",
15                 "sudo apt-get install -y sqlite3"
16                 ]
17         }]
18 }

Listing 2 aktiviert in der dritten Zeile einen Builder namens »virtualbox-ovf« . Er nimmt zunächst ein vorhandenes Image im Austauschformat OVF, das den Dateinamen »debian7.ovf« trägt. Von diesem zieht der Builder eine Kopie, die er anschließend mit Virtualbox startet (Abbildung 3).

Abbildung 3: Packer spannt hier Virtualbox ein, um das fertige Image zu bauen.

Die jetzt folgende Konfiguration des Gastsystems übernehmen wie bei Vagrant so genannte Provisioners. Listing 2 startet den Shell-Provisioner, der die Befehle in den Zeilen 13 bis 15 ausführt. Die wiederum installieren SQlite im Gastsystem. Die Anmeldung erfolgt dabei via SSH mit dem Benutzernamen »root« und dem Passwort »123456« . Diese Informationen verrät Listing 2 in den Zeilen 5 und 6. Mit dem »shutdown_command« kann Packer die virtuelle Maschine anschließend geordnet herunterfahren.

Frisch aus dem ISO

Zum Abschluss übernimmt noch einmal der Builder, der das Gastsystem wieder ins OVF-Format exportiert. Neben »virtualbox-ovf« bringt Packer weitere Builder mit. Beispielsweise erzeugt »virtualbox-iso« mit Virtualbox eine komplett neue virtuelle Maschine und installiert darin ein frisches System. Als Quelle dient ein ISO-Image, das er von einem Server herunterlädt und dabei sogar die Checksumme prüft. Das Ganze funktioniert allerdings nur, wenn die komplette Installation ohne Benutzereingaben auskommt. Wer mag, kann eigene Builder und Provisioners über das Plugin-System nachrüsten.

Consul

Gewöhnlich impft ein Entwickler seiner Anwendung fest ein, auf welchem Rechner sie die Datenbank findet. Alternativ könnte das Programm aber auch Consul befragen [9]. Dieser Dienst gibt Auskunft darüber, welche anderen Dienste gerade wo verfügbar sind, dient also als Service Discovery. Zusätzlich bietet Consul eine Failure Detection, kann also laufende Dienste und das System überwachen. So schlägt das Tool beispielsweise Alarm, wenn der Webserver auf wiederholte Nachfrage nur noch den HTTP-Status 200 zurückliefert oder der verfügbare Hauptspeicher plötzlich knapp wird.

Die dazu notwendigen Tests beschreibt der Administrator über entsprechende Regeln. Erkennt Consul ein Problem, kann es anfragende Anwendungen automatisch auf andere, noch laufende Server umleiten. Die Webanwendung würde dann noch nicht einmal mitbekommen, dass die Datenbank auf dem Hauptserver ausgefallen ist.

Abschließend offeriert Consul noch einen Key-Value-Store. In dieser Mini-Datenbank sollen vor allem Anwendungen ihre Konfigurationsdaten im Json-Format ablegen. Über den Key-Value-Store können verteilte Anwendungen auch Daten austauschen und so beispielsweise untereinander einen Master küren. Die Abfrage der Daten erfolgt dabei über eine REST-ähnliche HTTP-Schnittstelle.

Agenten im Einsatz

Consul selbst besteht aus mehreren Komponenten. Die Grundlage bilden ein oder mehrere Consul-Server. Sie speichern die Informationen über die laufenden Dienste und beantworten Anfragen von Anwendungen. Hashicorp empfiehlt, mindestens drei bis fünf Consul-Server aufzusetzen, um die Datensicherheit zu erhöhen.

Die Consul-Instanzen bilden selbstständig einen Cluster und wählen gleichzeitig einen Anführer (Leader), der die Koordination übernimmt. Wer mehrere Rechenzentren betreibt, kann in jedem einen eigenen Cluster einrichten. Vermag ein Consul-Server die Anfrage einer Anwendung nicht zu beantworten, leitet er sie an die anderen Cluster weiter und liefert die von dort kommende Antwort an die Anwendung zurück.

Ergänzend darf der Admin auf weiteren Rechnern Consul-Server starten, die einfach nur alle an sie gestellten Anfragen an die richtigen Consul-Server weiterleiten. Das soll unter anderem die Lastverteilung vereinfachen. Die kastrierten Consul-Server bezeichnet Hashicorp verwirrenderweise als Clients. Anwendungen können direkt bei einem Consul-Server, aber auch bei Consul-Clients anklopfen.

Consul selbst ist wie Packer in Go geschrieben und steht unter Mozilla Public License 2.0. Der Quellcode ist auf Github zu finden [10], fertige Pakete stehen für Windows, Mac OS X und Linux bereit. Wie bei Packer gibt es hier ebenfalls nur ein Zip-Archiv, das lediglich ein Kommandozeilen-Programm enthält. Dieser so genannte Agent startet je nach übergebenen Parametern entweder als Consul-Server oder -Client.

Ergänzend bietet Hashicorp eine simple Benutzeroberfläche in Form einer Webanwendung an (Abbildung 4). Informationen lassen sich einem Consul-Server entweder über dessen HTTP-Schnittstelle oder seinen eingebauten DNS-Server entlocken (Abbildung 5).

Abbildung 4: Über die Consul-Webanwendung erhalten Devops-Praktiker schnell einen Überblick über die ausgefallenen und laufenden Dienste. Hier ist alles sichtlich im grünen Bereich.

Abbildung 5: Die beiden Befehle holen Informationen über den Dienst »web« ein. Der erste Befehl nutzt die HTTP-Schnittstelle, der zweite den eingebauten DNS-Server des Consul-Servers.

Serf

Fällt der Webserver im Produktivbetrieb aus, entgeht dem Betreiber eines Onlineshops schnell sehr viel Umsatz. Wer es gar nicht so weit kommen lassen möchte, greift zu Serf [11]. Das Tool beobachtet die Rechnerknoten in einem Cluster. Sobald einer von ihnen ausfällt, führt es eine vom Administrator vorgegebene Aktion aus. Streikt etwa ein Webserver, kann Serf automatisch den vorgeschalteten Load Balancer benachrichtigen, der dann wiederum die Last auf andere Webserver verteilt.

Serf selbst ist als verteiltes System ausgelegt: Zunächst installiert der Administrator auf jedem einzelnen Rechnerknoten einen Serf-Agenten. Diese Agenten überwachen ihre jeweiligen Nachbarn im Cluster. Sollte einer von ihnen ausfallen, alarmieren sie die noch funktionierenden Agenten, die dann wiederum ihre Nachbarn benachrichtigen.

Die Serf-Dokumentation vergleicht das Vorgehen mit einer Zombie-Invasion: Es startet mit einem Zombie, der dann schnell alle anderen noch gesunden Personen infiziert. Auf diese Weise erfahren binnen kürzester Zeit sämtliche Agenten eines Clusters von dem Ausfall. Das Verfahren bietet zudem den Vorteil, dass es beliebig und effizient skaliert.

Die Agenten benutzen zur Kommunikation untereinander ein Gossip-Protokoll, das UDP-Nachrichten verschickt. Admins müssen folglich entsprechende Löcher in ihre Firewall bohren. Abschließend soll jeder Agent gerade mal 5 bis 10 MByte Hauptspeicher in Beschlag nehmen.

Radiosender

Serf kann nicht nur feststellen, ob Knoten ausgefallen sind, sondern auch vom Administrator vorgegebene Ereignisse aussenden. Diese Ereignisse lösen dann wiederum auf den Knoten bestimmte Aktionen aus. Beispielsweise könnten die Knoten auf ein Signal hin nach Updates suchen und diese einspielen.

Serf ist ebenfalls in Go geschrieben und untersteht der Mozilla Public License 2.0. Der Quellcode ist auf Github [12] erhältlich, fertige Pakete gibt es für Windows, Mac OS X, Free BSD, Open BSD und Linux – für Linux steht neben einer x86- und einer x86_64-Variante auch eine ARM-Version bereit.

Die Inbetriebnahme und Bedienung von Serf ähneln stark der von Consul: Auch hier findet der Administrator im Zip-Archiv gerade mal ein Kommandozeilen-Programm, den Agenten. Den startet er auf jedem zu überwachenden Knoten und macht dann die laufenden Agenten miteinander bekannt. Dafür reicht es schon aus, jedem Agenten lediglich einen Nachbarn vorzustellen, die übrigen entdeckt er automatisch.

Hashicorp hat vier äußerst nützliche Tools für den Devops-Lifecycle im Angebot: Vagrant hilft bei der Entwicklung, Packer beim Deployment, während Consul und Serf den Betrieb und die Wartung vereinfachen. Die Bedienung der Tools ist zudem extrem simpel: Bei Vagrant etwa reicht ein einziger Kommandozeilen-Befehl, um eine definierte Entwicklungsumgebung zu starten.

Breite Unterstützung

Vorbildlich ist auch die von Hashicorp bereitgestellte Dokumentation. Sie ist für alle vier Tools vollständig, umfassend und vor allem auch verständlich geschrieben. Einführungen helfen zudem bei den ersten Schritten. Noch offene Fragen klären Anwender in den entsprechenden Google Groups oder in IRC-Chats auf Freenode. Für Vagrant lautet der IRC-Channel »#vagrant« , die Vagrant Google Group findet sich unter [14]. Der Verlag O’Reilly hat ein Buch über Vagrant herausgegeben, als Autor grüßt kein anderer als Mitchell Hashimoto [15].