Gegenüber den Vorgänger-Versionen zeichnet sich Drupal 8 durch ein erheblich verbessertes Configuration Management aus. Die gesamte Konfiguration eines Projektes befindet sich in Form von YAML-Dateien im Ordner /config/sync und lässt sich sauber versionieren und zwischen verschiedenen Umgebungen wie z.B. "lokal", "Staging" und "Production" ausrollen.

Herausforderung Drupal Multisites

Bei Multisite Projekten, bei denen sich mehrere Websites eine weitgehend gemeinsame Code-Basis teilen, besteht jedoch die Herausforderung, wie mit der Konfiguration umzugehen ist. Zum großen Teil greifen alle Projekte auf die selben YAML-Dateien zurück, sich zum kleinen Teil unterscheidet sich die Konfiguration jedoch zwischen den einzelnen Websites.

Dies ist z.B. dann der Fall, wenn alle Seiten ein einheitliches Content-Modell verwenden, jede Seite jedoch ihren eigenen Google Analytics Tracking-Code benötigt.

In Drupal lässt sich das Verzeichnis /config/sync mit Bordmitteln nicht aufteilen.

Aufteilung der Konfiguration in "shared" und "override"

Um den Überblick über den jeweiligen Konfigurationstand in parallen Geschwister-Projekten nicht zu verlieren, wäre es also wünschenswert, die Konfiguration in zwei separate Ordner wie z.B. config/shared und config/override aufzuteilen.

Der gemeinsame Code in "config/shared" kann als eigenes Composer-Projekt in alle Geschwister-Projekte referenziert werden. Änderungen an der gemeinsamen Konfigurations-Basis gelangen mit dem nächsten composer install bzw. composer update automatisch in die Geschwisterprojekte.

Indem sich die gemeinsame Konfiguration an zentraler Stelle befindet, lassen sich die Unterschiede in den jeweiligen "config/override"-Ordnern besser vergleichen.

Configuration-Management mit "Nimbus"

Exakt hier setzt das Modul "Nimbus" ein, welches diese Funktionalität ermöglicht. Der Begriff "Nimbus" stammt aus dem lateinischen und bedeutet sowohl "dunkle Wolke" als auch "Heiligenschein". In Harry Potter ist sogar der bekannte Rennbesen "Nimbus 2000" nach diesem Modul benannt.

Nimbus benötigt keine Konfigurations-Oberfläche. Die Einstellungen werden in der settings.php vorgenommen. Die Ordner lassen sich dabei frei wählen. Der Konfigurations-Abschnitt kann z.B. so aussehen:

// Nimbus config override settings.
global $_nimbus_config_override_directories;
$_nimbus_config_override_directories = [
'../config/shared',
'../config/override',
'../config/export',
];

Beim Einlesen der Konfiguration liest Nimbus die YAML-Dateien aus dem Array $_nimbus_config_override_directories der Reihe nach durch und importiert die Konfiguration. Die Verwendung konkurrierender Konfiguration wird dadurch unterstützt: Der letzte Ordner gewinnt. Dies kann z.B. dann wichtig sein, wenn lokal ein anderes Verhalten als auf den Web-Servern gewünscht wird.

unsere comm-press Best-Practice

In unseren eigenen Projekten verwenden wir üblicherweise diesen Satz an Ordnern:

  • config/shared: gemeinsame Konfiguration
  • config/override: übersteuerte Konfiguration je Projekt
  • config/local: optional für lokale Konfiguration
  • config/export: neue exportierte Konfiguration, die in shared und override aufgeteilt werden muss
  • config/sync: lassen wir für den Fall stehen, dass sich in alten Branches gegebenenfalls noch Konfiguration befinden sollte

Wir haben entschieden, die Ordner config/shared und config/override invers zu verwenden: Eine Konfiguration soll sich üblicherweise entweder in config/shared oder in config/override befinden. Das erleichtert den Vergleich der parallelen unterschiedlichen Konfiguration in Geschwisterprojekten. Um dies zu erzwingen, haben wir den Ordner config/export per .gitignore ausgeblendet und als Regel festgelegt, dass dieser Ordner bei jedem Commit leer sein muss.

Bei diesem "inversen" Vorgehen muss man jedoch im Hinterkopf behalten, dass sich ein Projekt ohne den config/override Ordner nicht installieren lässt.

Konfiguration jederzeit aus Modul-Ordner einlesen.

Bei Drupal 8 lässt sich Modul-Konfiguration üblicherweise nur während der Installation einlesen. Indem Modul-Ordner als Nimbus "Override Directories" benannt werden, ermöglicht Nimbus auch im laufenden Betrieb den Import von Konfiguration aus dem Modul-Ordner.

drush Plugin "force uuid"

Drupal lässt bekanntlich nicht zu Konfiguration zu importieren, wenn die UUIDs aus Konfigurationsdatei und Datenbank nicht übereinstimmen. Das Update z.B. per config-set in der Kommandozeile ist etwas anstrengend. Dafür haben wir drush ein Plugin "force uuid" spendiert, welches mit dem einzigen Befehl drush force-uuid bzw. drush fuuid sämtliche UUIDs in der Datenbank auf den aktuellen Code-Stand abgleicht, damit sich die Konfiguration anschließend importieren lässt.

Weitere Tools und Helferlein

An Nimbus entwickeln wir aktiv weiter. Die Umsetzung folgender Funktionen in Form von Sub-Modulen befindet sich in Planung bzw. bereits in Bearbeitung:

  • Konfigurations-Quellordner für Nimbus auf read-only bzw. write-only setzen zu können. Damit lässt sich der oben beschriebene Vorgang, /config/export per .gitignore auszuschließen, vereinfachen.
  • Konfiguration aus einer Liste weiterer Module zu berücksichtigen.
  • Konfiguration aus allen aktiven Modulen zu berücksichtigen.
  • Implementierung einer Redis Anbindung. Damit lässt sich Konfiguration per Web-Service einlesen bzw. bereitstellen.

Alternatives Modul "Configuration Split"

Von [Nuvole]{https://www.drupal.org/nuvole} gibt es ein übrigens ein Modul "Configuration Split" mit praktisch deckungsgleicher Kernfunktionalität aber einem anderem Featureset in den Randbereichen.