Im Drupalcenter-Podcast ging es kürzlich um Multisites. Ich habe diese Funktion früher auch für viele meiner Webhostings eingesetzt und nutze Multisites nun gar nicht mehr. Eine gute Gelegenheit für einen Einwurf.
„Multisite“ ist eine raffinierte Funktion, um mehrere Drupal-Websites aus einer Codebasis zu betreiben: Im Webserver werden mehrere Domainnamen auf das selbe Drupal-Installationsvverzeichnis konfiguriert. Beim Seitenaufruf ermittelt Drupal den Domainnamen zum Request, sucht im Ordner sites/ den passenden Ordner mit den Konfigurationsdaten. Wenn es für die gesuchte Domain keinen Ordner gibt, dann wird im Ordner sites/default/ nachgesehen. Die im Konfigurationsordner vorhandene Datei settings.php enthält unter anderem die nötigen Datenbank-Informationen und Drupal liefert mit den in der Datenbank abgelegten Daten schließlich die Webseite aus. Eine detaillierte Beschreibung zu Multisites liefert das Handbuch auf drupal.org sowie die Linkliste am Podcastbeitrag.
Diese Funktion war ein unverzichtbares Hilfsmittel, als Festplattenkapazität auf dem Server kostbar war und FTP die einzige administrative Zugriffsmöglichkeit auf den Server war: Bei der Installation einer neuen Website braucht man nur einen neuen Konfigurationsordner anlegen, die settings.phpdorthin kopieren und anpassen und eine neue Datenbank befüllen. Beim Update eines Moduls kopiert man die von drupal.org heruntergeladene Modulversion per FTP auf den Server und ruft für jede Website die Updatefunktion im Browser auf. Und genau diese Arbeitserleichterng ist das Problem mit Multisites: Nach dem Austauschen der Moduldateien muss man sofort die Datenbank-Updates auf allen Websites durchführen. Das kann natürlich einige Zeit dauern, und so lange sind unter Umständen (bis zu n-1) Websites dieser Multisite-Installation zerbrochen. Und man muss darauf vertrauen, dass das Modul-Update keine der Websites „zerbricht“ — also gleich noch testen, was wiederum wieder viel Zeit beansprucht. Und wie geht man vor, wenn nun Eine der Multisites nach dem Update nicht mehr funktioniert? Viel Handbareit und eine erstmal zerbrochene Website bleiben zurück.
Seit rund 3 Jahren betreibe ich (fast) alle meine Drupal-Sites auf Webhostings, bei denen ich mich per ssh auf dem Server einloggen und die Websites administrieren kann. Bei den großen Anbietern bekommt man solch ein Hosting ab ~10 Euro je Monat. Alternativ dazu kann man sich für den Preis auch einen vServer klicken. Ich bin großer uberspace-Fanboy, dort bekommt man ein Webhosting mit ssh-Zugang (und sehr vielem mehr) für den Preis, den mit das Angebot wert ist. Ich folge mittlerweile der Empfehlung der Betreiber und habe für jede Website einen eigenen Uberspace (also ein eigenes Benutzerkonto auf einem der Uberspace-Server), weil auch die E-Mail-Konfiguration per Uberspace erfolgt und ich so jedem Kunden problemlos Ssh-Zugang zu „seinem“ Uberspace geben kann.
Nun fragt Ihr vielleicht, wie viel mehr Zeit ich für ein so verteiltes Hosting investieren muss? Deshalb hier noch ein paar Ausführungen dazu.
Ich bin bekanntermaßen begeistert von drush, dem Kommandozeilenwerkzeug für Drupal. Natürlich ist drushauf allen Uberspaces installiert. Ich pflege eine Vorlage für ~/.drush auf meinem lokalen Rechner und die wird — zusammen mit weiteren Konfigurationsdateien — in jeden neuen Uberspace kopiert. Aktualisierung des Setups ist auch schnell getan:
cd ~/uberspace_template
for i in $(uberspaces)
do
echo "*** $i ***"
rsync -var . $i:
done
Das $(uberspaces) habe ich kürzlich beschrieben.
Auf dem Uberspace kann ich nun mit drush schnell ein Backup der Website machen, Module aktualisieren und ein fälliges Update in Sekundenschnelle auf einer Kopie der produktiven Website testen.
drush rsync @live @test
drush sql-sync @live @test
drush @test up views
# und nun Testen
drush @live bam-backup
drush @live up views
Details dazu und den obligatorischen Hinweis auf environment_indicator.module findet Ihr in dem frühren Blogbeitrag.
Um herauszufinden, welche meiner Drupal-Installationen von einem nötgen Update betroffen sind, läuft dieses Sktipt von meinem lokalen Rechner aus:
for i in $(uberspaces)
do
echo "*** $i ***"
ssh $i "find /var/www/virtual/$i -type f -name modulname.module"
done
Um es noch einfacher zu haben, habe ich alle Dateien aliases.drushrc.php vom Server auf meinen lokalen Rechner kopiert und den Namen des Uberspaces als Prefix vorangestellt
for i in $(uberspaces)
do
echo "*** $i ***"
scp $i:.drush/aliases.drushrc.php ~/.drush/$i.aliases.drushrc.php
done
Dann noch die Paramater remote-hostund remote-user in den Aliases ergänzen und ich kann vom lokalen Rechner aus Drush-Kommandos auf dem Uberspace ausführen, ohne mich vorher dort anmelden zu müssen:
drush @uberspacename.live st
Das vergangene halbe Jahr seit meinem Umzug zu uberspace.de mit strengen Separation aller Websites auf eigene Benutzerkonten (Accounts) hat gezeigt, dass dieser Workflow robust ist und mit drush, git, komfortablem Backup auf Systemebene und all den anderen Helferlein keinen Mehraufwand gegenüber einem eigenen Server mit allen Websites unter /var/www bringt. Dafür aber Zuverlässigkeit der Plattform, schnell durchgeführte Drupal-Updates und einen freigestellten Linux-Admin.
Nun bin ich auf Deine Meinung gespannt. Wie administrierst Du Deine Drupal-Sites? Was für Hosting-Pakete favorisierst Du wie passt Dein Provider zu Dir? Und: Nutzt Du noch Multisites und ich habe irgend ein cooles Feature aus den Augen verloren?