Multisite

In der Regel kann man eine Drupal-Site mit einem Projekt gleichsetzen, Projekte nutzen eine Versionsverwaltung, immer häufiger ist dies Git.

Je mehr ich Git nutze, je weniger nutze ich die Möglichkeiten der klassischen Drupal-Multisite-Funkionalität, dem Teilen von Drupal-Core und Contributed-Modules über viele Drupal-Sites hinweg.

Im folgenden möchte ich diese (Verzeichnis-)Struktur innerhalb des Git-Repositories beleuchten und in diesem Zusammenhang Ansätze von spezielleren Drush-Konfigurationsdateien zeigen, welche sich in Drupal-Projekten für mich etabliert haben, ein Teil hiervon ist Drupal-7 spezifisch.

example.com/
|-- drupal
|   `-- sites
|       |-- all
|       |   |-- modules
|       |   |   |- features
|       |   |   |- contrib
|       |   |   `- custom
|       |   `-- themes
|       |-- default
|       |   |-- default.settings.php
|       |   |-- files
|       |   |-- themes
|       |   `-- settings.php
|       |-- example.sites.php
|       `-- sites.php
|-- dumps
|   `-- 20120615-185144.sql
|-- etc
|   |-- apache2
|   |   `-- sites-available
|   |       `-- example.com
|   `-- drush
|       |--- aliases.drushrc.php    
|       |--- git.drushrc.php    
|       `--- example.drushrc.php    
|-- privatefiles
|   `-- IMG_6445.JPG  
`-- salt
    `-- salt.txt
  • drupal

    Die Drupal Code-Basis und DocumentRoot des Webservers.

  • dumps

    Hier liegen die Datenbankdumps

  • etc

    Projektrelevante Konfigurationsdateien, relativ zur Wurzel des Dateisystems.

  • privatefiles

    Dateien die über Drupal verwaltet werden, (Ziel beim Hochladen: Private Dateien).

  • salt

    Beinhaltet in der Datei salt.txt, den aus settings.php ausgelagerten Salt

Rudimente für ein Drupal-Deployment mit

  • Lokaler Entwicklungumgebung
  • Stage-Umgebung
  • Live / Produktionsumgebung

unter Verwendung, der in Drupal-7 neu eingeführten Multisite-Features in der Datei sites.php, Drush-Aliases
und einer speziellen settings.php,
die in diesem Fall versioniert wird.

sites.php -- Verzeichnis Aliase in Drupal 7.x

Die in Drupal 7.x neu eingeführte Datei sites.php stellt erstmalig Verzeichnis-Aliase für Drupal-Multisites zur Verfügung.

So ist es jetzt möglich mit verschiedenen Domains bzw. VirtualHosts ein bestimmtes Verzeichnis innerhalb von sites anzusprechen,
ohne über z.B. Symbolische Links zu gehen, was in vorgigen Drupal-Versionen zur Folge haben konnte, daß Datei- oder Modulpfade beim "umbiegen" von der Dev-Site example.mydomain.de auf die Live-Site example.com divergent sind.

// sites/sites.php

// (LOCAL) DEV SITE
$sites['example.localhost'] = 'example.com';

// STAGE SITES
$sites['stage-example.mydomain.de'] = 'example.com';
$sites['stage.example.com'] = 'example.com';

// LIVE SITE
$sites['example.com'] = 'example.com';

@see /path/to/drupal7/sites/example.sites.php
"Drush und Multisite: drush_multi",
Session über drush_multi auf dem DrupalCamp Vienna, November 2009. drush_multi Session, DrupalCamp Vienna, November 2009
Foto: Florian Klare, ©

Bei einem Drupal Setup wie hier beschrieben, sind nur 8 Schritte für ein Update innerhalb eines Drupal-Zweiges nötig.

Hier wird exemplarisch das Update von Drupal-6.9 auf Drupal-6.10, welches am 27. Februar durchgeführt wurde beschrieben.

Es wird empfohlen die zu aktualisierende Seite in den Wartungsarbeiten-Modus zu versetzen und die Dateien sowie Datenbank im Vorfeld sichern.

Die Konfigurationsdatei für drush

Hier verwendet, drush für Drupal 6.x.

  1. <?php
  2. $options['r'] = '/home/foobar/drupal/6.x';
  3.  
  4. $options['v'] = 1;
  5.  
  6. $options['skip-tables'] = array(
  7.  'common' => array('accesslog', 'cache', 'cache_block', 'cache_filter', 'cache_form', 'cache_menu', 'cache_page', 'cache_update', 'history', 'search_dataset', 'search_index', 'search_total', 'sessions', 'watchdog'),
  8. );
  9.  
  10. $options['handler'] = 'wget';

Um drush in einer Multisiteumgebung zu arbeiten, haben sich folgende Mechanismen als nützlich erwiesen:

So soll die Multisiteumgebung später mal aussehen:

drupal/
|-- 6.x -> drupal-6.14
|-- 6.x_backup
|-- 6.x_profiles
|-- 6.x_sites
|   |-- all  
|   |-- default
|   |-- example.com
|   |   |-- files
|   |   |-- modules
|   |   `-- themes
|   `-- sub.example.com
|       |-- files
|       |-- modules
|       `-- themes
`-- drupal-6.14
    |-- includes
    |-- misc
    |-- modules
    |-- profiles -> ../6.x_profiles
    |-- scripts
    `-- sites  -> ../6.x_sites

Anmerkungen

Der Ordner 6.x_backup beziehungsweise der symbolische Link backup in der
Wurzel der Drupal-Installation ist drush-spezifisch.

Seit Commit 16a4e2b3cf0420a7dce7d3ed79f6701bdd97e095 auf Drush nicht mehr möglich:

Force to use a location for backups outside the drupal root.

Der Ordner 6.x_sites beziehungsweise der symbolische Link sites beinhaltet die einzelnen Sites und deren Daten.

Seit dem Fix von Issue #694708 auf drush_multi, behandle ich profiles analog zu sites.

Um als wieder Benutzer weiterzumachen:

exit

Wechsel in das 6.x_sites Verzeichnis:

cd
cd drupal/6.x_sites/

Anlegen eines Verzeichnisses für die erste Site,

mkdir -p example.com.localhost/files

Das Verzeichnis files für den Webserver schreibbar machen:

chmod 775 example.com.localhost/files

Erstellung des symbolische Links auf die Wurzel der Drupal-Installation, welche später in unserem VirtualHost die DokumentRoot darstellt .

ln -s drupal-6.4-DE 6.x

Grundlegende Konfiguration

Installation und Konfiguration der von Drupal benötigten PHP-Module, die nötigen Schritte um Suchmaschinenfreundlichen URL's nutzen zu können und das Hochsetzen der memory_limit-Direktive.

Die folgenden Schritte sind unter der ID von root auszuführen.

su

oder mit

sudo <BEFEHL>

falls sudo konfiguriert ist.