DrupalVM - eine Web-Entwicklungsumgebung nicht nur für Drupal - Teil 1

Wer mit Content-Management-Systemen Websites baut, braucht einen lokalen Webserver. Was sich fürgroß und gefährlich anhört beim ersten Kontakt mit der Materie, ist spätestens mit der breiten Verfügbarkeit von einfach installierbaren LAMP-Stacks einfacher als vermutet. Und die gibt es seit Anfang der Nuller Jahre. Die erste Software dieser Art war für mich persönlich XAMPP. Im Paket enthalten: Ein Apache Webserver, Mysql, PHP und allerhand Zugaben. Das Wesentliche sind aber diese drei Software-Pakete. Damit kann man PHP-Applikationen lokal betreiben und testen.

Zumindest wer professioneller Webworker ist und mit PHP arbeitet, sollte lokal arbeiten. Für den Großteil der Zielgruppe dieses Blogposts sollten die bisherigen Ausführungen etwa so interessant sein wie daß der Papst katholisch ist und Wasser oftmals nass.

LAMP ist gut - virtuelle Maschine ist besser

Z.B. XAMPP ist nur eine Portierung der genannten Teilkomponenten auf Windows ist und die Autoren sind bemüht, möglichst wenig von der Linux-Implementierung zu ändern. Denn schliesslich möchte man das Verhalten des Servers, der im allgemeinen unter Linux läuft, möglichst genau emulieren. "It worked on my machine" hilft beim dicken Bug auf der Stage- oder gar Livemaschine niemand. Daher - und auch das ist so neu wie die Zeitung von vorgestern - verwendet der ambitioniertere Webworker eine virtuelle Maschine, in der Linux läuft. Damit ist man der Abbildung des Zielsystems ein ganzes Stück näher. Man kann eine echte Linux Shell benutzen und alle Komponenten nativ verwenden. Für Drupal Entwickler besonders wichtig z.B. für Drush. Besonders als Entwickler, der auf Windows arbeitet, fühlte man sich den Macintosh-Kollegen irgendwie immer unterlegen von der OS-Seite. Denn die Macs laufen schon lange auf Unix und damit können die ganzen Linux-Pakete mehr oder weniger nativ ausgeführt werden. Was natürlich schneller und besser ist als die immer irgendwie hinkende Emulation auf Windows. Heutzutage läuft Windows schon lange mit 64 Bit und man kann soviel Arbeitsspeicher reinstecken wie man will. Es spricht also absolut nichts dagegen, das Problem mit einer virtuellen Maschine zu lösen - vielleicht abgesehen von der etwas größeren Komplexität der Installation und Maintenance.

Virtuelle Maschinen lassen sich mittlerweile auf sämtlichen Betriebssystemen komfortabel mit dem Host-Betriebssystem verbinden. Das benötigte Shared Directory, über das die Dateien zwischen Host und Gastsystem bidirektional synchronisiert werden, funktioniert bei richtigem Aufsetzen problemlos. Spezialisten dieser Materie werden mir wahrscheinlich widersprechen und allerhand Probleme, die es mit dieser Synchronisierung immer noch gibt, aufzählen können. In meiner praktischen Arbeit mit der hier beschriebenen virtuellen Maschine habe ich bis jetzt allerdings noch keine gehabt. Encoding (UTF-8) und Zeilenenden (LF auch auf Windows am besten) werden beibehalten, und von Performance-Schwierigkeiten habe ich nichts gemerkt. Der langsamste Faktor bin immer noch ich, der Entwickler.

Drupal VM, eine Vagrant Maschine

Besser, als die virtuelle Maschine selber aufzusetzen (oder zumindest einfacher) ist es, eine vorkonfigurierte zu benutzen. Im Zeitalter der Containerformate nicht wirklich schwierig. Docker, Vagrant - erlaubt ist was gefällt. Ohne bis in die letzte Schraube verstanden zu haben, was Vagrant wirklich ist - für mich reicht zu wissen, dass es eine Containersoftware für virtuelle Maschinen ist, die mir das Leben leichter macht.

Drupal VM ist mit Ansible und Vagrant gebaut - oder sollte ich sagen gepackt? An einer Docker-Version wird geschraubt, diese gilt derzeit noch als experimentell.

Was ist in der Schachtel?

Da sie aus der Drupal Szene kommt, ist die VM vor allem für Drupal Entwicklung optimiert. Man kann sie aber auch problemlos für die Arbeit mit anderen CeEmEssern verwenden, wenn man die Drupal-spezifischen Sachen deaktiviert bzw. nicht benutzt.
Die problemlos mitaktivierbaren Extras über die erwähten drei Basiselemente Apache, Mysql und PHP hinaus lesen sich durchaus beeindruckend:

u.a. Apache Solr, Varnish, Memcached, XHprof (für PHP 7 Tideways), die schlanke PHPmyadmin-Alternative Adminer, der Mail-Tester MailHog. Wer diese Dinge schonmal zu Fuß installiert hat, wird es zu schätzen wissen, wenn eine einfache Aktivierung mehr oder weniger per Schalter in vorkonfigurierter Form zur Verfügung steht.

Aufzucht und Hege

Drupal VM wurde von Jeff Geerling entwickelt und wird von ihm betreut. Jeff ist einer dieser Leute, bei denen ich mich frage, wie sie das alles schaffen. Ich habe vor allem immer seine hilfreichen Blogposts zu konkreten Drupal-Development-Themen mit viel Nutzen gelesen. Modul-Maintainer und aktiv auf drupal.org etc. Allein das Betreuten von Drupal VM sollte eine Menge Arbeit sein: auf Tickets antworten, Bugs fixen, neue Features einbauen... Für unser Thema aber nur wichtig: man hat nicht den Eindruck, dass der Support von Drupal VM wegen Zeitnot in Gefahr ist. Denn das wichtigste bei Software ist schliesslich, dass sie weiterentwickelt wird.

Auf die Installation und Nutzung gehe ich einem kommenden Blogpost ein. Bis dahin: die Doku und der Quick Start Guide sind sehr gut gemacht. Es ist definitiv komplizierter als XAMPP zu installieren, aber wenn man alles brav befolgt nicht wirklich schwierig.

Im nächsten Post (kommt bald): Installation von Drupal VM