Was die Haushaltsversicherung in Hinblick auf Wasserschäden sicher etwas nervös macht, können wir als Drupal Developer völlig risikofrei und mit garantiert trockenen Socken in Angriff nehmen. Konkret wollen wir den vom OS mitgelieferten Apache, beziehungsweise LAMP/WAMP/MAMP, durch eine lokale BOA Instanz ersetzen. Im Rahmen dieser mehrteiligen Blogreihe stellen wir das System vor und erklären Schritt für Schritt, wie man es auf dem eigenen Rechner konfiguriert.

Von Raubfischen und Kopffüßern

Wer mehrere Drupal Webseiten betreibt und bestrebt ist seine Arbeitsabläufe zu beschleunigen, der stößt unweigerlich auf Aegir. Aegir ist ein Hostingsystem, das selbst auf Drupal basiert und dabei hilft, mehrere Drupal Installationen zu verwalten.

Aegir makes it easy to install, upgrade, deploy, and backup an entire network of Drupal sites.

Klingt spannend, ist es auch! Automatische Backups, Migration ganzer Webseiten, kollektive Updates, Seiteninstallation per Mausklick, [Drush] Integration – das lässt das Administratorherz höher schlagen. Eine vollständige Auflistung und Erklärung aller Aegir Features würde allerdings den Rahmen dieses Beitrags sprengen. Wer sich dafür interessiert, wird um die [Aegir Community Seite][community] ohnehin nicht herum kommen.

Drupal in Drupal in …?

Wer jetzt schon im Geiste mit [Inception] Metaphern um sich wirft, der möge sich noch einen Moment gedulden. Der Name des BOA-Projekts, mit dem wir uns eigentlich beschäftigen, steht für Barracuda Octopus Aegir. Und es handelt sich dabei um nicht weniger als ein System zum Verwalten mehrerer Aegir Instanzen.

Kein Scherz.

Genau genommen ist BOA ein Shellskript, das eine nackte Linux Maschine (Vorzugsweise Ubuntu 12.0.4) von Grund auf in ein High-Performance Drupal Hostingmonster verwandelt. Und in der wiederum können mehrere Instanzen von Aegir gehostet werden, die wiederum mehrere Drupal Plattformen betreiben, in der wiederum mehrere Drupal-Seiten laufen. Das sind verdammt viele „wiederum“ für einen Satz. Um das Konstrukt im Ganzen zu erfassen, rollen wir es von aussen nach innen auf und definieren auch gleich die Begriffe, die uns weiter begleiten werden.

  • Barracuda: Das Shellscript, welches mit Root-Rechten in einer Vanilla Installation von Ubuntu oder Debian ausgeführt wird und den kompletten Server Stack von der Datenbank bis zum HTTP-Server konfiguriert.
  • Octopus: Ein weiteres Shellscript, das eine Aegir-Installation innerhalb von Barracuda, inklusive SSH/SFTP Zugängen für Developer und eine separate Administrationsoberfläche einrichtet.
  • Platform: Unter Platform versteht man im Grunde den Quellcode einer Drupal Distribution, die innerhalb einer Octopus Instanz betrieben wird. Das ist die Ebene auf der man operiert, wenn Drupal klassisch, also ohne BOA, installiert.
  • Site: Hierbei handelt es sich um das ganz normale Multisite-Verhalten einer Drupal Installation. Der einzige Unterschied ist, dass das Hostmaster-Interface von Aegir die Installation neuer Seiten direkt über das Administrationsmasken ermöglicht.

Technologie

Die genauen Eckdaten können der Projektseite von Barracuda entnommen werden. An dieser Stelle nur die wichtigsten Punkte:

  • NGINX: Barracuda setzt nicht auf dem altbekannten Apache Webserver auf, sondern nutzt NGINX. Dabei handelt es sich um eine deutlich schlankere, spezialisiertere und – speziell beim ausliefern von statischen Inhalten – sehr viel schnellere Alternative.
  • MariaDB: Drop-In Replacement für MySQL, das auf der einen Seite einige Performanceverbesserungen enthält, und gleichzeitig – im Gegensatz zu MySQL – vollständig Open Source lizenziert ist.
  • PHP-FPM/APC: Prozessoptimierung und Opcode Caching für PHP.
  • Redis: Performanter Key-Value Store, der für Cache-Bins in Drupal verwendet werden kann.
  • Tomcat und Solr: Richtig, die Katze sitzt gleich mit im Aquarium! Richtig tollen Suchfunktionen steht nichts mehr im Wege.

Und wozu das Ganze?

Um Drupal zu hosten, klingt es natürlich toll. Wir selbst betreiben unseren Server mit dieser Software, Omega8.cc – die Schöpfer von BOA – verkaufen nicht umsonst professionelles Hosting auf dessen Basis und auch Branchengrößen wie Pantheon bauen auf ähnlicher Technologie auf. Warum man sich alles nach Hause auf den eigenen Rechner holen sollte, erschließt sich allerdings nicht sofort. Folgende Gründe haben mich dazu bewogen:

  • „Auf meiner Maschine funktioniert es.“ Überraschungen beim Deployment sollten wegfallen, da wir zum Entwickeln dasselbe System betreiben, wie unserer Server.
  • Die komplette Installation ist in einer Virtuellen Maschine verpackt, die als ganzes gesichert und weitergegeben werden kann. Das spart Zeit, wenn Entwickler dazukommen oder ein Rechner aufgrund von übermäßigem Kaffeekonsum ausfällt.
  • Die Installation läuft selbst virtualisiert deutlich schneller, als der von Mac OSX mitgelieferte Apache oder MAMP. Wer viel Site-Building betreibt und mit Views und Panels UI arbeitet weiß das sicher zu schätzen.
  • Das lästige editieren der hosts-Datei fällt weg.
  • Die Domains funktionieren automatisch auch in anderen Virtuellen Maschinen. Stichwort Internet Explorer testing …
  • Testseiten können blitzschnell installiert und wieder entfernt werden. Datenbanken werden automatisch verwaltet.
  • Tomcat und Solr kommen ohne Zusatzaufwand oder große Konfiguration funktionstüchtig mit.

Diese Gründe sollten eigentlich ausreichen um Entwicklern das Wasser im Munde zusammenlaufen zu lassen. Die Tatsache, dass man damit auf diversen Meetups ganz toll prahlen kann ist nur das Tüpfelchen auf dem i. Im nächsten Teil werden wir uns mit dem richtigen Aufsetzen der Virtuellen Maschine beschäftigen. Stay tuned!