Drush site-alias – ein Sicherheitsnetz für die Drupal-Website-Entwicklung

Anmerkung: Dieser Post erschien ursprünglich im PartMaster-Blog.

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.