Whoops. Ein Produktlaunch und ein paar Tage fiese Erkältung später, und der letzte Beitrag hier ist schon drei Wochen vorbei. Sorry. :)

Nach dem eher allgemeinen Teil 1 und Teil 2 zu Chef nun endlich zum spannenden Teil: Wie nutzt man den Kram eigentlich?

Wie auch die Entwicklung einer Webapp startet diese Frage bei der Entwicklungsumgebung. In den meisten Projekten, in denen ich bislang meine Nase hatte, gab es meist einen von zwei Ansätzen für die Entwicklungsumgebung: Entweder gab es ein Image für eine Virtualisierungsumgebung, das herumkopiert worde, oder es wurde direkt auf der Host-Maschine ein mehr oder weniger klassischer LAMP-Stack installiert, konfiguriert, und damit entwickelt. Ein gern gesehener Gast hier war zum Beispiel XAMPP.

Mit Chef haben wir nun den Vorteil, dass das Setup der Server jederzeit gescripted reproduziert werden kann – und genau das nutzen wir auch für unsere Entwicklungsumgebung. Mit Vagrant kann vollautomatisch eine Instanz in Virtualbox initialisiert und installiert werden. Damit kann jederzeit mit drei Befehlen eine neue VM aufgesetzt werden, die im Setup und Konfiguration sehr ähnlich zur Live-Umgebung ist. Vagrant existiert für Linux, Windows, OSX und Solaris.

Vagrant ist sehr einfach zu installieren: Zunächst muss Virtualbox installiert werden. Virtualbox ist die eigentliche virtuelle Umgebung, in der der virtuelle Server später ausgeführt wird. Ebenfalls gebraucht wird ruby – aber ich gehe mal davon aus dass jeder Entwickler das sowieso auf seinem Server schon sauber konfiguriert hat ;) Anschliessend wird vagrant mit “gem install vagrant” installiert – alternativ kann vagrant auch mit Installationspaketen installiert werden, mehr dazu auf der Vagrant-Website.

Die Konfiguration der VM von Vagrant wird in einer Datei Vagrantfile festgelegt. Unsere Konfiguration bei Digital Pioneers sieht in etwa so aus:

Mit dieser Datei lässt sich eigentlich der Server auch schon direkt mit vagrant up starten und aufsetzen. Wichtig sind hier allerdings einige Pfade, die entsprechend angepasst werden müssen:
chef.cookbooks_path ist der Pfad zu den Chef-Cookbooks, die von Vagrant ausgeführt werden sollen. Ausserdem werden zwei Verzeichnisse mit der Host-Maschine geteilt: webdev ist relativ logisch: In diesem Mount befindet sich der Code der App, die wir entwickeln. aptcache ist dagegen ein “Hack” – die von Ubuntu heruntergeladenen Pakete werden dadurch auf der Host-Maschine gespeichert. Damit müssen bei einem zweiten Aufsetzen der Virtuellen Maschine nicht erneut alle Pakete heruntergeladen werden, sondern werden direkt aus dem Cache installiert. Bonustipp: In dem Verzeichnis muss sich das (leere) Verzeichnis “partial” befinden, sonst fällt apt auf die Nase.

Durch das Portforwarding kann dann mit einem Zugriff auf http://localhost:8080 der Webserver der virtuellen Maschine erreicht werden.

Vagrant ist relativ selbsterklärend, und auch gut erklärt – vor den ersten Schritten mit Vagrant lohnt es sich aber trotzdem, den “Getting started”-Teil der Doku von Vagrant querzulesen, da hier die wichtigsten Kommandos vorgestellt werden.

Im Entwicklungsalltag bei uns hat sich gezeigt, dass Vagrant zwar durchaus seine Ecken und Kanten hat: Insbesondere die Datei-Mounts, über die Daten zwischen Hostmaschine und der VM geteilt werden können ziemlich zickig sein. Auch fehlt beispielsweise ein sinnvolles Vagrant-Plugin, mit dem direkt von aussen verschiedene Shell-Kommandos in der VM ausgeführt werden können, wie etwa Unittests oder die Generierung von Sass-Assets.

Allerdings sind die Vorteile von Vagrant klar überwiegend: Mit Vagrant können wir mit wenigen Kommandos die Entwicklungsumgebung wieder auf den ursprünglichen Zustand zurücksetzen, das Setup der Entwicklungsumgebung und der produktiven Server wird parallel vorangetrieben, und die Einführung in ein neues Projekt ist sehr viel weniger aufwendig.

(Zu Teil 1)

Chef ist ein Produkt von Opscode, mit dem in Ruby-Scripten die Konfiguration eines Systems definiert wird. Grob gesagt also eine Art “Template Engine für den Systemadministrator”.

Ein anderes häufig genutztes Produkt für diesen Anwendungsbereich ist Puppet. Die Diskussion, welches Tool hier nun besser ist, erinnert an die klassische vi vs. emacs-Debatte – vor der Entscheidung für das eine oder andere Tool als am besten beides einmal näher ansehen, und das geeignetere nutzen. Wir nutzen Chef. Ymmv.

Chef in a nutshell sieht so aus, dass man zunächst in “cookbooks” die einzelnen Dienste und Services seiner Infrastruktur definiert, und die nötigen Schritte für die Installation und Konfiguration darin festlegt. Anschliessend können diese Cookbooks dann auf einem Server verteilt und automatisch ausgeführt werden. Für die Verteilung und Ausführung gibt es verschiedene Mechanismen und Anbieter. Teilweise direkt bei Opscode, zum Teil auch darauf aufbauende Varianten, wie Vagrantup und Scalarium, die wir nutzen.

Dies hat für uns zwei wichtige Vorteile: Das Setup der Server und auch alle Konfigurationsänderungen werden in den Cookbooks durchgeführt, die in einem Git-Repository liegen. So haben wir die Konfiguration der Server komplett in einer Versionsverwaltung, in der sofort sichtbar ist, was wann geändert wurde, und auch weshalb. Das klassische Szenario eines “Quickfix in /etc/irgendwo”, der dann vom nächsten Admin übersehen wird, sollte so nicht mehr vorkommen.
Ausserdem ist das Setup so automatisiert möglich: Wenn wir einen weiteren Server für unsere Infrastruktur benötigen, reichen vier Mausklicks bei Scalarium, und zehn Minuten später steht ein fertig installierter und konfigurierter Server zur Verfügung. Gerade unter Zeitdruck erspart das viel Arbeit, und vermeidet Flüchtigkeitsfehler ( – oder eben in dem Moment, an dem der Admin nachts um halb vier aus dem Bett geklingelt wird, weil irgend etwas an die Wand gefahren ist..)

Wie genau Chef funktioniert, und wie Cookbooks aussehen, ist schon an vielen anderen Stellen gut beschrieben worden. Ein netter Einstieg mit Codebeispielen sind zum Beispiel diese Vortragsslides vom Easterhegg 2011, detaillierte Dokumentation gibt es direkt im Opscode-Wiki, und eine ganze Handvoll guter Tipps und Hinweise finden sich bei Till.

Bei unseren ersten Schritten mit Chef hat sich auch gezeigt, dass man Chef am schnellsten versteht, wenn man einfach mal losläuft, und ausprobiert. Sehr hilfreich ist wie so oft, da fremden Code zu lesen. Eher komplexe Beispiele hat es in den Cookbooks von Opscode, viel findet sich auch bei easybib, und erste kleine Rezepte auch bei uns.

Hier wird auch ein weiterer Vorteil von Chef sichtbar: Durch die standardisierte Form der Cookbooks kann man einfach Cookbooks tauschen und weiterentwickeln. So muss man nicht ständig das Rad neu erfinden, sondern kann Hilfsscripte und das Basis-Setup von anderen erfahrenen Admins übernehmen und damit weiterarbeiten. Ein Ansatz, der Programmierern der Open Source Welt als völlig selbstverständlich vorkommen dürfte, und den ich für die Administration mindestens genauso grossartig finde.

Im nächsten Teil der Serie dann Schluss mit der Theorie: Wir setzen uns eine Entwickler-VM mit Chef und Vagrant auf. Wer schon einmal auf eigene Faust mit Vagrant losspielen will: Bitte sehr.

(PS: Digital Pioneers sucht dringend fitte Entwickler und Administratoren – da gibts dann Chef jeden Tag im Büro)

Digital Pioneers, mein Arbeitgeber, entwickelt regelmässig Prototypen von Web-Applikationen, um Business-Modelle zu evaluieren. Wenn sich abzeichnet, dass ein Produkt erfolgreich wird, wird das Projekt in ein eigenes Unternehmen ausgegründet, und dort weitergetrieben.

Das hat natürlich auch Auswirkungen auf unsere Entwicklung und Administration: Eine der Herausforderungen in diesem Ansatz liegt darin, dass wir ein neues Team in ein wachsendes erfolgreiches Startup einarbeiten müssen, und anschliessend sukzessive Betrieb und Entwicklung komplett an das Team übergeben.

Um hier möglichst wenig Reibungsverluste bei der Übergabe zu haben, setzen wir auf Tools und Methoden, die auch gleichzeitig als Qualitätssicherung und Dokumentation dienen. Neben automatisierten Tests ist hier vor allem unser Deployment-Setup wichtig: Alle Server werden automatisiert mit Chef administriert. Wir haben dadurch eine ganze Menge Vorteile gegenüber der klassischen “händischen” Administration:

• Administration als Code: Konfiguration der Server werden als Ruby-Scripte und Templates verwaltet. Dadurch gibt es ein Versionierung, Änderungen in der Konfiguration sind so dokumentiert und können auch problemlos rückgänging gemacht werden
• Synchrone Konfiguration: Die virtuellen Maschinen, in denen die einzelnen Entwickler programmieren, werden mit den gleichen Konfigurationen beschickt, die auch die produktive Umgebung betreiben. So gibt es hier keine unvorhersehbaren Probleme durch unterschiedliche Versionen oder Modulkonfigurationen.
• Reproduzierbare Administration: Setup der Server findet grösstenteils automatisiert statt. Wer schon einmal nach einer Feier nachts um vier in einer Root-Shell etwas reparieren musste weiss, wieviel Sicherheit es gibt, wenn die Scripte die Detailarbeit übernehmen. Auch Setup mehrerer gleicher Server hintereinander wird einfacher und schneller.
• Logging im Betrieb: Jedes Ausführen eines Deployments oder anderen Änderung wird protokolliert. Damit ist klar, wer wann etwas geändert hat, und warum.

In den nächsten Tagen werde ich kurz vorstellen, was Chef eigentlich ist, wie wir unsere Entwicklungs-Maschinen mit Vagrant realisieren, das produktive Setup mit Scalarium, und zuletzt einmal als Beispiel das Setup einer Symfony2-Applikation näher beschreiben.

Einige der in den nächsten Teilen beschriebenen Cookbooks haben wir auch bereits als Open Source released – more to follow.

Kurznotiz eigener Sache: Nach sechs tollen Jahren in Berlin, drei Jahren als Freelancer, und mit der Diplomarbeit in der Zielgeraden, geht es bei mir bald auf zu neuen Ufern. Ich werde am 15. Januar als “Head of Engineering” bei Digital Pioneers in Hamburg anfangen, und da eine Menge spannender Dinge in einem tollen Unternehmen tun.

Da die Wohnungssituation in Hamburg allerdings ganz schön gruselig ist, werde ich zunächst meine Wohnung in Berlin behalten, und in Hamburg nur eine kleine möblierte Wohnung nehmen.

Mittelfristig werde ich dann aber komplett nach Hamburg ziehen, daher das übliche Anliegen: Ich suche eine Wohnung in Hamburg.

Ich nutze für mich und ein paar andere Accounts einen privaten Jabber-Server. Die letzten Jahre habe ich hier auf ejabberd gesetzt. ejabberd funktioniert solide – allerdings ist ejabberd äusserst zickig, sobald einmal ein Problem auftritt. So sind Debug-Meldungen, falls ejabberd mal nicht starten möchte, unglaublich selbsterklärend, und verschluckt sich gern auch an Dingen, die nicht unbedingt naheliegend sind. So ist es zum Beispiel ein echtes Problem, wenn der Hostname der Maschine sich ändert.

Da es in der letzten Zeit für einige User nun zu Verbindungsproblemen mit Google bzw Gmail kam, und ich keine Lust mehr hatte, mich nochmal mit der Erlang-Hölle der geschweiften Klammern herumzuschlagen, habe ich mich nun nach einem Ersatz umgesehen. Dabei bin ich über den in LUA geschriebenen Jabber-Server Prosody gestolpert, und habe ihn gleich ausprobiert.

Migration
Die Migration war verblüffend einfach. Eine Installationsanleitung findet sich auf den Seiten von Prosody. Diese Anleitung nachvollziehen, anschliessend noch die gut kommentierte Config einmal mit einem Text-Editor durchgehen, und der Jabber-Server läuft.

Zur Migration der User-Daten von ejabberd nach prosody sind ebenfalls nur wenige Schritte nötig. Vorher muss allerdings das Script ejabberd2prosody.lua noch organisiert werden: Aus mir unverständlichen Gründen hat dieses Script nicht den Weg ins Ubuntu-Paket geschafft, sondern ist nur im Source von prosody zu finden. Direktlink zum Script für prosody 0.8 ist dieser hier.

• Zuerst der Export der ejabberd-Benutzerdatenbank: ejabberdctl dump export.dump (Hierfür muss ejabberd noch laufen!).
• Anschliessend in einem leeren Verzeichnis: lua ejabberd2prosody /var/lib/ejabberd/export.dump – oder wo auch immer das .dump File von ejabberd hingelegt wurde – ausführen.
• Das ejabberd2prosody-Script baut nun zwei Dinge: Eine Art “diff” für das Prosody-Config, mit der die VirtualHosts und Einstellungen von ejabberd übernommen werden, sowie ein Verzeichnis data, in dem die Accounts und Metadaten liegen. Der Inhalt(*) dieses Verzeichnis muss nun nach /var/lib/prosody/ (unter Ubuntu/Debian – das Verzeichnis könnte unter Umständen bei anderen Systemen ein anderes sein).
• Dann noch ein restart, und alles läuft wie gehabt.

Erste Erfahrungswerte
Ich bin bislang zufrieden: Configdateien, Source des Servers und selbst die Storage-Daten sind in einem Format, das man mit less und Co betrachten und auch verstehen kann. Der Umstieg war eine Sache von 10 Minuten ohne jegliche Probleme. Das Commandline-Tool prosodyctl ist leider sehr viel einfacher als ejabberdctl – aber über die Jabber Service Discovery kann man auch bei prosody eigentlich alle relevanten Einstellungen und Informationen abgreifen. Prosody bietet auch noch eine Fülle an Modulen, mit denen man die Funktionalität erweitern kann – da LUA eine relativ einfache Sprache ist, dürfte man hier im Zweifelsfall auch seine eigene Erweiterung stricken können.

Prosody ist sicher nicht der Jabber-Server für jeden – gerade im “heavy duty” Bereich wird er vermutlich nicht so gut wie ejabberd abschneiden. Stichworte wie Skalierung und Verteilung dürften für Prosody vermutlich eher Fremdworte sein. Aber gerade für meinen Einsatzbereich, die klassische Nerd-Maschine mit einer Handvoll Accounts, ist es wesentlich angenehmer zu benutzen und zu debuggen. Wenn also nicht noch irgendwann ein unerwartetes Problem auftritte, kann ich auf jeden Fall Prosody weiterempfehlen.

Irgendwann kommt der Moment, an dem man feststellt, dass man doch regelmässig Dinge (be)schreiben möchte, die nicht in 140 Zeichen passen.