In Drupal lässt sich ja mit drush site-aliases und den drush-Kommandos rsync und sql-sync elegant ein Setup mit Staging-Site und Live-Site auf einem Server umsetzen, wie kürzlich hier beschrieben. Ziel war dabei, schnell eine Kopie einer Drupal-Website zu erstellen, um daran z.B. Modul-Updates zu testen oder neue Konfigurationen, Module und Themes auszuprobieren.

Das Prinzip lässt sich nun leicht auf den eigenen Rechner ausdehnen. Ich habe z.B. viele meiner aktiv zu entwickelnden Website-Projekte auf meinem Notebook dabei und kann unabhängig von Internet-Verbindung und ssh-Latenz daran weiter arbeiten.

Vesa Palmu hat sehr gut und umfassend beschrieben, wie man sich unter Mac OS eine Drupal-Entwicklungsumgebung einrichtet. Er nutzt die nativen Werkzeuge des OS, eine Alternative ist MAMP. Linux-Benutzer haben auch meist alle Dienste installiert und müssen evtl. lediglich MySQL nach installieren. Windows-Anwender sollten wohl auch XAMPP setzen, um damit zum Erfolg zu kommen. Acquia bietet für alle genannten Betriebssysteme den Acquia Drupal Stack-Installer, der sicher auch eine sehr gute Wahl ist. Ich mag es nativ und habe den erstgenannten Weg gewählt.
Anmerkung: Drush soll auch unter Windows lauffähig sein. Ich habe das nicht getestet.

Nun legt man im Heimatordner den Ordner .drush an und installiert dort drush. Vorzugsweise via Git, weil damit die Aktualisierung der Drush-Installation am einfachsten ist.

cd ~/.drush
git clone git://git.drupalcode.org/project/drush.git
cd drush
git checkout 6.x-4.0-rc3

Der letzte Befehl aktiviert die derzeit neueste drush-Version. Alle verfügbaren Versionen in einem Projekt werden getaggt und können so leicht ermittelt werden:

git tag

Nun noch die Datei aliases.drushrc.php vom im Ordner ~/.drush anlegen (oder vom Server kopieren). Dort werden die beiden Drupal-Installationen auf dem Server eingetragen, in den Feldern remote-host und remote-user die ssh-Zugangsdaten zum Server ergänzen und einen Eintrag für die lokale Installation auf dem Notebook hinzugefügt.

<?php
$aliases['test'] = array(
  'uri' => 'test.beispiel.de',
  'root' => '/var/www/test.beispiel.de',
  'remote-host' => 'www.beispiel.de',
  'remote-user' => 'ich',
);
$aliases['live'] = array(
  'uri' => 'beispiel.de',
  'root' => '/var/www/beispiel.de',
  'remote-host' => 'www.beispiel.de',
  'remote-user' => 'ich',
);
$aliases['dev'] = array(
  'uri' => 'l.beispiel.de',
  'root' => '/Users/drue/Sites/test.beispiel.de',
  'db-url' => 'mysql://web1:MySecret@localhost/usr_web1_3',
);

Ich definiere für jede meiner lokalen Projekt-Websites als Domainname den ursprünglichen Domainname mit einem vorangestellten “l.”. Der Domainname, hier l.beispiel.de wird in /etc/hosts (bei Mac OS und Linux, Windows-User müssen die Datei hosts irgendwo unter c:\windows suchen) eingetragen.
Der Datenbank auf dem lokalen Rechner gebe ich üblicherweise den selben Namen und das selbe Passwort wie auf dem Originalsystem. Da es auf dem lokalen Rechner noch keine Drupal-Installation und damit keine Datei settings.php gibt, muss die Datenbank-URL hier angegeben werden und wird dann in die Datei settings.php übernommen. Die Datenbank muss im MySQL-Server angelegt werden und die Zugriffsberechtigungen korrekt eingestellt werden.

Nun muss dem Apache noch gesagt werden, was er bei Aufrufen der Domain l.beispiel.de ausliefern soll (hier als Minimalversion).

<VirtualHost *:80>
  ServerAdmin dirk@rueweb.de
  DocumentRoot /Users/drue/Sites/l.beispiel.de
  ServerName l.beispiel.de
</VirtualHost>

Nun kann der Transfer der Drupal-Site starten:

drush rsync @live @dev
drush sql-sync @live @dev

Fertig. Nun kann man immer an einer Website arbeiten, ohne immer Verbindung zur Server haben zu müssen.

Achja, nochwas: Wenn das Server-OS nicht gleich lokalen OS ist, bei mir Linux und Mac OS, dann kann es zu einem Problem beim sql-sync kommen, da die Pfade zum Ordner für temporäre Dateien kommen, bei Linux /tmp und bei Mac OS /private/tmp.

mysqldump: Can't create/write to file '/private/tmp/beispiel.de_usr_web1_3.sql.TjyIrx' (Errcode: 2)

Ich habe das nur so lösen können, indem ich auf dem Server das Verzeichnis angelegt habe, welches auf dem Client für temporäre Dateien genutzt wird.

mkdir /private/tmp
chmod 0777 /private/tmp

Drush ist erste Wahl bei der Administration einer Drupal-Website. Und seit Drush auch Site-Aliases kennt, kann man auch “Server voller Drupal-Sites” entspannt verwalten. Bei den Lullabots  ist eine sehr gute Beschreibung zu site-aliases zu finden.

Nun lassen sich diese Site-Aliases nutzen, um zu einer vorhandenen Website eine Testversion anzulegen. Das Ziel ist dabei, eine Kopie einer Website anzulegen, an der man neue Module ausprobieren, Themes überarbeiten oder Konfigurationen testweise ändern kann (und ich könnte hier noch viele andere Gründe nennen…).

Anmerkung: Bei dieser Beschreibung nehme ich an, dass die Live-Website unter der Domain “beispiel.de” erreichbar ist und die Staging-Website unter “test.beispiel.de” aufrufbar sein soll.    Für dieses Setup nutze ich nicht Drupals Multisite-Funktion, sondern zwei getrennte Verzeichnisse. So kann man auf der Staging-Site leicht Module aktualisieren oder austauschen, ohne die Funktion der Live-Site zu gefährden.

Die Einrichtung dieses Setups ist recht einfach.  Zuerst erstellt man die Datei $HOME/.drush/aliases.drushrc.php und beschreibt dort die beiden Websites.

<?php   
$aliases['test'] = array(   
  'uri' => 'test.beispiel.de',   
  'root' => '/var/www/test.beispiel.de',   
);   
$aliases['live'] = array(   
  'uri' => 'beispiel.de',   
  'root' => '/var/www/beispiel.de',   
);   
?>

Die Schlüsselwerte des Arrays $aliases sind die Site-Aliases, in unserem Fall “live” und “test”. Diese werden mit vorangestelltem @ als Drush-Argumente angewendet.

Nun legt man eine weitere Datenbank in MySQL (oder PostgreSQL) an, kopiert mit Drush den Ordner mit der Live-Installation in ein anderes Verzeichnis und passt in der Datei settings.php die $db_url an.

drush rsync --include-conf @live @test   
cd /var/www/test.beispiel.de/   
vim sites/beispiel.de/settings.php

Als Nächstes muss die Datenbank aus der Live-Site noch mittels Drush in die Datenbank der Test-Site kopiert werden.

drush sql-sync @live @test

Jetzt muss man noch dafür sorgen, dass die Test-Website von draußen erreichbar ist und dafür den Webserver anpassen, und ggf. auch den Nameserver.

Nun kann die Test-Website aufgerufen und bearbeitet werden. Um nicht die Übersicht zu verlieren, bietet sich das environment_indicator.module an. Mit dessen Hilfe wird auf der Website eine unaufdringliche Kennzeichnung der Live- und Test-Website an.

Das sieht für die Test-Site so:

$conf['environment_indicator_text'] = 'TEST SITE';   
$conf['environment_indicator_color'] = 'dark-red';   
$conf['environment_indicator_enabled'] = TRUE;

und für die Live-Site so:

$conf['environment_indicator_text'] = 'LIVE SITE';   
$conf['environment_indicator_color'] = 'green';   
$conf['environment_indicator_enabled'] = TRUE;

aus.

Sollen nun neue Module, Themes oder Konfigurationsänderungen an der Test-Site ausprobiert werden, so kopiert man “mal eben” die Datenbank und das Verzeichnis der Live-Site in die Test-Site und kann loslegen.

drush sql-sync @live @test   
drush rsync @live @test

Drush kopiert dabei alle Dateien, schließt jedoch die settings.php aus, so dass die Datenbank-Zuordnung der Test-Site erhalten bleibt. Das Verhalten von drush rsync kann umfangreich angepasst werden, Details dazu bietet die umfangreiche Drush-Hilfe.

Unbedenklich ist das Kopieren der Live-Site in die Test-Site. In der umgekehrten Richtung muss man  vorsichtig sein, es werden ja alle Dateien im Verzeichnis und die Datenbank überschrieben. Im einfachsten Fall verliert man die Watchdog-, Session-  und Statistikdaten seit dem letzten Kopieren der Live- in die Test-Site. Sollten jedoch zwischenzeitlich auch Inhalte auf der Live-Site erstellt oder aktualisiet worden sein, oder wurden Kommentare eingegeben, dann gehen diese beim Kopieren der Test-Site auf die Live-Site verloren.    Möglich wäre es, diese Inhaltsdaten vor dem Kopieren mit Backup_migrate und einem angepassten Backup-Profil sichern und nach dem Kopieren wieder in die Datenbank zu importieren. Aber dass setzt detaillierte Kenntnisse der Drupal-Tabellenstruktur voraus – man ganz genau wissen, welche Datenbanktabellen gesichert und wieder hergestellt werden müssen. Ich habe das so noch nicht angewendet, bleibt also Raum für zukünftige Tests.

Update: Nach dem Kopieren der Seite müssen evtl. noch Konfigurationswerte angepasst werden. So speichert z.B. das Modul Secure Pages die Basis-URL für die http- und https-Version.

drush @live vget securepages_basepath   
securepages_basepath: "http://beispiel.de"   
securepages_basepath_ssl: "https://beispiel.de"

Auch das Modul Mobile Tools speichert URLs für Mobil- und Desktop-Version einer Website als Variablen. Solche Variablen müssen für die Test-Website angepasst werden.

drush @test vset securepages_basepath http://test.beispiel.de   
drush @test vset securepages_basepath_ssl https://test.beispiel.de

Einen Schnelltest bietet:

drush @test vget | grep beispiel.de

Man sollte sich jedoch nicht ausschließlich auf diesen Schnelltest verlassen.

Beim Entwickeln einer Drupal-Website gehören bei mir ein paar Module immer auf die Liste der unbedingt zu installierenden Verwaltungsmodule. Neben dem Admin-Modul und den Themes Tao und Rubik ist da vor allem das Backup and Migrate-Modul zu nennen. Ich installiere es auf nahezu allen Drupal-Websites, egal ob die Installation in einem shared Webhosting erfolgt oder auf meinen eigenen Servern.

Zur Funktion des Moduls: Backup and Migrate erstellt manuell oder zeitgesteuert einen Abzug (Dump) der Drupal-Datenbank in eine Datei. Man kann einzelne Datenbanktabellen komplett vom Backup ausgeklammern oder nur deren Struktur sichern. Diese Datei kann beim Backup gleich noch komprimiert werden. Ein solcher Datenbank-Dump wird bei Bedarf per Mausklick wieder in die Datenbank importiert und ersetzt dabei den vorhandenen Datenbankinhalt. Man kann mehrere Profile anlegen und so bei Bedarf verschiedene Sets von Datenbanktabellen sichern, z.B. bei manuellen Backups keine Watchdog-, Session- und Cache-Tabellen, wohl aber bei der täglichen Sicherung.
Das Modul bringt vorbildliche drush-Integration mit, so dass ein Backup oder Restore mal schnell von der Kommandozeile erledigt werden kann.

Mein aktueller Fall: Gerade übertrage ich unser Intranet-Portal von einer seit Jahren produktiven Eigenbau-Drupal-Instanz in eine OpenAtrium-Installation. Auf der bisherigen Site haben sich eine Vielzahl selbstgebauter Inhaltstypen, Ansichten und jede Menge Beiträge (Nodes) angesammelt, die möglichst auf das in OpenAtrium vorgegebene Repertoire an Inhaltstypen (Buchseiten, Blogpost, Projekte und Aufgaben) abgebildet und in die jeweils passende Gruppe einsortiert werden sollen. Details zu der Migration werde ich später beschreiben, aber es sind verschiedene Strategien am Start und es hat viel mit Probieren und Testen zu tun.

Bei dieser Aufgabe unterstützt mich Backup and Migrate bestens, in dem ich nach jeder erfolgreichen Übertragung von Inhalten oder Konfigurations”orgien” ein manuelles Backup erstelle, ähnlich einem Wiederherstellungspunkt bei Windows, oder, um ein besseres Beispiel zu finden: einem git-commit ;)
Schlägt beim nächsten Arbeitsgang ein Node-Import fehl oder haben die importierten Inhalte noch nicht die erwartete Güte, dann wird das letzte Backup mit einem Klick wieder eingespielt, und ein die Importstrategie kann verbessert nochmals angewendet werden.

Backup and Migrate bietet auch die Möglichkeit, zeitgesteuert und automatisch beim Cron-Lauf eine Datenbanksicherung durchzuführen. Üblicherweise stelle ich als Zeitplan eine Datensicherung alle 24 Stunden ein und erhalte mir die drei letzten Backups. So kann man leicht auf aus Drupal heraus auf einen früheren Stand zurückgreifen, ohne die Datenbankdatei aus dem Serverbackup wieder herstellen zu müssen.

Es ist natürlich auch möglich, mal schnell Veränderungen an der Drupal-Site mittels Vergleich von zwei Datenbank-Dumps herauszufinden:

cd files/backup_migrate
vim -d scheduled/bak-2010-11-12T00-21-25.mysql \\   
      manual/bak-2010-11-12T21-22-41.mysql

Das Modul ersetzt jedoch keine Datensicherung auf Serverebene, sondern bildet eine sinnvolle Ergänzung dazu. Auch werden mit dem Modul keine Dateien gesichert, der Schnappschuss ist also nicht vollständig. Mit Git hat man jedoch einen guten Helfer für gleichzeitige Snapshots des Dateisystems.

So hat mir Backup and Migrate schon manche Stunde Arbeitszeit gespart.

Und noch eine Anmerkung: Bei größeren Projekten und komplexeren Setups mit Development-, Staging- und Live Sites ist man mit Git, Drush make und Features natürlich besser aufgestellt. Aber auch das ist eine andere Geschichte, die ich für später aufhebe. ;)

Mehr brauche ich dazu nicht schreiben, seht Euch einfach das Video an: http://mustardseedmedia.com/podcast/episode38

Update: Hätte ich fast vergessen zu erwähnen: Und warum das alles? Mit dem context.module kann man sehr komfortabel die Anzeigeeinstellungen für Blocks in einer Seite konfigurieren. Also so ähnlich wie die Zurdnung der Blöcke zu regionen und ihre jeweiligen rollenbasierten, benutzerbasierten und seitenbasierten Einstellungen im Block-Konfigurationsformular. Nur eben mit mehr Einstellungsmöglichkeiten, flexiblerer Konfiguration und extrem viel Komfort.

user warning: Unknown column 'path' in 'where clause' query: 
SELECT rid FROM path_redirect WHERE path = '<...>' LIMIT 0, 1
in /sites/all/modules/pathauto/pathauto.inc on line 74.

Der Modulautor hat bei dem Update das Tabellenfeld path in source umbenannt. Davon weiß aber das pathauto.module nichts und nimmt weiterhin das Feld path an. Der Modulautor empfiehlt nun, auf die Entwicklerversion des pathauto.module auszuweichen:

There is currently an incompatibility between Path redirect 6.x-1.0-beta6 and Pathauto 6.x-1.2. You must upgrade to Pathauto 6.x-1.x-dev version. Also, make sure to test before using on a production site. This module still is in beta after all.

Das wollte ich nun auch nicht tun, ich weiß ja nicht, was sich in der Entwicklerversion noch so geändert hat. Also habe ich mit die Fehlermeldung vor genommen und drei Zeilen in der Datei /sites/all/modules/pathauto/pathauto.inc geändert. Hier der Patch (leicht angepasst für die Webseitenbreite):

diff -u pathauto.inc{,.orig} 
--- pathauto.inc        2010-01-08 22:14:57.000000000 +0100
+++ pathauto.inc.orig   2010-01-08 22:10:44.000000000 +0100
@@ -68,10 +68,10 @@
   $alias_pid = db_result(db_query_range("SELECT pid FROM {url_alias}
      WHERE dst = '%s' AND src <> '%s' AND language = '%s'", array($alias, $src, $language), 0, 1));
   if (function_exists('path_redirect_delete')) {
     // Delete from path_redirect the exact same alias to the same node.
-    path_redirect_delete(array('source' => $alias, 'redirect' => $src));
+    path_redirect_delete(array('path' => $alias, 'redirect' => $src));
     // If there still is this alias used in path_redirect, then create a different alias
-    $redirect_rid = db_result(db_query_range("SELECT rid FROM {path_redirect} WHERE source = '%s'", $alias, 0, 1));
+    $redirect_rid = db_result(db_query_range("SELECT rid FROM {path_redirect} WHERE path = '%s'", $alias, 0, 1));
   }
   if ($alias_pid || !empty($redirect_rid)) {
     return TRUE;
@@ -405,7 +405,7 @@
     if (variable_get('pathauto_update_action', 2) == 3 && function_exists('path_redirect_save')) {
       if (!empty($old_alias)) {
         $redirect = array(
-          'source' => $old_alias,
+          'path' => $old_alias,
           'redirect' => $src,
         );
         path_redirect_save($redirect);

Ich hoffe das Problem wird sich von offizieller Seite schnell lösen. 1-2 Modulupdates werden erwartet. ;-)

Was mir noch fehlte, war die Einbindung in drush, um “mal eben” einen DB-Schnappschuss erstellen zu können. So hatte ich mir für die erste Januarwoche vorgenommen, ein kleines Modul zu bauen, welches genau dies implementiert. Und siehe da: Die 2.x-Linie des Moduls bringt die Funktionalität schon mit!

bam backup           # Backup the site's database with Backup and Migrate.
bam restore          # Restore the site's database with Backup and Migrate.
bam destinations     # Get a list of available destinations.
bam sources          # Get a list of available sources.
bam profiles         # Get a list of available settings profiles.
bam backups          # Get a list of previously created backup files.

Ein kurzes

drush dl backup_migrate
drush updatedb

erledigte das Update von der bisherigen Version 1.2 auf 2.2. Danke Ronan!

Aber dann kam das Gespräch zu Workflows und der Integration mit den Office-Werkzeugen (natürlich die aus dem Hause Microsoft). Und da gefiel mir sehr, wie eine Aufgabe im Sharepoint im Outlook weiter bearbeitet/verwaltet werden konnte, wie Office-Dokumente im Sharepoint eingebettet, weiterbearbeitet, versioniert und freigegeben werden können. Gute Arbeit.

Dann ist mir als administrationserfahrenem Microsoft-Anwender (Server 2003, Exchange, …) durch den Kopf gegangen, das für die Demo auf Server- und Clientseite neueste Hardware im Einsatz sein musste, um die Demo so flüssig hinzubekommen. Und dass man all diese schöne neue Welt nur hinbekommt, wenn man sich voll auf den Softwarestack aus Redmond verlässt: Windows OS, Exchange, Sharepoint, Office (komplett). Und dass man die Daten da nie wieder ohne Schmerzen rausbekommt, wenn es mal ein besseres System geben sollte. Und dass man bei der einfachsten Installation locker einen ganztagsadmin dafür einplanen kann.

Aber einiges ist nach der Demo denn doch auf meinem Drupal-Wunschzettel gelandet:

• Intuitivere UI (was sicher mit dem Drupal 7 User Experience Project geschafft wird),
• Bessere Integration mit externen Office-Werkzeugen
• Bessere Suche im Drupal

• Besseres Dokumentenmanagement (bzw. “nahtlose” Integration eines DMS)

Und was kann ich dafür tun?

• Ich werde mich in den nächsten Tagen intensiver mit D7UX beschäftigen und mal sehen, wie ich mich da einbringen kann.
• Ich werde mir aktiv zwei Projekte auf den Schreibtisch holen
  • trac -Support für das project.module
• SyncML-Unterstützung für Drupal (um Kalender, Aufgaben und Kontakte zwischen Drupal und meinem Nokiafon zu synchronisieren. Andere Synchronisationsprotokolle können gern folgen.

• Mehr Übersetzungen an die Projekte zurückliefern

Also los!

Ich habe drush unter /usr/local/share installiert und ein paar Shell-Aliase definiert:

alias drush=/usr/local/share/drush/drush
alias bdrush='drush -r ~/html/d6/ -l http://beispiel.de'
alias edrush='drush -r ~/html/d6/ -l http://example.org'
alias ddrush='drush -r ~/html/d6/ -l http://demo.example.org'
alias pdrush='drush -r ~/html/d6/ -l http://projects.example.org'

Drupal ist im Verzeichnis ~/html/d6/ installiert. Die Parameter -r und -l helfen drush, die gwünschte Website zu finden.

Und dann ist die Installation eines Modules so einfach wie:

drush dl support       # herunterladen nach sites/all/modules/
drush enable support   # Aktivieren des Moduls

Das Update einer Website wird mit

drush update

erledigt. Und an das Datenbankprompt bringt mich

drush sql cli

Den Rest findet Ihr selbst heraus. ;)

Nun wollte ich auf einfach Weise den Cron-Lauf für alle Websites zentralisieren. Und habe mir mit einem knappen Mehrzeiler geholfen:

#!/bin/bash
#
# Script to run the cron task on all installed Drupal sites.
#
# (C) 2009 Dirk Ruediger <dirk@niebegeg.net>
#
# This script depends on an Drupal installation, shell access to the
# server and drush installed.
#
;
# Where is the drush script located on my disk
#
DRUSH=/usr/local/bin/drush
;
# Any custom options for drush
#
OPTS=
;
# A listing of installation directories for drupal sites.
# On a confixx managed host Drupal is installed in an html/ subfolder in
# the client's home folder. The home folders are in /var/www.
#
ROOTS='/var/www/web*/html'
;
for s in $(find $ROOTS -name settings.php)
do
  DIR=$(echo $s | sed 's@/sites/.*@@')
  SITE=$(echo $s | sed 's@.*/sites/\([^/]*\)/.*@\1@')
  if [ $SITE == 'default' ]
  then
      $DRUSH $OPTS  -r $DIR cron
  else
      $DRUSH $OPTS -r $DIR -l http://$SITE cron
  fi
done

Das Skript such in allen htdocs/-Verzeichnissen aller User eines onfixx-Hosts nach Drupal-Installationen und führt drush cron für alle Websites einer Installation aus. So macht Administration Spaß!

—

¹ Wer ist nicht genervt, wenn im Drei-Tage-Takt irgend ein Modul bei irgendeiner Installation eine Sicherheitsaktualisierung benötigt, man das tar.gz-Paket herunterlädt, auspackt, das FTP-Programm anwirft und die Dateien auf den Webserver zu laden und anschließend noch update.php auszuführen. Und immer in kleinen Chargen, um dem White screen of death wegen eines zu knapp bemessenen _memory_limit_ auszuweichen…