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)